[alanwww1]

The occurences field seems to empty for almost everything. You know about this alan or is it an error? Actually, I can only find a single string that has it: the one shown on the wiki page..

This and the commenting is a brand new "feature" which comes from the new PO format we use. We try to fill out these helper strings for future strings and also make some comments for older strings which are hard to understand without a comment.

Also plural forms are coming to the translations soon (my next gig task to do :-) )

[takoi]

The occurences field seems to empty for almost everything. You know about this alan or is it an error? Actually, I can only find a single string that has it: the one shown on the wiki page..

This and the commenting is a brand new "feature" which comes from the new PO format we use. We try to fill out these helper strings for future strings and also make some comments for older strings which are hard to understand without a comment.

Also plural forms are coming to the translations soon (my next gig task to do :-) )

So the paths are manually typed? I imagine those will quickly get unmaintained. This could be generated. like gettext does..

[alanwww1]

The occurences field seems to empty for almost everything. You know about this alan or is it an error? Actually, I can only find a single string that has it: the one shown on the wiki page..

This and the commenting is a brand new "feature" which comes from the new PO format we use. We try to fill out these helper strings for future strings and also make some comments for older strings which are hard to understand without a comment.

Also plural forms are coming to the translations soon (my next gig task to do :-) )

So the paths are manually typed? I imagine those will quickly get unmaintained. This could be generated. like gettext does..

A tool for this is welcome !
I might write one later, if I have time, but I still have a lot other stuff to finish.

[takoi]

This and the commenting is a brand new "feature" which comes from the new PO format we use. We try to fill out these helper strings for future strings and also make some comments for older strings which are hard to understand without a comment.

Also plural forms are coming to the translations soon (my next gig task to do :-) )

So the paths are manually typed? I imagine those will quickly get unmaintained. This could be generated. like gettext does..

A tool for this is welcome !
I might write one later, if I have time, but I still have a lot other stuff to finish.

Could probably make something that does the most common cases, but this would be a lot easier if string keys were done first. Then its just a simple search..

[takoi]

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

[Roman_V_M]

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.

[jmarshall]

There's only a duplicate if both context and string matches. .po files have the context for just this reason, as two identical English words may well be different words in other languages.

[alanwww1]

I promised Lars to convert and update the PVR branch strings soon. There is no problem with that at all.
But first I need to finish my update tool which pulls fresh translations to a local repo updates addon.xml files as well so that I can update the language files in master.

[Wanilton]

@alanwww1, my question is, translators take the po file for an addon or a skin, translate into other languages, for xbmc frodo, perfect, but what will happen to users of Eden, the xbmc this case does not support yet the po file, is there any tool that converts the po file to XML, to avoid having to create such an XML file for the users XBMC eden, in my case, I think I have a po file in English that will be translated into other languages ​​via Transifex, but ask the translator to make xml file with the same translation for Eden is counterproductive. Can you clarify whether there is plan out in support for Eden po files, and how soon will it be?

[alanwww1]

@alanwww1, my question is, translators take the po file for an addon or a skin, translate into other languages, for xbmc frodo, perfect, but what will happen to users of Eden, the xbmc this case does not support yet the po file, is there any tool that converts the po file to XML, to avoid having to create such an XML file for the users XBMC eden, in my case, I think I have a po file in English that will be translated into other languages ​​via Transifex, but ask the translator to make xml file with the same translation for Eden is counterproductive. Can you clarify whether there is plan out in support for Eden po files, and how soon will it be?

Well there are plans to make this into a service release, but my time is very limited so I am not sure about this at the moment.

Edit: I'd also like to see how this works out in real life (I mean updates and stuff) than I have to make the addons project. After than I'll deal with plurals, native gettext calls and after that I can start dealing with this. Might be that we have Frodo ready be that time :-)

[takoi]

Am I missing something or are all of these strings unused?

Code:

31001
31002
31007
31020
31021
31030
31046
31047
31113
31114
31115
31120
31201
31202
31204
31302
31304
31305
31306
31315
31318
31323
31324
31409
31900
31907

Went through the confluence translation but didn't get any hit when searching for these. 27 out of 147 being leftovers is ridiculous. I can only imagine how many of these there are in core.. If this is the case, that these are unused, i hope something will be done about it because this is a waste of translators time.

[Wanilton]

@alanwww1, well understand your info about po file use in Eden, I believe one simple app, converting po file to xml file, solve my case, this is possible??

We have skin done with po file done, in English - perfect file for use with transifex and Frodo, but i need remember a lot of Eden users, in this case one tool converting format po file to xml, solve my case.
I think in a tool, similar make for convert xml-to-po, inverse in this case, po-to-xml...

Thanks, for great job,

Wanilton

[jmarshall]

@takoi: It wouldn't surprise me if it was that high. What would be a huge help is for the contexts to be done for all the strings you found - once the context clearly indicates where it's used, it's both useful to the translator (as you know where to look to see whether things fit etc) and also useful for developers when removing/replacing old strings as they know they are unused now. You can fill in something like "unused" for the ones that aren't done and I'm sure that Jezz_X will be happy to take a hunt through and confirm that they're unused, thus removing them.

Obviously this is a large job, but if everyone pitches in and just does a few each (just let us know which block you're doing), it won't take long before the whole lot are done.

@Attila: Does this sound like a plan?

Cheers,
Jonathan

[alanwww1]

@takoi: It wouldn't surprise me if it was that high. What would be a huge help is for the contexts to be done for all the strings you found - once the context clearly indicates where it's used, it's both useful to the translator (as you know where to look to see whether things fit etc) and also useful for developers when removing/replacing old strings as they know they are unused now. You can fill in something like "unused" for the ones that aren't done and I'm sure that Jezz_X will be happy to take a hunt through and confirm that they're unused, thus removing them.

Obviously this is a large job, but if everyone pitches in and just does a few each (just let us know which block you're doing), it won't take long before the whole lot are done.

@Attila: Does this sound like a plan?

Cheers,
Jonathan

This is exactly the plan. An ideal entry would look kike this.

Code:

#. play GUI sounds
#: xbmc/settings/GUISettings.cpp
msgctxt "#34122"
msgid "Always"
msgstr ""

Where:

Code:

#. Helper comment
#: occurence of the string
#: even more occurences in case
msgctxt "#ID"
msgid "Source string"
msgstr ""

I am planning to write a parser utility to extract at least the occurence of the string calls. The tricky thing is that we have several ways of passing the string id to the localization function. Sometimes it comes from a direct parameter, but sometimes it comes from an xml file or from other indirect calls.
So whenever I have time for it, I'll try do it.

[jmarshall]

Right - we can't yet replace msgctxt with something useful as we're still using the id's, so this is an interim measure.