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...

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.

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?

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.

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.

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?

(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.

(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.

(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

(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">).

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.

(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.

(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.

(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.

This problem persists and since it does not affect English and German languages, it remains unsolved.

This problem persists and since it does not affect English and German languages, it remains unsolved.

(In reply to Martin Srebotnjak from comment #18)
> This problem persists and since it does not affect English and German
> languages, it remains unsolved.

Which could be translated as: "Martin didn't translate the problematic tip to make it unproblematic - by drastically change the sentence to make the %MOD1 appear in a place where it isn't affected by the considerations in comment 0" ;-)

E.g., the translation could be like this English equivalent:

  Hold down the key "%MOD1" and turn ...

Well, Mike does not understand, that in some languages the names of keys do not start with capital letters, only words at the start of sentences do ... Whereas in English and German that is OK.

So a "Ctrl" at the start of a sentence in Slovenian is "Krmilka", while inside a sentence it is "krmilka" (both are now in the nominative, they change in other cases of course, which is still my main objection to using %MOD).

Since the string appears previously as translatable string "Ctrl", it is, as one cannot know where in a sentence (if at all it will be used as a part of a generated sentence, which should IMHO be a no-no) it will appear, translated as "Krmilka". When used in the way you propose - it is incorrect as far as Slovenian language (and many others) is concerned.