gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] What you need to know about internationalization of Gnash


From: John Gilmore
Subject: [Gnash-dev] What you need to know about internationalization of Gnash
Date: Wed, 18 Apr 2007 20:16:48 -0700

Last night I checked in the bulk of the changes for internationalization.
They touch a large number of files, largely because whenever there's a
call to log_*, its first argument has to be changed from this:

        log_error("Target is not a sprite instance (%s)",
                        typeid(*target).name());
to this:
        log_error(_("Target is not a sprite instance (%s)"),
                        typeid(*target).name());

All it takes is to put the first argument of the logging function into
parentheses, and precede it by "_", which is a macro defined in
libbase/log.h.

"_" maps to "gettext", a libc function which quickly looks up the
string in a directory of translated strings.  If it finds a
translation, it returns the translated string, which is passed to
log_error and thus to printf.  If not, it just returns the original
string.

So here's my pitch to you.  I've fixed up most of the places that need
_(...) inserted (and I'm looking for the rest).  But if I'm the only
one inserting those, gnash will drift out of translatability.
Instead, whenever YOU insert a call to log_anything, use the underbar
on its first argument.  And if you notice any existing calls that
ought to be translated, you can insert the underbars yourself while
you're in that file.  Thanks!

If you want to actually translate some messages into another language,
please wait a few days until I get the rest of the po/* infrastructure
checked-in.  I'll post a subsequent message about how to start
dabbling in translating Gnash's messages to your favorite language.

You can stop reading now.  :-)  What follows is how it works behind
the scenes.

The master directory of strings is in the file po/gnash.pot.  (I
haven't yet updated it in CVS, so what's there right now is an old
one.  The makefiles update it from a list of source files, which also
isn't accurate in CVS yet.)  Each language creates a file called
$(language).po, and it is compiled into a binary file called
$(language).mo.  $(language) is, for example "es" for EspaƱol, or
"es_MX" for Mexican Spanish.  By default, "make install" puts these
compiled files into:
/usr/local/share/locale/$(language)/LC_MESSAGES/gnash.mo.  At runtime,
a call to bindtextdomain, very early in main() in gui/gnash.cpp, tells
gettext what directory "make install" was configured for; and the
immediately following call to textdomain("gnash") tells gettext that
this process is going to use the "gnash.mo" files there.

Gettext figures out what language the user wishes to see by looking in
environment variables: LC_ALL, or if not set, LC_MESSAGES, or if not
set, LANG.  So end users can set "export LANG=es", and gnash will
automatically translate its messages according to the installed
Spanish translation file.  For testing, you can set environment
variables on the shell command line you invoke gnash with: "LANG=es
gnash foo.swf".  Note: it only works after "make install"; it won't
use a translation that's only in the source tre.

        John






reply via email to

[Prev in Thread] Current Thread [Next in Thread]