[viljoviitanen]

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...)