[CutSickAss]

2) An even sillier question: Compiling xbmc-xml2po to an executable file using VC++ 2010 Express and mentioning it here, for example, would be considered distributing, and, therefore, in violation of the License Agreement, right? I suppose that is why no-one has done that.

Sorry, but what License Agreement you are talking about? AFAIU, xbmc-xml2po is open source under GPL or something like that.

In my example I mentioned compiling the executable with Microsoft VC++ 2010, which is free to use, provided you don't create any commercial programs, I mean with intent to distribute (VC++ License Agreement).

[mad-max]

2) An even sillier question: Compiling xbmc-xml2po to an executable file using VC++ 2010 Express and mentioning it here, for example, would be considered distributing, and, therefore, in violation of the License Agreement, right? I suppose that is why no-one has done that.

Sorry man, but this made me smile a bit...
Why should it be illegal to distribute it?
You also compile XBMC with VC++ 2010...

BTW: You mentioned a PR for GIT?!?! Can we already submit changed po files or do we have to wait for transifex?
I have a new version of strings file in my local GIT, too...
If we can submit PR, I would do this, too...
Attila, any opinion?

mad-max

[CutSickAss]

2) An even sillier question: Compiling xbmc-xml2po to an executable file using VC++ 2010 Express and mentioning it here, for example, would be considered distributing, and, therefore, in violation of the License Agreement, right? I suppose that is why no-one has done that.

Sorry man, but this made me smile a bit...
Why should it be illegal to distribute it?
You also compile XBMC with VC++ 2010...

BTW: You mentioned a PR for GIT?!?! Can we already submit changed po files or do we have to wait for transifex?
I have a new version of strings file in my local GIT, too...
If we can submit PR, I would do this, too...
Attila, any opinion?

mad-max

That is why I opened with "An even sillier question", I also thought it would sound too dumb...
My reasoning was that compiling XBMC for myself is legal since I do not distribute it to anyone else. Also, my guess is that someone in the XBMC Team has VC++ Full Edition (or whatever is called), and is therefore eligible to compile XBMC for distr... eh, whatever, your answer is OK!

Regarding github, I "casually" mentioned I would be making a PR later tonight to see if anyone would object to that!
But truth be told, I wasn't going to do anything without confirmation it's OK to edit the strings.po files. It makes sense we should wait for the transifex move.

[Roman_V_M]

In my example I mentioned compiling the executable with Microsoft VC++ 2010, which is free to use, provided you don't create any commercial programs, I mean with intent to distribute (VC++ License Agreement).

That's a new. AFAIK there is no such limitations, provided that VC++ 2010 Express is properly registered (which is a free procedure).

[mad-max]

Regarding github, I "casually" mentioned I would be making a PR later tonight to see if anyone would object to that!
But truth be told, I wasn't going to do anything without confirmation it's OK to edit the strings.po files. It makes sense we should wait for the transifex move.

Hmm..ok...so my branch is ready...simply need to push the "submit" button for a PR...
Will hold on until Attila has come with an opinion...
Although it wouldn't harm or break anything...

mad-max

[takoi]

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

[mad-max]

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

[mad-max]

BTW:

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

[takoi]

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

[mad-max]

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

[alanwww1]

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

[alanwww1]

BTW:

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

[Roman_V_M]

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?

[alanwww1]

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.

[takoi]

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

---

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?