Whilst preparing the new v3.0.0 release and refreshing the translations, which should have been a simple exercise, I found the following snags.
Some messages are "untranslated", meaning the translated string (msgstr) is empty ie ""
Should these be set to the original (English) text rather than leaving empty to make it clear the translator intended there to be no difference? See Fahrenheit below for example.
I need to test this, as I assume (so I can get out of fixing all this now) that an empty translated text (msgstr) would just return the original (msgid) as per the following
To use a domain set by textdomain the function
char *gettext (const char *msgid);
is to be used. This is the simplest reasonable form one can imagine. The translation of the string msgid is returned if it is available in the current domain. If it is not available, the argument itself is returned. If the argument is NULL the result is undefined.
Update: Since I cannot determine why those strings were not translated, I just have to leave them
Of these only the rpm and Fahrenheit ones are of interest, as "Last Updated" I added recently (so there are not translations except for Spanish via google translate) and the voltage one ("%s%.2f%s") which has no translatable text anyway.
But for the voltage format one ("%s%.2fV"), where there is no translatable text now (because the units are coming from the output of sensors), this translation should probably be removed.
For a translation that is no longer required, by default msgmerge retains the msgid and msgstr and marks them as obsolete with #~ prefix, eg in tr.po
#~ msgid "N/A"
#~ msgstr "YOK"
I think it better to use the msgattrib command to strip out the obsolete translations, eg
msgmerge update.po file.pot | msgattrib --no-obsolete > file.po
Also, I did add a new translatable string "Sensors in Menu", but I see the "fuzzy" logic of msgmerge has picked op the translated text (msgstr) of "Sensor in Panel", which as far as I am concerned is close enough for now as it only appears in the prefs.
The new "Sensors in Menu" text is not translated, even though everything else works.
Update: after a lot of pain (note: remove stamp-po to re-make (compile) the gmo files) it is the "#, fuzzy" line that is preventing the translation - removing it then got the translation working, putting it back in stopped the translation again.
I was wondering why I couldn't get the locale override to work, and now I see I have left the old extension UUID in the calls to find the file that specifies the temporary locale
"temperature@xtranophilist"
I'l like to use the uuid at run time via the extension/extensionprefs class properties like I do with this.path and this.metadata. Refer to:
initTranslations() ... Consider this method deprecated. Only specify gettext-domain in metadata.json. GNOME Shell can automatically initiate the translation for you when it sees the gettext-domain key in metadata.json.
Darn it, I didn't test the translations before this, and it appears I was too eager to remove all the old imports, including the one for Gettext which contains the setlocale method:
Whilst preparing the new v3.0.0 release and refreshing the translations, which should have been a simple exercise, I found the following snags.
Should these be set to the original (English) text rather than leaving empty to make it clear the translator intended there to be no difference? See Fahrenheit below for example.
I need to test this, as I assume (so I can get out of fixing all this now) that an empty translated text (msgstr) would just return the original (msgid) as per the following
Update: Since I cannot determine why those strings were not translated, I just have to leave them
List of untranslated strings (ie msgstr is "")
Of these only the rpm and Fahrenheit ones are of interest, as "Last Updated" I added recently (so there are not translations except for Spanish via google translate) and the voltage one ("%s%.2f%s") which has no translatable text anyway.
But for the voltage format one ("%s%.2fV"), where there is no translatable text now (because the units are coming from the output of sensors), this translation should probably be removed.
For a translation that is no longer required, by default msgmerge retains the msgid and msgstr and marks them as obsolete with #~ prefix, eg in tr.po
I think it better to use the msgattrib command to strip out the obsolete translations, eg msgmerge update.po file.pot | msgattrib --no-obsolete > file.po
Also, I did add a new translatable string "Sensors in Menu", but I see the "fuzzy" logic of msgmerge has picked op the translated text (msgstr) of "Sensor in Panel", which as far as I am concerned is close enough for now as it only appears in the prefs.
The new "Sensors in Menu" text is not translated, even though everything else works.
Update: after a lot of pain (note: remove stamp-po to re-make (compile) the gmo files) it is the "#, fuzzy" line that is preventing the translation - removing it then got the translation working, putting it back in stopped the translation again.
"temperature@xtranophilist"
I'l like to use the uuid at run time via the extension/extensionprefs class properties like I do with this.path and this.metadata. Refer to:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html#extension-js
initTranslations() ... Consider this method deprecated. Only specify gettext-domain in metadata.json. GNOME Shell can automatically initiate the translation for you when it sees the gettext-domain key in metadata.json.
const Gettext = imports.gettext;Luckily I found it here:
https://gjs-docs.gnome.org/gjs/gettext.md
with new esm import
import Gettext from 'gettext';