The web translations still use the original Cockpit mechanism for creating and loading the translations
That uses a server based logic which has quite some drawbacks
We have to reimplement the very same logic in a Webpack plugin to make it work also in the local development server (npm run server). And unfortunately we cannot share the code because it is Rust vs. Javascript...
This will not work in the Agama online demo site with completely static files (without any server side logic, everything needs to be on the client side).
For me the original logic was quite strange, why the server should decide which translations should the client use? It should be completely handled on the client side, there is no reason for the special server logic. The server should just report the available translations and let the client to pick and use the right one.
The old implementation has also some ugly parts like requiring a global Javascript variable...
Solution
Move the translation logic from the server to the client (browser)
Use dynamic imports instead of HTTP redirection
Implementation details
Removed the po.js handler from the Agama HTTP server
Removed the po.js handler from the Webpack development server
Removed the original Gettext PO files from Git, replaced by already converted JS files
Removed the Cockpit Webpack plugin for converting PO files to JS, replaced by a simple script with similar functionality. (As a bonus the code was fixed to avoid adding unnecessary null values into the output.)
Added dynamic import for downloading the requested translations
Some code cleanup (removing the global JS object)
Moved the jed and gettext-parser NPM dependencies to the PO->JS converter, that means those NPM packages are installed only when converting the PO files to JS (basically only in the GitHub action which merges them), they are not installed when building the Agama web frontend
Testing
Tested manually, loading the translations works fine
I manually triggered the GitHub Action which merges the translations from Weblate. It works fine, the test run opened this pull request with updated translations (there are more changes as it was executed in the same branch as this pull request).
TODO
[x] Improve the mechanism for finding the appropriate translation file, the current simple logic only uses the language name and cannot load the pt_BR translations which additionally include the country code
[x] Rewrite the Webpack plugin for converting the *.po file to *.js into a standalone script (Webpack needs to load the JS files during compilation, the dynamically generated JS files are not found)
[x] Update the import from Weblate, run the new script and convert the *.po files to *.js during import (the Git repository will contain the already converted *.js translations instead of the original *.po Gettext files)
Problem
npm run server). And unfortunately we cannot share the code because it is Rust vs. Javascript...Solution
Implementation details
po.jshandler from the Agama HTTP serverpo.jshandler from the Webpack development servernullvalues into the output.)jedandgettext-parserNPM dependencies to the PO->JS converter, that means those NPM packages are installed only when converting the PO files to JS (basically only in the GitHub action which merges them), they are not installed when building the Agama web frontendTesting
TODO
pt_BRtranslations which additionally include the country code*.pofile to*.jsinto a standalone script (Webpack needs to load the JS files during compilation, the dynamically generated JS files are not found)*.pofiles to*.jsduring import (the Git repository will contain the already converted*.jstranslations instead of the original*.poGettext files)