Translations review

[kernc]

I don't think this kind of enumerated format for pages text is very extensible.

Suppose you, the upstream, add an English paragraph somewhere in between. You have to fix all the following labels, and any language extensions would have to add the new label as well. Additionally, if a downstream Chinese wants to add a paragraph or section for their users, how do they do it? What you're missing is the ability to transparently insert a piece of text only for some languages and not for others, e.g. an additional explanation for the Chinese, different disclaimer for the Africans, thorough insight for the Finns, ...

IMHO, it would be better if page labels were structured as: even better, see below.

...
text_gettingStarted: [
    'Preveden naslov 1',
    ['preveden odstavek 1', 'preveden odstavek 2', ...],
    'naslov 2',
    ...
],
...

This would have the potential to make different languages out of sync, but these are support information pages, and allowing for conditional presentation based on visitors' language is not something unexpected.

In general, the i18n system doesn't seem very modular and nice. The fact that keys are English labels repeated in full repulses me.

It's kind of late to provide that kind of feedback, but I'd like it better if only the bare-minimum requred translations were in the global language file. The rest being in their per-assignment modules. For example, some-assignment.html, almost self-contained:

<div class='i18n text'>
    <p data-lang="en">This is english translation.</p>
    <p data-lang="sl">To je slovenski prevod.</p>
</div>

This is, among other examples, how FreeDesktop does it (/usr/share/applications/*.desktop files).

[ddksr]

I think this kind of translations are state-of-the-art on the web:

• http://codex.wordpress.org/I18n_for_WordPress_Developers

They can bring many problems (as we can see with pages) but the model is solid and it isn't confusing for translators. The idea is like this: If a translator notices an untranslated text, he/she copies the text into the JSON and translates it there. This way we can always see from what the text is translated (no confusing keys etc.).
I don't agree that the FreeDesktop way is the best for every situation. I don't mind it in the Linux development cycle but on the web these kind of practices are fading away.

But you are right. There is a large issue with page translations. I can't use the whole page text as an translation key. This is probably something that should be discussed on a coffee or a skype call and then closed for ever. I would really love to hear all your comments about the model. Also, I would really like to defend some concepts I like. I think some common ground can be found here but we really need to discover and discuss it.

[ddksr]

Pages will be put in separate html files. The fallback files will be located in the pages directory and the translations in the lang directory. Probably.

[kernc]

What about new commands (and their help texts) that an assignment may introduce, where are those translated?

[ddksr]

I thought that I already implemented adding commands from assignments but
apparently I didn't. Will look into it and prepare a translation system
that will support this. Do you have any suggestions?

2014-01-28 kernc notifications@github.com

What about new commands (and their help texts) that an assignment may
introduce, where are those translated?

Reply to this email directly or view it on GitHubhttps://github.com//issues/34#issuecomment-33537083
.