Discussion: Localization Strategies for Static Template Strings

[katporks]

I'm evaluating different strategies for localizing static template strings:

1. Django's Default Translation System: This method uses Django's built-in translation system, which stores translatable strings in .po files within a localization folder. This approach would necessitate direct modifications to these files via GitHub.

2. Transifex: This method involves using Transifex for fileless localization. I'm currently favoring this approach as it's being utilized in the Tasking Manager project (refer to their translation documentation for more information).

I'd appreciate your thoughts and suggestions on these options or any others that you think might be best. Thank you in advance for your input!

[spwoodcock]

I think it should be a mix of the two ideally.

I'm sure others have ideas / input, but the ideal I envision is:

1. Use Weblate to gather community-driven translations (using Github directly is a barrier to many).
   • It has nicer features and better maintenance than Transifex: https://github.com/transmission/transmission/issues/2538
   • The hosted solution is free for open source projects.
   • Supports many different file outputs, so would work for both Wagtail (PO) and Lit (XLIFF): https://docs.weblate.org/en/latest/formats.html
   • Ideally we can have a centralised project with translation strings that are used across multiple projects.
   • Any specific strings that are not present in most projects could possibly go in a different project (let's experiment and decide).
2. Then we export translations in whatever format we need from Weblate and periodically update the translation files outselves in our chosen repo.

[dakotabenjamin]

Agree with sam. These strings are not as frequently needing to be updated as the CMS content, so it will be important to set a low-maintenance workflow for perioding syncing.

[dakotabenjamin]

I have configured Weblate for this repo