Attention ALL translators

So, if I understand this correctly, it's not really using gettext. The old xml ids are simply put in a comment in the .po files, and xbmc reads the string by this id while the actual msgid is completely ignored. Seams fragile; and it's a custom format, so I really don't understand why you call it gettext and .po files..

Nope...the old ID is commented out...
XBMC takes the mesgid and converts the string to the msgstr based on regional settings...

At least it's that way if I got it correct

BTW:

(2012-05-07 20:56)Roman_V_M Wrote:  I'm worse than a noob in programming, but VC 2010 displays an error when trying to compile a build due to an ablolute path in \vc_project\libiconv\relocatable.c, line #29:

Code:

#include "C:\Users\Atti\xbmc-xml2po\vc_project\libiconv\include\config.h"

When I've changed the path to the actual location of the file in question, I've been able to compile xbmc-xml2po.exe that seems to work.

Yeah, came around that, too...
Submitted PR for xml2po for alanwww1's GIT in order to fix this...

(2012-05-07 22:48)mad-max Wrote:  Nope...the old ID is commented out...
XBMC takes the mesgid and converts the string to the msgstr based on regional settings...

At least it's that way if I got it correct

Well, as per latest commit yesterday; removing the comment, and the string disappears; changing msgid and it stays the same

Hmm that's odd...
Let's wait for alamwww to enlighten us...

(2012-05-07 22:39)takoi Wrote:  So, if I understand this correctly, it's not really using gettext. The old xml ids are simply put in a comment in the .po files, and xbmc reads the string by this id while the actual msgid is completely ignored. Seams fragile; and it's a custom format, so I really don't understand why you call it gettext and .po files..

@takoi

We need to get use of the old system at first stage.
Just imagine what it would take to convert ALL language calls in XBMC to convert them to gettext() calls in ONE STEP !
If you can do it, while the code still needs to be working all the time, than your help is more than welcome here.

The final goal is to have most calls with native gettext calls, but that is still a long long way to go (at least without your help).
Note that we have several ways of calling GetLocalizeStrings() function.

1. Core c++ calls
2. Through skin xml files
3. Python addon scripts
4. Weather Tokenization
5. and so on.

All in all at translator point of you, this does not matter at all. Transifex will be up and working. The change of the calls in the code won't ever gets shown to the translators and will be transparent. The system will work.

So if you want to help to make this job to convert all calls to gettext() calls, just let me know !

Cheers, Attila

(2012-05-07 23:07)mad-max Wrote:  BTW:

(2012-05-07 20:56)Roman_V_M Wrote:  I'm worse than a noob in programming, but VC 2010 displays an error when trying to compile a build due to an ablolute path in \vc_project\libiconv\relocatable.c, line #29:

Code:

#include "C:\Users\Atti\xbmc-xml2po\vc_project\libiconv\include\config.h"

When I've changed the path to the actual location of the file in question, I've been able to compile xbmc-xml2po.exe that seems to work.

Yeah, came around that, too...
Submitted PR for xml2po for alanwww1's GIT in order to fix this...

FYI I made precompiled builds for windows https://github.com/alanwww1/xbmc-xml2po/downloads

BTW, what about translation for individual plug-ins that are not a part of the core XBMC project? How will those translations be maintained? Or this will be completely up to individual authors how they choose to maintain translations for their plug-ins and/or forked projects?

(2012-05-08 11:21)Roman_V_M Wrote:  BTW, what about translation for individual plug-ins that are not a part of the core XBMC project? How will those translations be maintained? Or this will be completely up to individual authors how they choose to maintain translations for their plug-ins and/or forked projects?

I plan to maintain a Translation github repository for ALL plugin developers, where they can easy pull in the fresh translations to their upstream repo.

This will be a second step after core and Confluence is up.

(2012-05-08 09:19)alanwww1 Wrote:  

(2012-05-07 22:39)takoi Wrote:  So, if I understand this correctly, it's not really using gettext. The old xml ids are simply put in a comment in the .po files, and xbmc reads the string by this id while the actual msgid is completely ignored. Seams fragile; and it's a custom format, so I really don't understand why you call it gettext and .po files..

@takoi

We need to get use of the old system at first stage.
Just imagine what it would take to convert ALL language calls in XBMC to convert them to gettext() calls in ONE STEP !
If you can do it, while the code still needs to be working all the time, than your help is more than welcome here.

The final goal is to have most calls with native gettext calls, but that is still a long long way to go (at least without your help).
Note that we have several ways of calling GetLocalizeStrings() function.

1. Core c++ calls
2. Through skin xml files
3. Python addon scripts
4. Weather Tokenization
5. and so on.

All in all at translator point of you, this does not matter at all. Transifex will be up and working. The change of the calls in the code won't ever gets shown to the translators and will be transparent. The system will work.

So if you want to help to make this job to convert all calls to gettext() calls, just let me know !

Cheers, Attila

No no, i understand incremental development. Just wanted to know there was a plan to remove the integer system completely. Btw is the GetLocalizeStrings function that takes string as input implemented? Then i could probably help out with some of this..

---

(2012-05-08 12:17)alanwww1 Wrote:  

(2012-05-08 11:21)Roman_V_M Wrote:  BTW, what about translation for individual plug-ins that are not a part of the core XBMC project? How will those translations be maintained? Or this will be completely up to individual authors how they choose to maintain translations for their plug-ins and/or forked projects?

I plan to maintain a Translation github repository for ALL plugin developers, where they can easy pull in the fresh translations to their upstream repo.

This will be a second step after core and Confluence is up.

So you will mirror only the english strings from the official addon repo, then it will be up to the addon developers to choose to pull translations before sending pull request to addon repo. Correct?