[Gtranslator-devel] gtranslator plural forms/PO file parsing

[Ross Golder <ross golder org>]

http://bugzilla.gnome.org/show_bug.cgi?id=123528

First, my apologies for this being outstanding for so long. I've been
meaning to get round to doing this for a very long time now, and every
time I sit down to do it, I come up against the same dilemma. I think
this time, I should ask for some advice, or seek some kind of
confirmation that I'm on the right track.

To fix this, the message structures and the PO file reading and writing
routines need to be updated to handle plural forms (better). Currently
the PO reading and writing routines in gtranslator are fairly crude (in
comparison to the way the gettext library reads and writes PO files).
IMHO, gettext does this job in a much more 'proper' fashion. However,
gettext's external library API doesn't expose much (it's really crap)
and can't be used directly.

IMHO, it would be more appropriate to spend the time librarising
gettext, and making exposing all the file reading/writing code (and the
'message.h' structure etc) from there. I've currently got my head buried
in the gettext source code (and am learning quite a bit about flex!),
with this aim in mind. I mentioned it once to the gettext developers on
their mailing list, but I didn't have anything concrete, and I didn't
hear anything back. If this is an achievable goal, I can think of at
least the following benefits:

- All of gtranslator's file parsing/writing bugs could be squashed in
one hit
- gtranslator could become a GUI front-end to the all the msg* tools,
reducing the need for translators to become familiar with using a shell
- General benefits of code re-use, savings in developer time and memory
footprints etc (gtranslator on the ipaq? when?)
- gettext seems to have the ability to write out more than just PO files
(e.g. Java '.properties' files and other formats). We'd get to leverage
that flexibility too.
- knock-on effect - gettext becomes more modular

I appreciate that for most gtranslator users, a quick-fix would be
preferable and would make life easier for them when translating PO files
with plurals in. However, I've only got time to follow one path, and
(unless proven wrong) I feel that the gettext approach is the 'Right Way
(tm)' to do things.

I did ponder the quick-fix way, and (IMHO) step one would involve
updating the GtrMsg struct in messages.h to manage 'msgstr' as an array
of strings, and updating everywhere else in the code that uses 'msgstr'.
I followed this path for a bit, but it turned out to need updates in a
*lot* of places, so I abandoned it for the path of righteousness. If
anyone does go this route, and produces a working patch, it'd still be a
step in the right direction from where we are now, so please send it it.

However, either way we do the file handling, we're still faced with the
second half of the problem... How best to present plural forms to the
user that allows them to update them intuitively.

I haven't spent much time thinking about this, but I'm imagining that
whenever the user browses to a plural message, the translated panel
would split from 1 into x number of horizontal panels, each with one of
the possible translations. Can anyone see any problems with this, or
suggest a better interface? Like I said, I still haven't really thought
that part of it through yet.

So that's my apology for tardiness, and my lame excuse. Comments,
advice, guidance etc on either stage of the problem would be
appreciated.

Regards,

--
Ross