• 1
  • 3
  • 4
  • 5
  • 6(current)
  • 7
State of the translation
#76
ventech Wrote:However, with respect to addons, being in the official repo is optional and there's already lots of rules in place for this repo. Will adding a few more make any difference?
Call it package translations like ubuntu if you like: You can translate your addon all you want but it wont necessarily be a part of xbmc. Translations in the addon repo are considered part of xbmc and thus distributed separately. Sure, someone is not going to like it but the same can be said for all the other rules.

I really hope that this time, I can handle addons translations in Transifex. Under a different project, but with shared translation memeory. This can be done in Transifex. That is what I am planning. It will be a hell of a work to put it together and update, but I am willing to undertake this job.

ventech Wrote:Another thing that i don't think has been mentioned is how are you going to handle upstream changes? for instance, when a translation is updated in transifex, and the addon maintainer do changes without pulling from main repo, who wins? If you distinguish between upstream and package, the obliviously package trumps upstream.

This is exactly why we need to have an ability to update Transifex with the upstream language files as well, not only the source English file. This time the upstream change will immediately go into Transifex so translators there can see it. Obviously they will show up as new TRANSLATED strings so there will be no big trouble for the translators.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#77
alanwww1 Wrote:This is exactly why we need to have an ability to update Transifex with the upstream language files as well, not only the source English file. This time the upstream change will immediately go into Transifex so translators there can see it. Obviously they will show up as new TRANSLATED strings so there will be no big trouble for the translators.
I mean if someone change a translation in transifex, call it string (a), and this propagates to the xbmc repo. Then someone change some other translation based on up to date upstream (addon development repo), but not up to date downstream (xbmc addon repo). When you are going to pull from upstream, you either you have a conflict or you cant determine if upstream changed string (a) back. Right?
Reply
#78
alanwww1 Wrote:Of course I'd need to discuss this with the team, but how about having the original English string in the language xml files. Like this:

<string id="7" source="File manager">Fájlkezelő</string>

I would love that.
Reply
#79
Just to show what it would look like, I updated my test project with all addons included in core xbmc git, with all available languages:

https://www.transifex.net/projects/p/mytest55/

Doing this, I noticed two addon translations are not utf-8 but latin-1:

https://raw.github.com/xbmc/xbmc/master/...trings.xml
https://raw.github.com/xbmc/xbmc/master/...trings.xml

Those should be fixed.
Reply
#80
viljoviitanen Wrote:Just to show what it would look like, I updated my test project with all addons included in core xbmc git, with all available languages:

https://www.transifex.net/projects/p/mytest55/

Doing this, I noticed two addon translations are not utf-8 but latin-1:

https://raw.github.com/xbmc/xbmc/master/...trings.xml
https://raw.github.com/xbmc/xbmc/master/...trings.xml

Those should be fixed.

Thanks. No It can be clearly seen how bad the situation with addons is.

We need to convert all strings into utf8 for sure.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#81
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.

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.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#82
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 Wink

...

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.
Reply
#83
Regarding the Description and Summary from addon.xml - will these strings be available for translation?
Reply
#84
I'll try to solve that too.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#85
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?
Reply
#86
It is the addon system. Language files only get loaded when the addon is loaded.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#87
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.
Reply
#88
Ping to all those subscribed in this thread... http://forum.xbmc.org/showthread.php?tid=126925
Reply
#89
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..
Reply
#90
(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.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
  • 1
  • 3
  • 4
  • 5
  • 6(current)
  • 7

Logout Mark Read Team Forum Stats Members Help
State of the translation2