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

[Bruno Coudoin]

Le 28/02/2014 11:22, Fòram na Gàidhlig a écrit :
> 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:
Hi,

I am sorry for that. GCompris became quiet big over the years.

> - 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 ;)
Sorry again for your eyes ;) but I am not convince it's all GCompris's 
fault.

Maybe you could blame the translation tool you use for not being 
practical for a such large po file.

>
> - 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.
Again this is more a translation tool issue. It should made 
collaboration easy.
> 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.
That makes sense but it is very hard to handle on the software side. It 
means that we have to switch the textdomain all the time. For example if 
an activity call a function in the core at some point we have to switch 
to core textdomain and then switch to the activity textdomain on 
function return. This is not very practical.

> 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 :)
In the Qt Quick version we don't use gettext, at least not immediately. 
We are using 'ts' which is the technology proposed by default in Qt. On 
the KDE side, the translations will be still managed in po format but 
transformed in the ts file format for GCompris to use it. So there will 
be a ts2po, the translation and then a po2ts.

> So, what do the localizers and devs on this list think - good idea, bad
> idea?
>
As a dev, I believe this is a translation tool issue, it should be made 
easier to handle large files and propose some collaboration feature. 
Managing this on the GCompris side would make the code complex and error 
prone.

Bruno.