Posts: 33
Joined: Mar 2010
Reputation:
0
sebak
Junior Member
Posts: 33
Great! I'll have a look at different tools from other projects.
Posts: 1,265
Joined: Oct 2009
Reputation:
29
takoi
Team-Kodi Member
Posts: 1,265
1 year later..
not happening after all?
Posts: 33
Joined: Mar 2010
Reputation:
0
sebak
Junior Member
Posts: 33
It took a long time, but now I'm working on a platform to make it easier to translate XBMC.
It can be used to translate xbmc & add-ons, all translations are centralized, which makes it easier to work together with multiple translators.
Posts: 1,256
Joined: Feb 2009
Reputation:
29
h.udo
Is a huge ABBA fan
Posts: 1,256
Hi sebak.
Thanks for investing your time on this. I'm the Portuguese translator and really think that a proper method to translations has to be found.
Current method of downloading files, translating and publishing diff for old files or new files for new translations is madness.
I say madness because add-ons resulted on hundreds of files that need translation. I can deal with translations on the hundreds... What I _can't_ deal is remembering all the gits, svns and looking every day to add-ons mailing list for updates and checkout if new strings exist.
We really need a new method for translations. Something along the lines of:
1 - Get all translators (Portuguese in my case) 'official/available' translators registered on the site/tool adopted
2 - Maybe adopting the method of anyone can collaborate on translations but only the language translation responsible can review and approve the correct translation to be committed by devs on svn, git, whatever
3 - Files created/updated in need of translation (usually English strings.xml is the one created/updated first) trigger an automatic 'call on translators' to update/create translation
4 - Get _all_ add-on developers on board such a solution, properly maintaining a 'translate convention' and translatable files database for ease of use and maximum efficiency on translations
Seriously, guys!
It's not funny to translate things, send patches to add-ons mailing list or trac only to realize your translation is outdated because the add-on developer added/remove/changed a string. Not my Friday night first choice, really.
One case that happened a couple days ago: my Portuguese scrapers translation on xbmc trunk were synced with dharma-pre git on sourceforge. Not a problem, right? Wrong! Some of the translations on git were older than the translations present on xbmc trunk.
Result? A few translations were lost on xbmc trunk...
Not funny...
Please, we need to get to a consensus on a solution.
hudo
Posts: 1,265
Joined: Oct 2009
Reputation:
29
takoi
Team-Kodi Member
Posts: 1,265
Instead of reinventing the wheel you should rather focus on:
1) detokenize xbmc
2) removing duplicates
Then the transition to gettext can be made and rosetta (launchpad), which can already do everything hudo mentioned, can be used.
Posts: 1,256
Joined: Feb 2009
Reputation:
29
h.udo
Is a huge ABBA fan
Posts: 1,256
I really don't care about the final solution, whether it's a new one or something already existing.
What I do care about is the current state of things. It's frustrating and can lead to new translators rapidly realizing that they are going to find a real mess with files all over the place.
Old translators are used to the current method. Only problem is that the new add-ons system really exposed a serious lack: a centralized database of translatable files and files translated/in need of translation.
hudo
Posts: 1,265
Joined: Oct 2009
Reputation:
29
takoi
Team-Kodi Member
Posts: 1,265
2010-10-15, 17:37
(This post was last modified: 2010-10-15, 17:41 by takoi.)
have a clone of the addon repo; then everyone add their addons to be translated. So what 'greater control' is it that you need exactly?
Also, lets not forget launchpad already have a huge database of translated strings it will use. You cant match that..