Updating translation strings in lang files from code

[jguille2]

I see lang-de.js is not synchronized with code strings.

I can use lang-pt.js like a template (with 248 extra strings) to achieve a better translation... but I know it is not the right way.

I can try working with this to bring something useful. First thoughts:

• We need a lang.js as a template for translations. Only with the English strings. Easier to update from any developer, adding and updating code strings.
• What would be the correct strings order? Themes or categories seems best... but we use the same strings in different places. We could order them alphabetically.
• We can add comments to string lines. We can annotate the file (or files) where they appear, or we can annotate the category (tabs, editor, menu...)

In any case, I offer to work on this topic and follow your indications.

Joan

[DyslexicAwe]

@jguille2 Wow, that would be an awesome Seasons Holiday gift for all translators. Until now, changing an existing lang-LL.js was not an easy task and sometimes it just didn't work and I had no clue why it didn't work.

[jguille2]

First of all, I try to develop a proposal and wait for your feedback... then I can do the job according to your instructions.

Excuse my non-first-class English language :(. Luckily, this is an asynchronous issue (I can use more time to do my best)... and I trust your patience to fix this (my) poor bug :))

Goals

Two main goals for our translation system:

• Make it easier to build and update translations.

  • Build a simple system.
  • Keep translation files synchronized with code.
  • Allow and encorage the maximum number of languages (with full or partial translations).

• Allow developers to change strings in code when refining or improving features... without being tied to an excessively rigid structure.

Proposals

1. Build a lang-en.js as the master template. English to English translation

   • All developers and helpers could directly update it, with the code changes.
   • Easier to spread changes. Partial translations will be copies from this template (with all the strings) that can be easily updated (only editing text).
   • English language could be refined without code changes (English code to English lang). This will not be the standard way, but an easy possibility. Some times, our free translations are more refined than the English one (chained to the system).

2. lang-en.js (and the other lang files) can have all the strings in alphabetical order.

   • I like a thematic distribution (menu, blocks...) but strings can live in different scenarios.
   • Easier to developers to use existing strings, avoid collisions...
   • Maybe one line per string is better (although they'll be longer)
   • We can comment lines to add info. Source file, function... or only a counter of uses (to help developers to delete lang strigs after code modifications).

3. Make an updater script to run it locally.

   • The script creates all new lang-xx.js files, copying from lang-en.js source and updating values from last lang-xx.js.
   • Then, each lang-xx.js file will have all the strings updated. New strings with their English value, and the others with their own (translated or not). Deleted strings will be out.
   • We don't need a dynamic update. We can run this script before releases if there have been changes in lang-en.js

More...

• In the future, we can build a web service for tranlators. A web form to update lang-xx.js files is easy. Another thing is web, users... First the forum!!!
• We can build an extra option to the updater script to make some special changes. For example, if you want to change "Cancel" to "Close", we can make the change and update lang files assigning "Cancel translations" to "Close string". Then we can make necessary changes without a great translation problem.

I wait your feedbacks. Thanks!

Joan

[jguille2]

Hi! I was working into this. I still have only a draft (you can see here) but I want to share this with you... waiting your feedback and directions.

I think hte issue is better explained in the last post, but I try to explicit some things to encourage discussion.

This proposal is not a real change (not a pot system...), more a methodological issue... but I think it can help us.

Some points ...

• lang-en.js like the master template. It can be the real English implementation... or only a template to build the other language files.
• All lang-xx.js will be copies from the master template (with the same code strings) keeping translation work in past versions.
• Alphabetical order. For me it's ok in all cases. If you want keeping 'themes' distribution, only in 'master template'. Language packs will be in alphabetical (to ensure a coherent construction).
• Automation of the process. To save time and maintain synchronization.

Examples and draft work...

• You can see a draft version for a Snap! translation tool.
• Now I can build the master lang-en.js from any language file. I use Catalan translation (with 800 strings) to build this.
• Then, with the template (en) created we can build all 38 language files with a click. All files will have these 800 strings and we'll reuse translated strings from last versions. For example, it is lang-de.js builded.

I wait your feedback... Thanks,

Joan

[DyslexicAwe]

Great idea for translators and I hope it will succeed.

Examples and draft work...

• You can see a draft version for a Snap! translation tool.
• Now I can build the master lang-en.js from any language file. I used Catalan translation (with 800 strings) to build this.

I don't quite understand where did the 800 strings come from? Did you manually collect those 800 strings from the code, or did you find them already in lang-pt.js (if so, how they got there in the first place)? And in future, are only lang-XX.js files going to be updated to reflect the changes in the master template? Or will ( after the code changes will be made for next version of Snap! by Jens, and your tool will be run to do what it does ) the master template lang-en.js be (or not be) synchronized with the code changes again? I guess not.

I'm just curious :-)

[jguille2]

Hi @DyslexicAwe,

• Catalan version has now 800 strings. 531 are just collected in lang-de, Portuguese translation file has 244 more strings, and I found 25 extra strings from code. Maybe there are more strings (although I haven't seen more playing Snap!) and maybe some strings are old (out of code).
• This issue is only a proposal (it needs Jens blessing) about our translation organization. And the script is only a tool to avoid manual work (repetitive, heavy... and often non accurate). Now we can build with a click all 38 language files, with the 800 strings updated and loading all strings translations from last lang-xx.js files.
• I've documented and shared the script (a draft version... I 'll try to polish it) ... to anybody... But really I can begin the work of updating lang files to achieve translations easier.

@jmoenig, Do you want I update all lang-xx.js files? The behaviour will not change compared to the current... but all files will have these 800 strings. You can check the result in the lang-de.js example. If you are agree that lang-en.js will be the master template and you prefer the actual structure (sorted by themes) I will build a lang-en.js with the themed structure (like actual catalan file) and all the other translation files will have the alphabetical non commented order.

Or you can ask me for another proposal and I will be working on it.

Joan

[jmoenig]

Hi @jguille2 , from what I understand this sounds like a great proposal to harmonize translations and help translators stay abreast of new strings as they are introduced. I'd love to learn more and perhaps discuss this with you in person. Maybe we can find some time in January for a Skype call?

[jguille2]

Ok @jmoenig I'll send you a mail and we'll see...

For translators who want to update their language (@DyslexicAwe told about "an awesome Seasons Holiday gift for all translators")... they can run the script...but I could also send an updated file to them...

But until we close this issue and decide the file format, I think they should continue with the traditional method. They can take the lang-ca.js as a template to have the maximum translatable strings in their language.