Uploading strings in non-en-US locale

Issue #15 wontfix
Zibi Braniecki
created an issue

We do not cover scenario in which a jetpack is originally written in a language different than en-US.

We should support this. To make things easier we probably should recognize a different locale, offer translation to en-US and once we have en-US translation offer it to other locales.

Comments (2)

  1. Serafeim Mellos

    Hm, this might be a bit tricky to implement.

    Currently, throughout Transifex, we have the source language of the string tightly coupled with the resource. To make a resource accept and handle multilingual source strings probably requires a rewrite of quite a big chunk of Transifex.

    As I see it, the easier way to support non en-US jetpacks is to have something like intermediate resources which will handle the localization from the source language to en-US and when this is completed, the strings could be added to the main resource with the rest of the jetpacks. This will of course require a different resource for each source language but this could be hidden from the user somehow in the UI.

    The other options include modifying Transifex to accept multilingual source strings under the same resource or if we go on with the moving of the Jetpacks into their own models, we could add a source language in there as a field and organize strings under the Jetpacks (of course this may be much harder due to the commonpool since we don't want duplication of the strings under each jetpack).

    I'll have a look in the code and try to see if there is any other solution to this issue.

  2. Log in to comment