• 1
  • 2
  • 3(current)
  • 4
  • 5
  • 7
State of the translation
#31
Hi Viljo !

I made some tests with Transifex. I tried it with fedora 16 and Centos 6.2.

Well the latest Transifex 1.2.1 was not working so well despite that easy_install ran without an error I have some missing icons and the translatable strings does not get shown, despite that it is showing the available number of strings.

The older 1.1 version runs a lot better. No missing icons, translation and strings are working (at least with POT files), but I am also having some occasional error messages. And mailing is not working ( of course it is not, because I have not set up the emailing on the system)

I have an idea for setting up things after we figured out the web setup.We could have an intermediate git repository for storing/updating all strings.xml files and the converted PO/POT files. We can write some scripts which can run daily to pull in the upstream xml files convert them to pot files (Transifex does the rest, to automatically pull in the changed POT files and notice users about it) to make things into the other direction we can pull down the translated files with scripts to the intermediate git repo and convert them back to strings.xml for xbmc and addons. What do you think ?

By the way XML parsing is not working for me at least.

Should I send you the VirtualBOX files for testing ?

Cheers, Attila
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#32
What about writing xml parser extension for Transifex? I guess better then convert to pot then translate the convert it again to xml.
Reply
#33
queeup Wrote:What about writing xml parser extension for Transifex? I guess better then convert to pot then translate the convert it again to xml.

If we convert, we don't need any modifications in transifex. It's safer that way, we can be sure that when transifex is updated, the thing still works. I don't see any gains in writing a "native" parser for xbmc strings.

I'd also say converting is easier, too, as it can "just be done", no need to study transifex internals.
Reply
#34
Bahhh look how easy to write native xbmc parser:
examples:
http://code.indifex.com/transifex/change...6281c9ca87
http://code.indifex.com/transifex/change...3a225805aa
Reply
#35
Just so you know, there's a whole thread about converting xml to gettext somewhere. I worked on this myself and you can do it with the existing tool xml2po, however, it's a dead end because gettext is going to require you to provide a msgctxt tag for each duplicate entry, and there's a lot them in xbmc! Also you are going to have to take care of "storing" the xml ids somewhere yourself.

But perhaps the most important thing is that you'll loose the id ordering in the xml files. Because of all the string fragmentation and how the ids are divided in chunks, it's very important for translators that this order is kept.
Reply
#36
How about Pootle - a web-based translation tool.

I am not aware of the features that transifex provides nor what special needs the devs have - just wanted to suggest it.
Reply
#37
ventech Wrote:But perhaps the most important thing is that you'll loose the id ordering in the xml files. Because of all the string fragmentation and how the ids are divided in chunks, it's very important for translators that this order is kept.

We need to write a custom utility where all fields filled out properly. And also string_ids are handled. In this case I don't see the problem. Transfifax uses its own databse engine and format to handle strings anyway.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#38
NEOhidra Wrote:How about Pootle - a web-based translation tool.

Transifax was not a bad suggestion. Has a lot of potential. I will also try pootle. Thanks for the suggestions.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#39
Hey all,

Now that I've taken a look at transifex documentation, I think best would be to use the transifex api to do the day to day updating from and to xbmc string files:

http://help.transifex.net/features/api/api-v2.html

There's some testing to do obviously, the docs don't tell much about the json. But I think it's easy enough to find out.

And if we were REALLY clever, we'd make the updates realtime from git with github hooks: http://help.github.com/post-receive-hooks/ (and detect language related pushes and then make the update) . But maybe for starters we'll do updates just from cronjobs...
Reply
#40
@Viljo

I think we should try Transifex and Pootle in real life situation.

I've just tried Pootle and the interface is a little simpler, but seems more stable and with much less fuss to install. Well actually it was:

Code:
yum install pootle.noarch
PootleServer --port=8000

It makes a demo (Gnome) translation project this way which you can test.

Also if we can not use xml as a native format, I checked that we can you XLIFF instead of POT. It has an ID based structure, similar to xbmc and Context hints can be inserted easily. XLIFF is well supprted by both Transifex and Pootle.

Edit: Even email confirmation is working. :-) Out of the box.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#41
alanwww1 Wrote:Hi Viljo !

I made some tests with Transifex. I tried it with fedora 16 and Centos 6.2.

...

Should I send you the VirtualBOX files for testing ?

Cheers, Attila


I don't have virtualbox installed anywhere and the image files are unnecessarily large anyway...

I'll take a look at setting up transifex on my amazon ec2 server.
Reply
#42
alanwww1 Wrote:@Viljo

I think we should try Transifex and Pootle in real life situation.

I've just tried Pootle and the interface is a little simpler, but seems more stable and with much less fuss to install. Well actually it was:

Code:
yum install pootle.noarch
PootleServer --port=8000

It makes a demo (Gnome) translation project this way which you can test.

Also if we can not use xml as a native format, I checked that we can you XLIFF instead of POT. It has an ID based structure, similar to xbmc and Context hints can be inserted easily. XLIFF is well supprted by both Transifex and Pootle.

But does pootle have an api? I still think doing the integration directly with transifex api would make many things quite easy and straightforward as opposed to converting both ways...
Reply
#43
So guys, lets just take a step back and think about the real issue here. I just need this to being said: The core to all of the problems discussed in this thread remains the same: the poor internationalization support in xbmc. Even if someone were to write the parser/converter/infrastructure and all that you're still stuck with a program where lot of parts aren't even internationalizationable. For this to happen the key/value xml system needs to go in favor of a proper i18n tool. It most definitely isn't going to be an easy task, but it needs to be done sometime.
My point is: if this were to be done, then everything else discussed here will fix itself. All the tools for translating, syncing, deploying are already in place.
Reply
#44
ventech Wrote:So guys, lets just take a step back and think about the real issue here. I just need this to being said: The core to all of the problems discussed in this thread remains the same: the poor internationalization support in xbmc. Even if someone were to write the parser/converter/infrastructure and all that you're still stuck with a program where lot of parts aren't even internationalizationable. For this to happen the key/value xml system needs to go in favor of a proper i18n tool. It most definitely isn't going to be an easy task, but it needs to be done sometime.
My point is: if this were to be done, then everything else discussed here will fix itself. All the tools for translating, syncing, deploying are already in place.

I think you are absolutely right.

But if we want results now, as opposed to in 5 years, we're gonna have to go the quick and dirty way, converting.

Anyway when we have the system, switching it to use the proper tool will be very easy.

And I'd be willing to try to go the "native transifex" way, i.e. using directly the api. Actually I'm just gonna try it, cos I like tinkering with apis Smile
Reply
#45
@ventech: I don't think that changing the translation system in xbmc would be easy. First there are the strings which are translated token-based with xml query. Also the addons coming in with a python framework. I don't think that developers would agree to this, but I can ask their opinion.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 7

Logout Mark Read Team Forum Stats Members Help
State of the translation2