[gcompris-devel] GCompris-qt - some thoughts on textdomains

Fòram na Gàidhlig fios at foramnagaidhlig.net
Fri Feb 28 10:22:49 UTC 2014


Hi all,

I just did a proofreading session for my translation and noticed again 
how big GCompris has become: We have 1,948 strings, containing 17,304 
words. This is creating some difficulties for localizers:

- Proofreading this took me all day, and there was no logical spot to 
take a break. Not all localizers can afford to set a whole uninterrupted 
day aside for this. Not to mention that my eyes hurt ;)

- The size of the file is very daunting for people trying to localize 
into a new language. I felt pretty overwhelmed when I embarked on this 
last year.

- If you are in the lucky situation of having more than one person on 
your language team, it is very hard to split up the work. If we had 
multiple files, every localizer could just grab a file.

Now, since GCompris will need to be rebuilt from the ground up for the 
QT version, this might be a change to do some refactoring here and to 
split the translation into separate packages. Out structure could look 
something like this:

- GCompris Admin
- (GCompris)
-- Main GUI (buttons, menu titles etc)
-- Activity content
-- Help texts

The activiy content and help texts would still be quite big though, so 
how about something like this:

- GCompris Admin
- (GCompris)
-- Main GUI (buttons, menu titles etc)
-- (Activity content & help texts)
---- computer
---- discovery
---- experience
---- ...

Technology-wise, all strings in the same source file always have to end 
up in the same textdomain together, so the file structure will have to 
be designed accordingly. There is just no other sane way to write an 
extractor that will collect the strings.

We are currently using Intltool, which was designed for handling one 
textdomain only. So, we would either have to initialise several versions 
of intltool in multiple subfolders, or write our own extractor script. 
The devs of the Widelands project have a very nice gettext extractor for 
C++ and Lua which we might consider adapting if Intltool shouldn't work 
for us. I'm sure they wouldn't mind us taking it if I ask them nicely :)

So, what do the localizers and devs on this list think - good idea, bad 
idea?

GunChleoc




More information about the Gcompris-devel mailing list