Bug 130979 - LO7: Tooltips in cui/messages.po contain variable %MOD1 instead of string
Summary: LO7: Tooltips in cui/messages.po contain variable %MOD1 instead of string
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 125615
Blocks: Tip-Of-The-Day
  Show dependency treegraph
 
Reported: 2020-02-27 08:22 UTC by Martin Srebotnjak
Modified: 2022-10-23 14:06 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Srebotnjak 2020-02-27 08:22:36 UTC
Description:
Obviously to circumvent different strings for macOS and other OS (as modifier keys are different) someone introduced %MOD1 to insert a proper key.
But this solution is useful only for English and other languages that do not uses cases - for other languages this is not a proper solution.
So please revert strings back to Ctrl or create separate strings for macOS. These strings cannot be localized properly.

Actual Results:
Tooltips cannot be properly localized in some languages.

Expected Results:
Tooltips should allow for proper localization.


Reproducible: Always


User Profile Reset: No



Additional Info:
UI designers should think about the l10n process.
Comment 1 Martin Srebotnjak 2020-02-27 08:32:24 UTC
Another reason this solution is not l10n friendly:
In English the key are written with capital letters (Ctrl, Cmd).
In Slovenian, for example, it has its own naming (krmilka for Ctrl), and it is written with small capital letter. So when this modifier lands at the start of the sentence, the sentence will start with small letter, although as being the first word in a sentence it should start with a capital letter.

Here is an example how cases make your solution unuseful (from Slovenian; string uikxZ):
Hold down %MOD1 and turn the mouse wheel to change the zoom factor.
- Translation would be: -
Držite pritisnjeno %MOD1 in zavrtite kolesce miške, da spremenite faktor povečave.
- if %MOD1 would become "krmilka", localized sentence would read: -
Držite pritisnjeno krmilka in zavrtite kolesce miške, da spremenite faktor povečave.
- But that is wrong, as the key "krmilka" should be in the 4th case and should read "krmilko", so this is the desired result which this kind of code cannot generate: -
Držite pritisnjeno krmilko in zavrtite kolesce miške, da spremenite faktor povečave.

I wonder what other issues might arise with other languages...
Comment 2 Martin Srebotnjak 2020-02-27 09:00:43 UTC
Also, the tooltips in cui still remain Windows/Linux-centic, as the Options dialog path for macOS is different, but shows as for Windows/Linux, so maybe also the keys should remain Windows/Linux-centric or switchinline code should be used for both.
Comment 3 Heiko Tietze 2020-02-27 10:50:12 UTC
Done in bug 125615; you can localize the terms used for %MOD1/%MOD2

#define STR_CMD                         NC_("STR_CMD", "⌘ Cmd") //use narrow no-break space U+202F here
#define STR_CTRL                        NC_("STR_CTRL", "Ctrl")
#define STR_Alt                         NC_("STR_CMD", "Alt")
#define STR_Option                      NC_("STR_CTRL", "⌥ Opt") //use narrow no-break space U+202F here

It's defined in cui/inc/tipoftheday.hrc

Does this work for you?
Comment 4 Martin Srebotnjak 2020-02-27 22:10:34 UTC
No, Heiko, please read my example in second post.

Languages (not English) have cases, as does German. Only that in German only in Genitiv usually words get a "s" ending (or similar).

In Slovenian and many other languages of the World cases mean different ending in several cases. And the keyboard shortcut is not always in Nominativ.

So your solution would work, only if it could create proper case according to the grammar of every l10n language, which of course it cannot do.

So this solution is not OK.
Comment 5 Mike Kaganski 2020-10-15 14:18:30 UTC
I don't think it's a reasonable request.

Being a Russian native speaker, I understand what Martin talks about. Yet, it's unreasonable to create tons of duplicating translatable strings to account for macOS differences. And of course, development of AI to manage natural languages differences (creating word forms matching context) is out of question.

The placeholder approach is rather established; and given that dialog has quite a lot of room for the tip, I assume it's always possible for a translator to re-phrase the tip to e.g. not have the problematic word (krmilka) the first word (avoiding uppecase/lowercase problem), or to be in proper case (maybe by adding some introductory words).

Using fixed "Ctrl" (for both macOS and others) is also bad, because it's too often that bug reports and user questions have confusion related to the key combinations used in other OSes.
Comment 6 Mike Kaganski 2020-10-16 07:17:02 UTC
A related idea: there's vcl::KeyCode::GetName(), which provides the key combination name used in our menus.

We could use it instead of duplication the effort in cui/inc/tipoftheday.hrc; e.g. making the array look like

> ...
> { NC_("RID_CUI_TIPOFTHEDAY", "Did you know that you can attach comments to portions of text? Just use the shortcut %KEYCOMBO."), "", "", vcl::KeyCode(KEY_SHIFT | KEY_MOD2 | KEY_C)},
> ...

and then just replace "%KEYCOMBO" with vcl::KeyCode(4th_elt_of_tuple).GetName() if 4th_elt_of_tuple is not 0.

That method would (1) automatically account for macOS differences; and (2) could allow for following extension, where you would provide a UNO name instead, to convert it to key combination, and it would get actual key combination -> additionally automatic account for localization differences (some have different default key combinations) and even user-defined preferences.

