Context
As of 2021-10: The interface translation process in Tiki needs some love. We have seen some failures like
- Transifex (A volunteer started the project and then became unavailable)
- i18n.tiki.org (which we are restarting now)
and some successes like
- Translations Revamp
- Migration of all related CLI scripts to
php console.php translation:*
- Some keen community members reporting issues with untranslatable strings
The current status is that it's confusing for translators to get started.
Let's clean this up.
Let's have a 2 hour online session with the experts of this topic and clarify the high-level direction, and 2 or 3 multilingual junior developers will start using, and refine the documentation as they go.
The most important point is to decide where to converge all the documentation related to translators: doc.tiki.org vs tiki.org vs dev.tiki.org vs translation.tiki.org Then, move/update all the docs while adding redirects to old pages.
Who
- Jean-Marc
- Brendan
- Marc
- Jonny
- Adrien (coordinator of the junior devs)
- @Bernard Sfez / Tiki Specialist
- @luciash d' being 🧙
- You? (join the discussion!)
What
There should be at least 3 ways to contribute translations
- Via GitLab's web interface
- Tested here
- Via Git process that all devs use (CLI, IDE, etc.)
- i18n.tiki.org (for in-context translations and/or other non-tech savvy Users/Translators familiar interface everyone can use?)
There should be at least these sections:
- How to edit/add strings to an existing translation
-
language.php
-
language.js
-
- How to add a new language
- How to contribute (and merge) 3rd party/external translations (e.g. made in-context on their local Tiki installation and exported from there)
Special cases:
- Same term in English has more than one meaning in a translation, depending on context
IE: The English word "Location" exist and is used for a place (geo-location trackeritem) while it also also exist in French for a place or renting an apartment. - I changed a string in English and I don't want to break translations
- Contribute translations to trunk, and after, backport to a branch (ex.: Tiki21 LTS)
Everyone listed above, please review all documentation on *.tiki.org to make sure a new community member can contribute translations to trunk via GitLab. Developers can be sent to normal Git contribution workflow, while non coders should have a recipe to use the web interface.
All scripts are converging to console.php and docs need updating:
https://gitlab.com/tikiwiki/tiki/-/merge_requests/717
https://gitlab.com/tikiwiki/tiki/-/commit/be39ca6315a1432c019e5976ef796a4222edbdde
While documenting, let's think of opportunities for enhancements and automation. Ex.:
- What are other opportunities to save time and reduce errors?
How to reduce waste disk space in Tiki source code?
- GitLab is tracking many lines with English to English commented translations like Copy to clipboard// "Registration & Log in" => "Registration & Log in",
- There was a parameter to clean up all commented out lines from language.php in getstrings script, no?
Running php console.php translation:getstrings as part of the CI would generate a lot of noise.
Maybe translators should have Translation Priorities and run translation:getstrings on their instance before contributing translations?