State of the translation

Hi all.

Im not sure is this proper place, but I kind lost my way to in this thread

I was wondering in developement thread for some subtitle add-on developement, but my second nature is in translations.
So I decide wrote small "Hi for all".

I would like to participate translation tool developement and maybe give some effort of my programming and time.

Terve Viljo

Good springtime for all.

Hi Troopie !

Thanks for the offer !
I am deep into refactoring xbmc's internal language file parsing engine, so there I wouldn't need any help at the moment, but with the xbmc-xml2po tool it would be good if you guys could test it with various addons and have the output POT and PO files tested in Transifex. Also a simple gui would be nice. I was thinking of QT as it is cross platform.

The tool is here and for me works in Windows and Linux without major issues:

https://github.com/alanwww1/xbmc-xml2po

So I've implemented actual gettext support here and python interface here.

I'm starting to wonder if this have been though much through before jumping into it, because there's a few limitations:
- language files must be placed in a directory "nb/LC_MESSAGES" or "nb_NO/LC_MESSAGES" for example
- to be able to distribute translations along with addons, the .mo files must have a unique name i.e. <addon-id>.mo
- also, how should the binary .mo files be deployed? Generated by addon devs, or by xbmc on download?

(2012-05-09 12:35)takoi Wrote:  So I've implemented actual gettext support here and python interface here.

I'm starting to wonder if this have been though much through before jumping into it, because there's a few limitations:
- language files must be placed in a directory "nb/LC_MESSAGES" or "nb_NO/LC_MESSAGES" for example
- to be able to distribute translations along with addons, the .mo files must have a unique name i.e. <addon-id>.mo
- also, how should the binary .mo files be deployed? Generated by addon devs, or by xbmc on download?

We'll use a custom implementation using the PO files directly. Actually it will be read by the same parser already in mainline.
The hashing and storing in the memory will be done at runtime.

So, it will not be gettext after all. You've been referring to it as gettext, which is why i got confuse. So, your plan is to completely reimplement all the i18n features that gettext has been doing to like 10 years, instead of just using gettext. Not sure im convinced this is the best idea.

Just read your previous post and you see a few things why we are doing this. Also:

- To get use of the calls implemented with the XML system, in any case we would have to write a PO parser.
- Imagine what would a translator say if I am telling him to convert his translated PO file into an MO file to try it out.
- Different platforms handle gettext differently. Even the Local variable is handled differently.
- Gettext runtime without the includes is more than 700k of code. We have the PO parser currently with 324 lines of code.
https://github.com/xbmc/xbmc/blob/master...OUtils.cpp
- On Windows it is a PITA to compile gettext and has a lot of nice includes

This is just some of the reasons. There are others. Believe me, it was well considered.

Well, not in this thread at least. I just feel the same mistakes are being made over again. This whole thread has been about the old system was a bad idea from the beginning. Every one agrees on this. And now, instead of moving to proper i18n, it looks like the same system just replacing integer keys with string keys.

Sorry, but why is this bothering you so much ?
Are you regularly develop a lot of code for xbmc, so that this slows down your develop process ?

I mean from a translator point of you, everything is solved.

So sorry, but unless you actually want to help and have a working solution, please don't deprecate other's hard work which, actually helps end users and translators life and puts more work on himself.

And just a note: The calls will be the same as if we had libintl included. No difference in that. So gettext tools will be suitable for all kind of build and search functions.

I translate, and everything in i18n is definitely not solved. I'm sorry if i sounded deprecative, I didn't intend to, I very much appreciate the web translation system and everything, I do. It's a big step up for xbmc no doubt.

Glad to hear. And thanks for the translations.
I plan to extend capabilities of the system for paractically all things gettext knows.
For example, there will be plural form support. The parser is already prepared for that.
I think that is the only major missing thing at the moment. It will be again a big step. But only after we have Transifex up and going.
And of course you are invited in the translation team if you'd like to participate.