State of the translation

Guys !

I am taking over the handling of translations for xbmc. Tickets, pull requests, github stuff basically, but I am planning to write a completely new QT based multiplatform translator tool which can handle also context explanations for each strings.

With first step I start to make context comments for most of the strings in the English xml file (It will be a PITA :-( ). These comments will be handled of course with the new QT based translator tool.

At the end and if I have some help I plan to build a GIT client into the Utility so that it can handle things directly using GIT.

I'll keep you updated with further plans builds etc.

Cheers, Attila

alanwww1 Wrote:Guys !

I am taking over the handling of translations for xbmc. Tickets, pull requests, github stuff basically, but I am planning to write a completely new QT based multiplatform translator tool which can handle also context explanations for each strings.

With first step I start to make context comments for most of the strings in the English xml file (It will be a PITA :-( ). These comments will be handled of course with the new QT based translator tool.

At the end and if I have some help I plan to build a GIT client into the Utility so that it can handle things directly using GIT.

I'll keep you updated with further plans builds etc.

Cheers, Attila

Excellent news, thanks!

For sure the tool will handle addon translations as well as core xbmc?

But are you sure it's worth it to create a new tool, as opposed to using existing tools? Google translation tool looks pretty powerful to me... And if existing tools are for sure ruled out, if it was up to me, I'd probably try to make a web translator thing, not a qt one - modern javascript ui libraries makes creating even complex ui's pretty easy (I'm thinking http://jqueryui.com/). I'd prefer the web thing because it'll lower the barrier for contributing, and it would probably make git integration easier too, as a translator would not need to set up/understand git at all, it would be handled server side. As a bonus it would be possible to integrate the currently orphan xbmc translation addon to the central system quite easily - you could even allow completely anonymous "suggestions", and then have a logged in "moderator" accept them. (I still think it would be best if creating/correcting translations would require as little effort from the potential translator as possible...)

And if you were to do it the web way, you'd have at least one developer willing to help :-) I do python, php and even perl (I'm so old I still think perl is cool, like it was 10 years ago :-)). Java, C++/C and ruby I don't do. Javascript/node.js... I'm not sure.

OR you could have the qt client contact (optionally?) some kind of cental web system so fetching and updating translations would be super easy. Hmm... I think this is necessary, because forcing a translator to use git is not cool. Git is powerful, github even more so, but grokking all that is not easy, even if you have some version control system experience. (I started using cvs in 1995, and lately subversion, but still...)

Anyway the context idea is very good, and obviously necessary to create quality translations easily. Otherwise you'll need to be very familiar with the whole thing that's being translated. Maybe if you do some "context" strings at first and commit them in git, then other people can help when they have seen what it's about, so it'll be a smaller PITA to deal with.

Hi viljoviitanen !

It is really good to know that I can expect a help on this. The ideas and points are really good what you wrote. The QT way was just because I know C++ but absolutely no experience with web programming languages. I will reconsider the best way to go for. I'll leave this discussion open so that we can really find the best possible solution.

I am really count on the help you offered and really appreciate it.

About the context commenting. I am sure I'll need all the help I can get. From team members and as well as users, translators.

Thanks, again, we'll keep in touch !

Ok, I think I have a winning idea here (Charlie Sheen type winning, dunno )

I'm still liking the javascript, 'cos with modern html5 thingies you can probably work also with local files. So we can (at first) work with a website, but later also add local support. (I'm not an html5 expert, but you can do wonders with modern browsers.) For the "local" use, we could probably just target chrome/chromium, it's popular and cross platform enough.

Then, the app. My great idea is to generate a really really big "translation memory" from freely available gnome, kde, firefox.. translations in addition to existing xbmc translations. Store the "where" part in the database, as to provide reference. Set up the search so that xbmc specific strings are displayed first.

Use json as internal format, only convert to xbmc xml when "exporting" the translated string.

And since we're talking about xbmc, changes in the core translations could even probably make an automated pull request, http://develop.github.com/p/pulls.html .

Make all this configurable so that other projects than xbmc can use the tool as well, and join developing it.

Winning!

Or maybe there is such a tool already, but at least the gnome guys, who have "some" experience in translating, do not seem to have such a tool: http://live.gnome.org/TranslationProject...ranslating

---

Also, alanwww1, I suggest to look if the "context" part in xbmc could be an attribute, like so:

then parsing the xml to the tool can be done more easily than if it's a comment. I just hope xbmc accepts such xml.

Alternative would be e.g.

or if even that's not possible, then maybe just store the context hints in a separate file, using the same format. Anyway xml comments probably is not a good idea because of the parsing problem.

Thanks. The idea is great. I found extjs pretty impressive. TVHeadend uses it and it is great. http://www.sencha.com/products/extjs/examples/

What do you think ?

Except I would keep the xml format for the internal format.

To have the context hints as attributes was also in my mind. I will talk to the team members about this.

Thanks

alanwww1 Wrote:Thanks. The idea is great. I found extjs pretty impressive. TVHeadend uses it and it is great. http://www.sencha.com/products/extjs/examples/

What do you think ?

Except I would keep the xml format for the internal format.

To have the context hints as attributes was also in my mind. I will talk to the team members about this.

Thanks

extjs looks pretty good, maybe I'll try prototyping the ui with that instead of jqueryui.

http://www.json.org/xml.html - I'm gonna go with json, because it's much easier. And I've hated xml since.. well I can't remember, so long

@viljoviitanen

Can you come up to IRC some time ? Would be good to talk.

Usually I am up after 11pm-01am central european time.

Right, I have an early "prototype" of what the ui of the translator that I had in mind:

http://viljo.wippiespace.com/xbmc/demo/demo.html

That has no "server side" things done, it's just an "dummy" UI. And it's still missing the crucial thing I want it to have, the translation memory (and it does not have support for the context hints, I seemingly missed some extjs source files). And I have this really weird problem that if the json file of the translated strings I'm fetching is too large, I get an error from extjs that it's invalid json. But anyway.

I really hope other interested devs would hop along There'll be lots of interesting things to be done both client and server side...

Neat

Finally. I sucked all developers life before to start this kind of translate project. Finally