[Nagiosplug-devel] Internationalization

[Karl DeBisschop]

On Sat, 2003-07-26 at 02:46, Jeremy T. Bouse wrote:
> Karl,
> 
> 	I guess it was good timing then as I had just recently been working
> with getting to use gettext in a PHP project I was working on, so I
> should be getting up to speed to help out with the i18n work needed for
> the plugins. As for getting the translations done might it not be a good
> idea to make a master messages.po file to give to the translation people
> to work from. If they all work from that master then they should be able
> to use msgmerge to include new translations into the POT file when there
> are additions and subtractions of entries.

I thought 1 .po for each language might work well - there's no reason a
polis translation team should have to consult with the chinses team on
changes.

And thats' what auotmake does by default anyway (as an aside, while
autotconf has always been a big win, automake in my opinion was closer
to break even until this work - I have a feeling this would have been
alot harder without automake support.)

> 	One thought I had while reading the patches you submitted for
> check_tcp was that I thought from what I read that adding the \n to the
> end of the entry within _("") might cause problems when ran through
> xgettext. Have you found any problems with this in your testing or might
> this be something we need to be aware of and watchful for as we proceed.

No - works fine.

> 	I do like your idea of having partial gettext support by the
> mid-august targeted release date is a reachable goal. If we could have
> english, french and german by then that would be an ideal goal. If you
> want to split up the plugins that still need work I can take on some of
> the load. I have plenty of time while commuting back and forth to work
> on the train now that I have a Sony Vaio which is light enough to take
> back and forth (replacement for 8lbs Toshiba laptop). I'll also be
> taking some vacation time the 30th - 1st so I'll have some free time
> to work on things but not the whole time as wife wants me to spend some
> time with her.

Great. Here's what I've figured out so far:

1) the style I had where the strings were initialized as constant cahr's
up front will not work. Once gettext comes into play, they are no longer
const cahr.

2) I could go back to #defines defined up front, but gettext guidance
has you keep the message sizes to a 'paragraph' -- so many of the
plugins would need severad #defines. (I'm also looking at a size
limitation in the constants that would break an old ANSI c compiler).

3) I still plan to extarct embedded docbook out of theses strings at a
later date (beyond the mid-august alpha, probably beyond 1.4 entirely).
Actaully, gettext makes this pretty easy. If I define S_() as a second
macro for gettext(), I can just grep through the file to collect them
for the SGML. But to do this, things need to be in the order they would
be read.

So, I had to move the print_usage and print_help functions above main.
Historically, I haven't wanted to do that becuase it makes poeple slog
through non-core code before they see tha actual program logic. But it
seemed to be the right course given all these constraints.

As for approach, when people pick up a plugin to mark for translation,
they could give a shout on this lest, or they could enter it in a
tracker (we could use bugs, or we could just create a separate tracker
for advisory "checkouts" like this)

What works for you?

--
Karl