Heiko, what do you think?
Comment 7 Heiko Tietze 2020-10-16 09:36:13 UTC
(In reply to Mike Kaganski from comment #6)
> Heiko, what do you think?

Pro: cleaner code, and we get rid of STR_CMD/STR_CTRL
Con: more complexity for the tip (another attribute in the tupel), doesn't solve Martin's concerns

(In reply to Mike Kaganski from comment #5)
> it's always possible for a translator to re-phrase the tip

I concur.
Comment 8 Mike Kaganski 2020-10-16 09:49:15 UTC
(In reply to Heiko Tietze from comment #7)
> Con: more complexity for the tip (another attribute in the tupel)

This IMO is not important (if we need some manageable complexity in code to make a good thing, it's justified); and anyway, there are other proposals to limit tips to current module - that is impossible without extending the tuple with module identifier. This would also be needed here, because key combinations are often module-specific... so extension of the structure is likely anyway - the question is what is most useful to users and the tips.
Comment 9 Ming Hua 2020-10-16 09:58:35 UTC
(In reply to Mike Kaganski from comment #6)
> (2) could allow for following extension, where you would provide a UNO name
> instead, to convert it to key combination, and it would get actual key
> combination -> additionally automatic account for localization differences
> (some have different default key combinations) and even user-defined
> preferences.
I'd like to chime in that the benefit of accounting for l10n differences is not hypothetical, but already existent in current tips, namely
https://opengrok.libreoffice.org/xref/core/cui/inc/tipoftheday.hrc?r=728548f8#88
"Need to insert the date in a spreadsheet cell? Type %MOD1+; or Shift+%MOD1+; to insert the time."

Here many locales don't have an easy-to-access semicolon key, and use %MOD1+, and Shift+%MOD1+, (comma instead of semicolon) instead.  Such a change would save the translators from double-checking to make sure their localized UI and TotD match, as evidenced in the following mailing list thread:
https://listarchives.libreoffice.org/global/l10n/2020/msg00340.html
Comment 10 Heiko Tietze 2020-10-20 12:14:21 UTC
(In reply to Ming Hua from comment #9)
> Here many locales don't have an easy-to-access semicolon key...

Maybe I got this wrong, but to my understanding this is about the %MOD1 variable in tips being replaced by STR_CMD or STR_CTRL depeding on whether you run macOS or not.

Martin suggests something like
Tip1_MACOSX = "Press Cmd to write Hello World"
Tip1_UNXWIN = "Press Ctrl to write Hello World"

where the current solution is

Tip1_MACOSX = "Press %MOD1 to write Hello World"
...
#define STR_CMD                         NC_("STR_CMD", "⌘ Cmd")
#define STR_CTRL                        NC_("STR_CTRL", "Ctrl")

and the %MOD1 (and MOD2) are replaced per code.


You may change the shortcuts in your localization and refer to this shortcut, see https://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/Accelerators.xcu where the first entry Ctrl/Cmd+A is assigned to Select All for English but Open in case of Spanish (<value xml:lang="es">).
Comment 11 Martin Srebotnjak 2020-10-20 12:37:03 UTC
No, Heiko, I do not suggest this.
I am having the following problem (as described in an extensive way in my 2nd comment):
the system of replacing placeholder with a fixed localized key name does not work always for languages with cases, where words need different forms in a different case/use.
"krmilka" (for Ctrl) needs to be sometimes "krmilke" or "krmilko", depending on the sentence and the case the word appears in.
Since English and German do not have this problem (except for Genitiv use in German) I guess it is hard to understand, but I hope now I made it clear.
Comment 12 Heiko Tietze 2020-10-20 13:49:36 UTC
(In reply to Martin Srebotnjak from comment #11)
> the system of replacing placeholder with a fixed localized key name does not
> work always for languages with cases, where words need different forms...

Which effectively means to remove the %MOD variable ending up in one version for Linux/Windows and another for macOS.
Comment 13 Ming Hua 2020-10-21 05:34:52 UTC
(In reply to Heiko Tietze from comment #10)
> (In reply to Ming Hua from comment #9)
> > Here many locales don't have an easy-to-access semicolon key...
> 
> Maybe I got this wrong, but to my understanding this is about the %MOD1
> variable in tips being replaced by STR_CMD or STR_CTRL depeding on whether
> you run macOS or not.
My comment was specifically about Mike's suggestion of adding %KEYCOMBO variable and a fourth member of TofD tuple, and its possible extension to automatically getting the shortcut key-combo from system/user configuration (in contrast of hard-coding them in the tip text).

[...]
> You may change the shortcuts in your localization and refer to this
> shortcut, see
> https://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/
> openoffice/Office/Accelerators.xcu where the first entry Ctrl/Cmd+A is
> assigned to Select All for English but Open in case of Spanish (<value
> xml:lang="es">).
To use your example here, said extension, if implemented, would have a tip "Press %KEYCOMBO to select all text/cells/whatever", instead of "Press %MOD1+A to select all" as we have now, and the Spanish translator has to be mindful and change "%MOD1+A" to whatever shortcut Spanish UI is using in his/her translation.
Comment 14 Ming Hua 2020-10-21 05:45:23 UTC
(In reply to Ming Hua from comment #13)
> My comment was specifically about Mike's suggestion of adding %KEYCOMBO
> variable and a fourth member of TofD tuple
As long I'm commenting in this bug reported by Martin, I should add that this %KEYCOMBO idea seems to have the same shortcoming as the current %MOD1/%MOD2 implementation (if not worse), and won't solve his problems encountered while doing Slovenian translations.
Comment 15 QA Administrators 2022-10-22 04:03:19 UTC Comment hidden (obsolete)
Comment 16 Martin Srebotnjak 2022-10-23 14:06:32 UTC
This problem persists and since it does not affect English and German languages, it remains unsolved.