This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Notes on i18n
- To: egcs at egcs dot cygnus dot com
- Subject: Notes on i18n
- From: kthomas at gwdg dot de (Philipp Thomas)
- Date: Thu, 20 May 1999 04:19:13 GMT
- Cc: Jeffrey A. Law <law at cygnus dot com>
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.