State of the translation

Guys, I have some good news ! I presented the proposed solution for the whole team including the developers.

No objections were raised, some of the members actually loved it :-)

So the modifications we can do:

For the source English file we can have it like this:

For the translation files we can have them like this.

@Viljo: Can you help me create a py script which fetches the English source string at specific revision, and also fetches the language file at latest git revision and creates the new language strings.xml file like the second sample format.

Also would be good if you could modify the source xliff creation script to be able to use the context attribute field I presented in the first sample format.

Well the best would be if we could implement to read these new format files in Transifex. As the xliff parser is pretty simple http://code.indifex.com/transifex/src/02...s/xliff.py we could directly use these new format xml files as we now have in one xml file the source and target not like before.

Viljo, can you help out, or should I start them it in C++ ?

Thanks in advance

ps.: I had Transifex working quite well on Fedora 16 using the current snapshot. I modified the Google shared doc, how I did it. I don't want to run it on a server, but for maybe implementing a native new xbmc strings.xml format it is needed to test the parser before we send to the Transifex developers.

alanwww1 Wrote:Guys, I have some good news ! I presented the proposed solution for the whole team including the developers.

No objections were raised, some of the members actually loved it :-)

So the modifications we can do:

For the source English file we can have it like this:

Code:

<string id="392" context="Weather addon, chance of rain">Medium</string>

For the translation files we can have them like this.

Code:

<string id="392" source="Medium">Közepes</string>

@Viljo: Can you help me create a py script which fetches the English source string at specific revision, and also fetches the language file at latest git revision and creates the new language strings.xml file like the second sample format.

Also would be good if you could modify the source xliff creation script to be able to use the context attribute field I presented in the first sample format.

No problem, I'll try to take a look tonight (european time).

alanwww1 Wrote:Well the best would be if we could implement to read these new format files in Transifex. As the xliff parser is pretty simple http://code.indifex.com/transifex/src/02...s/xliff.py we could directly use these new format xml files as we now have in one xml file the source and target not like before.

Viljo, can you help out, or should I start them it in C++ ?

Thanks in advance

ps.: I had Transifex working quite well on Fedora 16 using the current snapshot. I modified the Google shared doc, how I did it. I don't want to run it on a server, but for maybe implementing a native new xbmc strings.xml format it is needed to test the parser before we send to the Transifex developers.

I still don't like the idea of adding xbmc strings.xml support in transifex. You need some arguments to explain why it would be better to do a native transifex parser, as opposed to just converting on the fly (which is what I've already done, the above modifications are easy to do). We also probably have very different ideas of what's simple as to me that transifex xliff.py sure doesn't seem simple at all and I would rather not try to work with that to create a similar parser that deals with xbmc strings.xml files. I'd rather not know anything about transifex internals - they are likely to change, xliff files are not. Also I would think that long term goal in xbmc MUST be to get rid of the current "ad hoc" strings.xml solution and start using some proper stuff other people too are using.

Anyway I could also try to figure out the "web hook" apis of both transifex and github and how they are used to set up a demo site with full integration between transifex, an intermediate translation repo and an "origin" repo (I'll just fork xbmc on github...) as discussed earlier in the thread. That stuff is interesting, doing parsers in python is not

...

About the context strings - how about using transifex to collect them, creating a separate project with only one "translation" which actually is the context? When "enough" context strings are collected, I can easily prepare a new strings.xml file with the context attributes added (it's essentially the same tool that's used to create the translation files with source in an attribute, but used in reverse...) Typing all those with text editors direct in xml is just something I would not recommend. I would also suggest at the same time to get rid of the current comments in the strings.xml file, and add them in the context attribute.

Regarding the Description and Summary from addon.xml - will these strings be available for translation?

I'll try to solve that too.

I was wondering if they are ment to be translated why they are in a separate file?
When translating by hand it is annoing to monitor 2 files per addon. When compearing new to the old versions i will be notified that addon.xml is changed - because the vesion bump and so on even if there is no change in the english strings.
Why not move these strings into the .xml files that hold the strings which should be translated by the translators?

It is the addon system. Language files only get loaded when the addon is loaded.

alanwww1 Wrote:It is the addon system. Language files only get loaded when the addon is loaded.

Well it COULD be done so that description is inside addon strings.xml, and then manually (or automatically by the repo building scripts or whatever) copied to the description xml that's loaded when browsing available addons. (The string would then be in two places, and technically not used by xbmc at all in the addon strings file.)

Btw, individual addon developers could actually already do it this way if they wanted. But since there has not been a central translation system before, it would not help much if addon descriptions were in the strings.xml file and it would make things a bit more complicated for the developer (and to me it seems not many addon developers care much about translations, because it's so hard getting them done in the first place and after that keeping translations in sync).

Monitoring files manually (and trying to figure out the needed new/changed strings) anyway is stupid, that's one reason there is a need for getting the system better. It has been discussed before, and actually to me that seems one of the most important reasons, if not the most important reason why the translation system needs improving. The very first tool I presented in the first post of this thread kind of tried to address this... but obviously it could not detect changed strings, just missing ones. The other reason is the "crowdsourcing" thing, making contributing to translations easy for anyone.

Ping to all those subscribed in this thread... http://forum.xbmc.org/showthread.php?tid=126925

So, how are you able to accept addon translation from both git and this new translation system safely without tracking both of them via vcs?. I still dont see how it's even possible to do, so im fearing a lot of "unintentional destroying of translation" happening. Enlighten me..

(2012-03-28 15:52)ventech Wrote:  So, how are you able to accept addon translation from both git and this new translation system safely without tracking both of them via vcs?. I still dont see how it's even possible to do, so im fearing a lot of "unintentional destroying of translation" happening. Enlighten me..

Only the English strings will be updated at xbmc master repos. These will be constantly monitored by Transifex for changes. The translated strings will only be updated pulling from Transifex daily to a translation git repo. From here, we can update the language files from time to time in one batch.