[Bf-committers] I18N/L10N issues

Yue Shi Lai bf-committers@blender.org
Mon, 02 Jun 2003 06:16:59 +0800

Since I have not reached again those people from the
#blendercoders meeting, there are still some issues
I noticed thereafter:

1. It is really a bad idea to put gettext() in ftfont.
This effectively make any l10n (localisation) of
dynamic messages impossible. Example of such a message

Quality: 95

for which you actually call (via many intermediate
functions) ui_def_but, but the message there is
composed by strcpy and strcat.

Gettext called by FTF_DrawString has no subsequent
possibility to determine the translation of the
composed string "Quality: 95" (unless, of course,
you want to specify that for every possible value
between 1 and 100 - you will have much to do when
you have a floating point value).

The correct (and usually used solution - if you
look into those localised softwares) solution
should be to use gettext on "Quality: ", and not
somewhere in ftfont on the final string.

2. Also visible from the scenario above, it is also
virtually impossible to do l10n just by tracing
where which string constant goes, unless someone
could manage to write a parser able to parse the
C source codes in source/blender/src.

And after I tried this, I can tell that it will be
not easy, with all the recursive definitions and
typedefs in the Blender source.

Therefore, I must really raise the question whether
one should implement gettext based l10n in
source/blender/src, instead of hiding it in ftfont.
The later solution may be convenience for some of
the programmers, but you will only be able to do
l10n on a very limited fraction of the messages.

Yue Shi Lai
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze