Allow for disambiguating same-word/phrase, but different context

[Athanasius]

It is possible that we might have a word, or short phrase, that in English can be re-used in multiple contexts, but in other languages requires a different translation for each context.

The current translations framework only allows, per language, for one translation per 'key' string.

Discuss ideas for allowing to disambiguate, e.g. an optional second parameter to the translation function that prepends a string for the look up.

[magni1200s]

I am not an I18N/L10N expert nor Qt dev, but it seems that Qt 5 has a good implementation for this issue.

Internationalization and Localization with Qt Quick

See "3. Disambiguate Identical Texts". You can add an another meaning as the second parameter to the same text.

[Athanasius]

I am not an I18N/L10N expert nor Qt dev, but it seems that Qt 5 has a good implementation for this issue.

Internationalization and Localization with Qt Quick

See "3. Disambiguate Identical Texts". You can add an another meaning as the second parameter to the same text.

We don't use Qt, this is a tk(inter) project.

To flesh out the idea I had:

1. We use a function _(string) to request a translation in code.

2. The string passed in is the 'key' for the lookup.

3. The translation files are in macOS .strings format, one file per supported language. Each entry consists of a comment (which I believe appears on OneSky) and then a line with `"key string" = "translation string";:

   /* Comment about this translation */
   "Key string, which is what appears if no translation" = "The translated string";
   

   And note that we use a file of the same format to define the phrases to be translated, which is in English and has the translated phrase identical to the key phrase.

4. So my proposal would be to change the function to take an optional second argument: _(string, disambiguate). This second argument is also a string.

5. In the translation files we would prefix the key string with, e.g. [<disambiguate>] so that the keys differ between different contexts for the same phrase.

So, an example. This may well not differ in any language we support, but let's go with how we use 'Default'. This is used both for "the default theme" and "the system/OS default language".

In code we would use something like:

prefs.py-644-        # LANG: The system default language choice in Settings > Appearance
prefs.py:645:        self.lang = tk.StringVar(value=self.languages.get(config.get_str('language'), _('Default', 'Language')))
...
prefs.py-675-        nb.Radiobutton(
prefs.py-676-            # LANG: Label for 'Default' theme radio button
prefs.py:677:            appearance_frame, text=_('Default', 'Theme'), variable=self.theme, value=0, command=self.themevarchanged
prefs.py-678-        ).grid(columnspan=3, padx=self.BUTTONX, sticky=tk.W, row=row.get())

And in the en.template file:

/* prefs.py: The system default language choice in Settings > Appearance; In files: prefs.py:645; */
"[Language]Default" = "Default";

/* prefs.py: The default theme choice in Settings > Appearance; prefs.py:677 In files: prefs.py:677;*/
"[Theme]Default" = "Default";

And we would, of course, update our documentation to define that any string of the form [words] should not only not be translated, but should not appear at all in the translated string.

I'll have to review all the current code to be sure that [some words] won't clash with anything. We already have {UNTRANSLATED WORDS} for anything that needs to stay literally in the translation. It does look like we don't currently make use of square brackets, so they're available for this.