A unified approach for ui elements for multilingual - Idea

I am just writing a small little tool to use with some friends I play a game with (lords Mobile). But most my friends are thai, so i need it to be “multilingual” well in this case bilingual(English/Thai). I know there are a million approaches you can take to do this. But what really gets in the way of iterating over the elements finding the correct string and assigning it, is some small inconsistencies in what the text value is. Eg, a label you should set the text attr, a button you should set title attr.
I understand this can easily be coded around. But it seems to me, as Pythonista evolves, some thought/support for multilingual ui’s would be great. I mean in the sense that because of some small support in Pythonista , most will write multilingual views the same way. I am not suggesting you should write a translation module. But maybe you have a attr called caption or something like that. If its != None then you apply it to the visual ui part of the element. Ok, maybe not a good way, but I am sure you get my meaning. If you make it, they will come, basically. Sorry, I know I have not articulated this very well. However, i think the concept is there. People normally follow the developers way of doing things, if there is no way stated, then everyone makes it up themselves.

iOS way

In ObjC, localization does work in this way:

section_label.text = NSLocalizedString(@"Hallo", @"section title");

@"Hallo" is a string, which is used by default (when the language bundle is not found or the string is not found in the bundle). Then, you can generate strings from your source files, which is a simple text file:

/* section title */
"Hallo" = "Hallo";

Now you can translate the right part to any language, copy it to a language bundle. Then iOS automatically translates these string.

Better approach is to use keys, instead of real text, provide even en_US bundle as well. Something like:

section_label.text = NSLocalizedString(@"SECTION_TITLE", @"section title");

/* section title */
"SECTION_TITLE" = "Hallo";

It's better, because you're not forced to to modify all language bundles when the key changes. Like Hallo -> Hello and now you have to change this particular key in all bundles.

All these things applies when you're writing native iOS app. Not sure if this can be used within Pythonista script, etc. I think no, because even these resources are signed AFAIK (correct me if I'm wrong, didn't localize an for a while).

Python way

You can use gettext for example:

import gettext
gettext.bindtextdomain('myapplication', '/path/to/my/language/directory')
gettext.textdomain('myapplication')
_ = gettext.gettext
# ...
print(_('This is a translatable string.'))

Just google it, ton of examples around how to generate strings, etc. Not sure if everything is possible with Pythonista (for example generating .mo from .po, dunno if there's pure Python solution).

Related issues

Something like this can be created for Pythonista. But I think that Python gettext should be used to make all these scripts compatible with desktop. Just some tools to generate .mo files can be created for example.

Still not sure if it's worth it. Localization is hard and had ton of side effects. Not hard in terms of simple text replacement, but other issues like LTR (Left-To-Right), RTL, different text lengths (job for auto layout (#402)), ...

@zrzka, thanks for the time for the complete reply. I still think the Pythonista ui Elements could offer some help. One big help is that the ui objects can now have runtime added attrs or custom attrs in a UIFile. This is helpful for assisting something like an id (in this context a language id). One useful thing would be a attr something like caption. Where caption sets the default text property for the control. Just all to iterate/walk all controls in a view and talk with one attr rather than coding exemptions for title, text, segments. In older app like vb/hypercard they called this the default assignment attr or something like that.
I had a quick look at the gettext lib. I will see how easily it seems to work with. It appears to work very similar how I used to do it on the Mac years ago. Our cat files where resource files. We also did all calls to app constants with our default language (for readability as well as a fall back if no translation found). For all our static application views, we tagged all our ui elements with an id. the view was iterated over and if translation not found, the elements default would be the fallback.
Anyway times have changed a lot since then, there maybe some extras that gettext can help with.

I have already done a simple version of a type of gettext using TinyDB and using tables.

I will do more....

omz / Pythonista-Issues