Re: an i18n sample

["Eli Zaretskii" <eliz@gnu.org>]

> Date: Mon, 25 Oct 2004 17:57:41 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: gdb-patches@sources.redhat.com
> 
> This isn't the first time we've seen an attempt to mark up GDB.  Last 
> time, unfortunatly, things became bogged down by the desire to fix i18n 
> code problems _before_ marking things, and that let to the process 
> becomming stalled (it's scope became too large so nothing happened), and 
> eventually dropped.  Lets try to avoid that mistake this time.

Baurjan clearly said that he is willing to do both in one go, so I
don't see how we are making the same mistake.

> Looking at the work, there are two tasks here:
> 
> - mark up gdb's strings
> - fix i18n breakage
> 
> Where there's a trivial tweak, perhaps commit it, but for more complex 
> cases we should consider leaving them(1), comming back later.

I didn't see any non-trivial tweaks in the parts of the code that were
posted.  It's a bit more work, but nothing close to rocket science.

> We'll soon hear about it - the i18n users will soon alert us to
> where english is still showing through.
> 
> By doing this we can can limit the scope of the immediate task (so it 
> can be completed), and then address the second over time.

Consider my message to be such an alert (you will see on the TP Web
site that I'm the team leader for a particularly non-trivial
language).

Look, I was asked to give an opinion on the patch, which I did.  If
the majority here wants to see half-baked i18n ``support'' just to say
that some TODO item is done, then so be it.  But I consider simple
markup of deeply English phrases to be a bad example of i18n, because
the results are ugly in many languages, including the one I'm
responsible for.  You are in fact requiring the translators to do
their job twice, because once the code is rearranged along the lines I
suggested, the translations need to be done anew for most of the
messages.  It's a waste of scarcely available resources.

> Hmm, should we require all strings to be "marked-up", using a new macro 
> ``I_()'' for identity strings - ones that shouldn't be translated.

We should use this macro to mark strings that should not be
translated, yes.