+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Translations and Language Files (/forumdisplay.php?fid=90)
+--- Thread: State of the translation (/showthread.php?tid=118978)
- alanwww1 - 2012-02-05 01:33
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>
Just like "standard" translation files. This way we could write a custom parser for Transifex and we would't need a separate xlif file.
- viljoviitanen - 2012-02-05 22:33
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>
Just like "standard" translation files. This way we could write a custom parser for Transifex and we would't need a separate xlif file.
I still don't think it's a good idea to write a parser module in transifex, we gain essentially nothing and it's harder to do that way (auto-update of source file is so small a gain I don't count it at all cause it's trivial to do with the api, and more real time too because we can use github hooks). And we aren't really needing the xliff files as such, the idea is to generate them "on the fly" when using the api and just discard them after the api call. (as I noted before, they can be mapped 1:1 so no information is lost converting back and forth.)
Anyway I'm really not sure what adding source strings in xbmc xml accomplishes - does it help with the "changed meaning" scenario? Because in any case since xbmc is using only the id, if you do not invalidate the old translation, xbmc is using the old translation and transifex too gets updated with the old translation. And if/when a translation is invalidated, we will need some mechanism that allows strings needing retranslation detected. I think best would be to just add new id's.
About id's: I think it's "foobared up" the id's are thought to have some meaning (==i.e. derive context from id number, or have a need to re-use them), they should be just random numbers, like uuid, having no "internal" meaning. I can rewrite my tools easily to preserve the xml order. Now I've just done them the easiest way possible, not caring about order internally at all, using a python "dictionary" (similar to perl hash), and at output sort by id numerical value (this is just kind of a left-over from my first tool that detected incomplete translations...)
- takoi - 2012-02-05 22:49
Why did we need importing again?
- alanwww1 - 2012-02-06 00:55
viljoviitanen Wrote:Anyway I'm really not sure what adding source strings in xbmc xml accomplishes - does it help with the "changed meaning" scenario? Because in any case since xbmc is using only the id, if you do not invalidate the old translation, xbmc is using the old translation and transifex too gets updated with the old translation. And if/when a translation is invalidated, we will need some mechanism that allows strings needing retranslation detected. I think best would be to just add new id's.
As I see, this is now the only way of handling the "changed meaning" problem. Either to store the used source string in a backup xml or xlif file or to put them inside the original ones,
ventech Wrote:Why did we need importing again?
Guys, I want to make the best possible solution here which is both acceptable for translators and developers. There are a lot of commits when developers change refine etc. the meaning of the string. Also when a non-English speaking developer commits something, he will do his language translation already on GIT. He won't be waiting for things to go through Transifex and translate there. Specially I am thinking of addon developers who develop, test commit to git in the most cases two languages. English +1. So we do need the ability to updated Transifex translations from git sometimes.
- takoi - 2012-02-06 19:48
Ok, I see your point. Actually, im one of those committing English+1 for addons. (for xbmc patches i dont think the reviewer will even let you do that in the same commit) 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.
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.
- alanwww1 - 2012-02-06 20:36
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.
- takoi - 2012-02-06 21:03
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?
- NEOhidra - 2012-02-06 22:51
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.
- viljoviitanen - 2012-02-06 23:08
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/addons/metadata.artists.allmusic.com/resources/language/German/strings.xml
https://raw.github.com/xbmc/xbmc/master/addons/metadata.tvdb.com/resources/language/Spanish/strings.xml
Those should be fixed.
- alanwww1 - 2012-02-06 23:21
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/addons/metadata.artists.allmusic.com/resources/language/German/strings.xml
https://raw.github.com/xbmc/xbmc/master/addons/metadata.tvdb.com/resources/language/Spanish/strings.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.