Notes on i18n

[kthomas@gwdg.de (Philipp Thomas)]

As the 2.95 branch has happened, it's time to unearth ones todo lists. And
here is part of mine (other parts will follow in separate posts).

Before I start, a warning for the casual reader: this *will* get rather
long, so if you're not actively taking part in egcs's development,
you may safely skip this message.

	
While working on completing i18n for egcs I've made some observations.
Some of them are not always obvious for those whose native tongue is English,
others I'll mention just to make it simpler for those that haven't dealt
with i18n matters before.

I'd like to share them all with you fellow egcs developers in order to ease my
work (well, wouldn't you have guessed :) and that of other future translators.

In the following I'll abbreviate gcc/ABOUT-GCC-NLS as AGN.

 - Before you implement any diagnostic/warning/error reporting functions,
   please read AGN for a description of the mechanisms used, and for
   guidelines as to what should and what shouldn't be translated.

 - I'd also recommend browsing gettext.texi - part of the GNU gettext
   package - specifically the topics under `Preparing Program Sources' in
   the toplevel menu.

 - if you create a new file, or change an existing one that contains/will
   contain something that should be translated, please update
   gcc/po/POTFILES.in if necessary.

 - In functions that are part of the reporting mechanism of the
   frontend (f.i. cp_error for g++), please name the parameter in which the
   message string is passed msgid or end its name with msgid. gcc/exgettext,
   gcc's helper script searches for these names to determine which strings
   to extract for translation.
   
 - When you create/use static message strings, encapsulate them either with
   N_() if the string will get translated on a higher level, or with _()
   if the string is used locally to construct a larger message.
   This makes the strings visible for the message extraction tool(s).
   Here an example from java/parse.c (out of my to_send queue :) :

      char *msg = (!valid_cast_to_p (type_value, type) ?
		   _("Can't") : _("Explicit cast needed to"));

 - If you must use printf et al, mark the message with _(). Again, please see
   to it that direct printfs are concentrated in as few routines as possible
   in order to avoid cluttering up the sources with _().

 - When using conditional expressions for printing the plural form, _please_
   use the full words, rather than just the endings, e.g. 
   
     printf ("%d %s\n", n, (n == 1 ? "warning" : "warnings");
   
   instead of 
   
     printf("%d warning%s\n", n, (n == 1 ? "" : "s")
 
   The most obvious reason being that it's easier for the translator to
   decide how to translate it.
   
   The more subtle but non the less much more important one is: 
       xgettext, the actual message extraction tool, creates only one
       translatable catalog entry for identical strings. Thus you'd get
       only one "s", where the translator would need different entries
       because the translations don't end the same.
   
   

That's all for now. I think at least part of these points should go into a
file in the toplevel dir, something like README.Coders :)


 
Philipp

-- 
You have moved your mouse. Windows must be rebooted for the
changes to take effect.