Transifex project is translated with our Native technology! 🎉

I would like to inform you that we are currently developing a new technology of integrating Transifex project with well… Transifex. With this integration in place you will eventually get more context and control over localization. All changes below are referring only to “Transifex” project.

A big part of these changes are on the syntax of the strings, which will now be ICU enabled. As you understand this will enable a big depth of localization syntax supported phrases. For now we will only support plurals and placeholders/variables of the ICU syntax.

We are at the stage where a new resource called “Core_native” is added in the Transifex project and all strings along with their comments, issues, screenshots, tags, etc. are already migrated to that resource. To secure that we maintain a single point of truth for the aforementioned metadata (issues, comments, etc.) we have locked the existing resource called “Core” so that it will not accept any translations.
You can continue your work on the “Core_native” resource.

Despite our efforts there is a chance some translations and metadata will be lost. For such cases we advice you to check TM suggestions of strings as there are cases where translations are available with the only difference of variable placeholders marking. For those cases please copy the TM suggestion and take some time to replace with the correct variable placeholders found on the source strings. In almost all cases we use the same name displayed in variable placeholders but have different characters surrounding them, e.g. variable placeholder ‘%(month)s’ is transformed to ‘{month}’.

Since this is a strategic effort for Transifex that we feel will be valuable to other projects’ localization, we would really appreciate your input, feedback and suggestions into making this technology useful for translators too! Finally if you have found a workaround or a specific improvement in your workflow, we would appreciate sharing it with everyone using Transifex community.

Thank you for your efforts in keeping Transifex translated.

2 Likes

I know there are several other implementations:

  1. L20n/Fluent
  2. Crowdin method
  3. Wikipedia/MediaWiki
  4. Transifex method
  5. All sorts of funky methods supported by Weblate

Is there a reason for developing another method for that?
Is it an actual ICU standard?

Thank you!

Rather than a new method, the only change affecting translators is that xliff files have substituted .po ones for offline translation, and that only for Transifex translation project. (Not for the plethora of projects hosted in https://www.transifex.com ). Again, this only affect those of us who use offline translation tools.
I was firstly concerned with the change, because of the lack of free .xliff editors and of loosing the ability to use any translation memory creating through working with .po files. Poedit seems to provide a nice solution: with it you open .xlf files as you’d do with .po ones. No need for any extra steep. After opening it, you forget about it being a .xlf file: all Poedit capabilities are available.

P.S. I don’t know which format is better and in what cases

@ujdhesa thank you for the clarification on Poedit + xliff.

@yaron if I understood correctly your question, what Transifex Native brings on the table is a way to unify all your content across different frameworks directly in your codebase with no files created. We are using the ICU syntax as it is a well-known, rich localization syntax.
Transifex vision is summarized great in our Transifex Native announcement blogpost, as an end-to-end, fully cloud-based localization stack.
For more details you can also check our documentation introduction.

In case I totally mis-understood your question, please clarify.

Yaron, Transifex Native uses ICU to mark your phrases in your code.

Regarding Fluent: Fluent is a modern, cutting-edge expressive language for localization. It’s Mozilla’s effort to add more expressiveness to ICU. One of its strengths is the ability to capture complex i18n cases. We included Fluent, together with ICU, in our consideration for our underlying i18n language, and eventually, we used ICU because it’s a more widely accepted standard with existing bindings.

Regarding Crowdin, Mediawiki, and Weblate: I am not aware of similar technologies from these platforms. Transifex Native includes a cloud-native i18n technology which, by default, syncs phrases to the cloud without requiring a local translation file (e.g. stored in git).

1 Like

@ujdhesa: That’s right. Translators contributing to existing projects are still able to use the file format the projects have chosen (e.g. PO). For projects using Transifex Native as their localization method, XLIFF is the default file format. I recorded your feedback, that translators would prefer to work on PO files, as I think it’d be interesting to allow translators to also export/import the translators as PO files, in addition to XLIFF.

Great explanation, thanks.

1 Like