Hi Patrick,
thank you for the explanation, looks like this was the best choice, then.
(and good to see you again! We've been missing you.)
Maren
Am 17.11.20 um 18:41 schrieb Patrick Storz:
Hi all,
to quickly chime in here (I'm the one who implemented this part of the code): Detecting the language code automatically would obviously be the ideal case. Unfortunately there's actually not an easy way (at least none that I'm aware of) to detect the translation that ultimately is being used from within Inkscape code! This part is automagically handled by a third-party library (gettext) which will pick the language that appears most suitable on the user's system (the choice depends on a multitude of locale settings compared against the list of available translations, taking locale variants and dialects into account). In other words: gettext picks a translation file based on a non-trivial internal logic and returns translated strings without Inkscape even being aware of the specific locale that is used eventually.
Short of re-implementing the logic of gettext and hoping to get it right (otherwise one might end up with a localized template when Inkscape is set to English or vice-versa) the easiest way to determine the language code turned out to be to simply ask gettext to translate the string "en" (which all of this is about).
I initially "translated" all of these for all languages (by using a script), so translators would not have to worry about this. It's possible some of the strings got lost again while syncing translations at a later point, though.
Cheers Patrick
Am 16.11.2020 um 23:52 schrieb Milo mail:
On second thought, LINGUAS file distinguishes "localized" translations … for instance:
- en_AU
- en_CA
- en_GB
Hmmm … to bad I'm not a programmer, so I don't know if my initial idea with LINGUAS file works ...
Sorry, Milo
16.11.2020., u 21:49, Milo mail mail@milotype.de je napisao:
Another idea I have is to use the languages in the "LINGUAS" file to determine the language …
Milo
16.11.2020., u 20:34, Milo mail mail@milotype.de je napisao:
IMO, the problem is the string definition itself, even though a comment for translators is specified in the .po file (but obviously easily overseen):
'en' is an ISO 639-1 language code. Replace with language code for your language, i.e. the name of your .po file
I do agree with Maren, that this string should ideally be "translated" automatically in some way. I'm not a programmer … maybe by using the file prefix of the .po file?? So maybe it's possible to get rid of this string altogether …
Milo
16.11.2020., u 16:02, Maren Hachmann maren@goos-habermann.de je napisao:
Great! It was an interesting find for me, too - I'd have thought that the language abbreviation would be inferred automatically.
Take care, Maren
Am 16.11.20 um 14:37 schrieb Cristian Secară:
În data de Mon, 16 Nov 2020 02:17:18 +0100, Maren Hachmann a scris:
> So, the English template is used. I just dug a bit deeper into the > code and found that you need to translate the term "en" to "ro" to > benefit from the translated template file. Found it:
#. TRANSLATORS: 'en' is an ISO 639-1 language code. #. Replace with language code for your language, i.e. the name of your .po file #: ../src/file.cpp:895 ../src/io/resource.cpp:154 ../src/io/resource.cpp:159 #: ../src/verbs.cpp:2375 msgid "en"
For some reason it was "translated" also as en, changed to ro and is ok now.
Thank you, Cristi
Inkscape Translators mailing list -- inkscape-translator@lists.inkscape.org To unsubscribe send an email to inkscape-translator-leave@lists.inkscape.org
Inkscape Translators mailing list -- inkscape-translator@lists.inkscape.org To unsubscribe send an email to inkscape-translator-leave@lists.inkscape.org
Inkscape Translators mailing list -- inkscape-translator@lists.inkscape.org To unsubscribe send an email to inkscape-translator-leave@lists.inkscape.org
