Internationalization - Proof of Concept

[jscheidtmann]

• Configure gettext for use with PiFinder
• Mark all relevant strings in menu_structure.py for translation
• Use pybabel to extract a *.pot file
• Create a German translation file
• Demonstrate German menu
• Add command line param to select language
• Add menu entry to select language
• Add selected language to the configuration
• Make tests run again

[jscheidtmann]

Running

$ pybabel extract -o messages.pot python

in the PiFinder root directory extracts the marked strings successfully.

[jscheidtmann]

Got a German menu running:

As you can see umlauts are supported.
The current patch is ... well ... sub-optimal: Translation happens at load time of the menu structure. That way translation files needs to be read and ready before all the imports in main.py.

[jscheidtmann]

The translation is now applied at point of display (for the text menu).
This means I could move the Translation-object instantiation to the start of PiFinder, when all the configuration is done.
That in turn means we can make language selection a command line parameter and a menu option.

[jscheidtmann]

• Command line param --lang overrides configured language and stores in configuration.

• Menu entry "Language" in settings allows to select language on the fly.

• Nox / ruff still have problems with the _() function.

[jscheidtmann]

Ruff and mypy as run by nox now run through with-out errors. Although, I have to admit, it's slightly ugly:

While ruff can be configured to have _() added to the builtins, there's no such facility in mypy (and bug reports on this are unresolved now since basically 5 years: #8727, #12172)

Instead, when TYPE_CHECKING, I define a very laxly annotated _()-function. We will have to add that to the top of each compile unit that is using the _()-function.

[mrosseel]

apart from the scripts seems fine, haven't tested it though!

[mrosseel]

this implies changes to pifinder_setup and pifinder_update so everyone gets the languages. Also, each time a new language is added, these scripts need to be updated - unless we have some queryable single source of languages like a file used by the setup scripts and the app

[jscheidtmann]

When updating, we can check the python/locale folder for new subdirs and then install the respective packages/languages. Alternative could be to install „all“ languages once. I have to check which of these options is preferable.

[jscheidtmann]

See #264 (comment) : At least on bullyeye, nothing like this is necessary.

[jscheidtmann]

• Ok, setup a Pi3B with-out hardware.
• Downloaded latest release img
• git pull origin
• added my fork as remote jscheidtmann
• git pull jscheidtmann
• checkout jscheidtmann/i18n
• pip install -r requirements
• had to create the tetra3 symlink
• disabled the service
• started PiFinder from command line with --camera debug
• The software couldn't find the IMU and GPS, but nevertheless started and started solving (as per messages on the console)
• I could open up the remote server and:

The language menu is there, one can switch to french or spanish, even if the locale has not be generated! So no requirements (on bullseye) to generate locales!

[jscheidtmann]

From my point of view, we could merge it. We still have to weed out non-translated items and mark them with _(), translate them and checkin the respective .mo-files.

[jscheidtmann]

Waiting for translations for French.