Re: RFA: start of i18n

[Andrew Cagney <ac131313 at cygnus dot com>]

> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

>   I do know, from the last time I looked at gettextizing gdb (that
>   would have been April 98) that parts of gdb aren't i18n-safe.  For
>   instance, add_show_from_set is not.  This means that as part of the
I recently added that to the ARI.  That should at least help to stop it 
spreading.

I suspect GDB is going to have some fun with ui-out.  Some messages are 
not contigious strings but rather a concatenation of several strings.


> Maintenance-wise there are also some things to be aware of.
> Only the first one is difficult.
>
> * When new strings are added, they must be marked.
>   This is a coding style change and unfortunately isn't really
>   automatable.
Hopefully checking it can be automated.  Sounds like we'll be needing to 
be more careful with message formats and the like.


> * You have to regenerate the primary message catalog whenever strings
>   are added, changed, or deleted.
Should the primary catalogue even be kept in CVS (at least on the 
trunk)?  Hmm, how do things handle a situtation where the primary 
catalogue gets changed but not the translated catalogs?

Given that GDB is interactive it is likely going to see more string 
changes then say BINUTILS or GCC.


> * You have to periodically send the master catalog to the appropriate
>   site so that translation teams can work on it.  I know some projects
>   (Gnome) try to do a string freeze before a release so that the
>   translation teams can catch up.
>
> * You have to periodically incorporate new translation catalogs from
>   the translation teams into the source repository.
>
>
> A couple other ways gdb could be made i18n-aware, plus my comments:
>
> * gdb could be aware of the encoding of strings in the inferior, and
>   convert to the correct output encoding when printing.  In some
>   situations this might be nice.  I don't plan to look at this.
>
> * In theory gdb commands could be translated.  However, I think there
>   is some consensus that in general translating commands and arguments
>   is too difficult in practice.  I don't think anybody is doing this,
>   so for now I think gdb should not either.  (For instance: program
>   names and command-line arguments aren't translated, Emacs function
>   names aren't translated.)
more fun!
thanks,
Andrew