(2012-06-01 22:28)takoi Wrote: Since you mentioned plural and special plural support is the next step there's a couple of things I find, as a translator, will make it a lot easier to work with the translations, perhaps more than the occupational lack of plural. A basic context, like a path to the file it occurs, is on top of my wishlist, because the english language have so many different meanings it's almost always impossible to make a proper translation without searching the source code or opening up xbmc trying to find it. If you don't, it's just a wild guess. It leads to bad translations not knowing the context. To sum up:
- All strings should have a context description. A path to the file is fine
- There's string reuse a lot of places it shouldn't. It's causing bad translations and breaks geometry.
- String tokenization. It should never be done. No exceptions. Xbmc has a lot of these, and I've even seen it being added new one recently. Perhaps this haven't been communicated..
- A lot of unused strings (string keys will fix this)
- The whole weather thing
Although as a translator I totally agree with all your points, I'm afraid, .po files are more prone to string re-use due to the requirement that all source stings in a .po file must be unique. No duplicates like in XML language files (e.g. 2 identical English strings with different IDs but for different context) are allowed. All tools for processing .po files, including Transifex, immediately show error message when source string duplicates are found.
E.g. this is a big problem for the current PVR branch from opdenkamp - the English .po converted directly from XML has duplicates and because of that cannot be translated by .po processing tools until all duplicates are removed.

![[Image: badge.gif]](http://www.ohloh.net/projects/9132/badge.gif)
Search
Help