Translation layer to be used for menu items and other items

[LunaMeadows]

What is the problem or limitation you are having?

Currently when creating a Toga application, the menu items are only in English with no way to change the language or edit the default menu items easily.

Describe the solution you'd like

Using a module like gettext and creating locale files for languages. Ideally all items would be translated already for users for any language however that would take a lengthy amount of time. It may also be useful to pick a module that allows dynamic editing/creation of locale files so a dev could add their own translations.

Using a module like gettext would allow for a seamless experience for end users and devs to speed up the language parts of development, especially if we could include a way to add their own translations to their program. Either through toga methods OR the use of a new briefcase entry in the TOML file.

Describe alternatives you've considered

I am not sure of other translation modules for python, I have only looked into gettext. There may be a better or more well suited option that I am not aware of.

Additional context

No response

[freakboy3742]

Strongly agreed that this is a feature that is required.

Some initial thoughts and discussion topics based on my (very limited) prior experience dealing with translation stuff:

• Terminology: there's 2 related issues - Internationalization (frequently abbreviated as i18n... i, 18 letters, then n :-) ) and Localization (l10n). Internationalisation is the literal translation part - making "Hello World" appear as "Hallo Welt" in a German locale. Localization is formatting and other UI tweaks - things like date format (MDY? DMY?), and number format (1,000.00 or 1.000,00?).
• As you've noted, gettext is the default answer to this problem. It's not without flaws - but it's also well known, so the flaws are reasonably well understood (e.g., pluralisation of Eastern European languages is complex).
• A tool like Babel might be worth investigating, as it provides both a wrapper around i18n, a lot of additional l10n capabilities, and a bunch of "stock" translations such as days of the week, months, and so on.
• In addition to the basic "API" for implementing i18n and l10n in code, there are some additional factors that need to be considered:
  • How is the locale specified by the end user of an app? i.e., how does the app know that I'm in a German locale? Does this change between python -m myapp and briefcase-style deployment?
  • Toga itself definitely has translation needs (for menu items) - but how does this change the workflow for third-party developers? If an app developer wants to translate their own menu items or labels, what does that process look like?
  • How do we (as a project) manage translations? Is there any project-level tooling we can provide to make the translation process easier?

[LunaMeadows]

I looked into the Babel tool option and it does look like a better starting point then gettext. Tho while looking, I found it hard to locate any information on how to give Babel your own translation files in addition without also using gettext unless I was not looking into the right things. Further information/help could be useful there if any can be given.

As for the additional factors, here are my thoughts

• Default behavior I feel should be to include a way for each platform to auto detect the users language. This should provide the most support out of the gate. I feel like the option to change the language would fit in something like the preferences menu if/when that gets implemented. The app dev could also provide their own way of setting a different language. This would also require that there be an exposed method that allows the dev to change the current language of the app and preferably update all language in the app without a restart.

• For devs to translate their own menu items, I have a few different thoughts. 1) We update each widget that contains text to include translation by default by wrapping the provided text to get translated. If this is something that would already have a translation by default then no further action is needed. This also takes the work off the dev from having to implement translation again when it's already there in toga. 2) If the dev wants to translate something that is not already in Babel, they would need a way to include their own PO files. This is something that I am not seeing a way to do without moving that to a briefcase implementation. I don't know how tied to briefcase you want to make toga or if you want to try and keep it usable outside of it. This implementation wouldn't make it unusable outside of briefcase but they would lose support for personal translation files.

  To actually provide the PO files, my thought was to include a new entry in the briefcase TOML file that let's users add their own PO files as well as a new folder in the briefcase directory to house the PO files. Then when the dev builds the project, we have something that combines the PO files if any are present and if any changes are made to the default PO files it would recompile the PO files to MO files.

  The other option to keep toga apart from needing briefcase for this is add a toga method to add translation files but this would be more complex I feel and could lead to more issues as the PO files would have to be compiled every time at launch I believe.

• For this, I don't have much insight. Ideally we would have one central location that stores all the default translation files in the toga repository so that they can easily be edited when working on the codebase and then as part of pre-merge checks or something we have something that would run and copy those files to all the other needed locations. I don't know if any of the currently used tools has an option for that but I don't feel like that would be something complicated to create and implement if it's not already an option.

  As for tools in general to make translating easier/editing the translation files we could recommend a program like poedit for a nice gui interface to edit those if people want to assist in providing translations. That's not a needed thing but could make it more inviting for people to contribute to them.