Stage 1: Patched to work right now
Stage 2: Refactored Core I18n
Stage 3: User Data Translation
How will it work?
- custom_mo(&$mo_file_paths, $locale, $context, $domain) allows you to inject custom .mo files into the translation, based on the translation context.
- ts_post($locale, $original_text, &$translated_text, $params) allows you to detect, profile and change any prepared translation just before delivery
- ds_post($locale, $original_text, &$translated_text, $params) allows you to do the same for user data. This will only become available with stage 3.
- SYSTOPIA's Custom MO extension allows you to define custom .MO files that should be evaluated before the regular translation kicks in.
- SYSTOPIA's Profiler extension allows you to live-capture ongoing translations and export those as .PO and .POT files, so you can easily create or amend the existing translation.
What can I do with it?
- Start the translation profiler (de.systopia.l10nprofiler)
- Fill out the form, go through every step
- Stop the profiler
- Download the PO file.
- Use a translation editor (like POEdit) to change the translations where you want to
- Upload the resulting MO file the editor produces into the second extension (de.systopia.l10nmo) and use to its configuration page to activate it
It's pretty exciting to see you moving forward with this!
For folks who weren't in the conversation at Bamford and who don't do a whole lot with internationalization, I just want to add a little bit more of the context. CiviCRM's translation generally works fine if the site starts with one language and sticks with it, and it also supports multiple languages. Each additional language comes with a cost (requiring a set of additional MySQL columns on many tables) -- and MySQL imposes some hard limits on the number columns. The extra technical cost is fine for 2 or 3 languages but becomes problematic with 10 languages.
The basic idea here is to shift some of the multilingual work out of MySQL and into gettext. MySQL is a general-purpose data-store... and gettext is a specialized data-store optimized for translation of strings across many languages. The great thing is that gettext performs well at runtime; it's a de-facto standard for software translation projects; and it's already used for large parts of Civi's translation. What's the catch? The workflows are usually geared toward the needs of experts (translators/developers), but Civi's ecosystem is diverse (including experts and novices), and the current MySQL approach has better options for reaching novices. Making something comparable with a pure-gettext runtime definitely calls for some R&D (design/tooling/development/documentation/etc).
I really like how l10nx is oriented around extensions. That means Bjoern (and other experts, hopefully!) can collaborate on this publicly and deploy the iterations as needed -- even while less sophisticated users can continue with the built-in translation mechanisms (and hopefully lend some moral support!).
Great stuff. I continue to be amazed how many projects you are involved with enabling & collaborating on Tim.
Bjoern - great to see you picking this up & running with it.
Also clever title!
Really exciting to see this :-)
Really nice! Good work!
That sounds exiting!