Re: Internationalization

[pinard@progiciels-bpi.ca (François Pinard)]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

| [...] I suddenly got the urge to internationalize Gnus.  [...]  If such
| a thing was to be done, how should one do it?  Has there been done work
| in this area for other Elisp packages?

Let's keep tight contact on this one, Lars.  I'm deeply interested and
involved.  And since Red Gnus is a sizeable package, it would surely throw,
as an example to all, an heavy pole in the good direction.  I compulsively
want to convince you of the good direction to take! :-)


* Step 1.  Get file:

	ftp://alpha.gnu.ai.mit.edu/gnu/gettext-0.10.24.tar.gz

and install it on your site.  Follow this recipe:

	./configure --with-included-gettext
	make check
	make install

becoming root for the install if necessary.  If you do not have root
privileges, rather use:

	./configure --with-included-gettext --prefix=$HOME/local
	make check
	make install

or such, and ensure you have ~/local/bin on your $PATH.


* Step 2.  Get a recent PO mode for Emacs, from:

	ftp://alpha.gnu.ai.mit.edu/gnu/po/po-mode.el

and override the one which was installed by gettext.  Ensure you have
this new one on your load-path.


* Step 3.  Use this installed PO mode to *mark* all translatable strings
in Red Gnus.  The recipe is more or less like this:

	etags *.el

	M-x visit RET RET
	C-x f rgnus.po RET

And then, just loop on the following two commands:

	,	find next candidate for a translatable string
	M-,	(conditional) mark it for translation if it makes sense

until you marked all strings.  You may decide that `message' will be
a translating function, in which case tell PO mode by using M-. to add
`message' to the list of known marking functions, so the command `,' will
skip them.  My choice would be to not consider `message' as translating,
while Richard Stallman would see it as translating.  Use _ as the general
marking function (the default with `M-,') and N_ for those translatable
strings for which translation should be delayed at run time.  The command
`M-.' without prefix allows using other marks with completion.


* Step 4.  Alter your files so they logically all include the
following Emacs LISP text near their beginning:

    (eval-and-compile
      (or (fboundp 'gettext) (defsubst gettext (string) string)))
    (defsubst _ (string) (gettext string))
    (defsubst N_ (string) string)

Red Gnus should now work exactly as before, and you may distribute the
resulting work right away, continuing from now on to mark translatable
strings as you go in your Gnus work.  As things would stand at this point,
you have zero overhead for English.


* Step 5.  Recreate a better gnus.pot file through the following command:

	xgettext -drgnus -k_ -kN_ -kmessage *.el

and send it to me (or to gnu-translation@gnu.ai.mit.edu, it's the same
address) the resulting gnus.pot file under a name like rgnus-0.63.pot.
I'll then submit it to all translation teams for getting the translation
of all messages done.  When I get translated PO files, I check them for
formal correctness and, if OK, you semi-automatically get a copy.

Oops!  This is not right.  xgettext has not been changed yet to handle
Emacs LISP sources.  OK, for now, just stick to the rgnus.po file which
was generated while you were marking strings in step 3.  I'll push so
xgettext gets adapted sooner, or I'll do it myself if it slows us down.


* Step 6.  Either wait until someone develop a patch for GNU Emacs so it
includes gettext as a new primitive, or else, reimplement it in Emacs LISP.
The gettext primitive is not ready yet, but I believe it has to be done in
any case, we cannot really escape it, even if it may take a while.  On the
other hand, GNU gettext is quite featureful, and it will be relatively
difficult to reimplement it all in Emacs LISP without forgetting features.

Nevertheless, an Emacs LISP implementation of gettext would be very useful
as an interim measure, even if partial, before it gets integrated in Emacs
for real.  If you do so, please keep in close contact with me, as it would
be a wonderful thing for the GNU translation project.  A few translation
teams are starving to dive into the translation of Emacs LISP packages.
Just make very sure you stick to the GNU .mo format, which is described
somewhere in the GNU gettext manual.  The format allows for sequential
search, binary search or even a double-hashing search on the compiled PO
file, but if you use hashing, you have to precisely stick to the algorithm
implemented by gettext.  In any case, Ulrich Drepper and I have given a
great deal of thought to all of this.  Let's keep in touch, please.



So far, experience taught us that the most tedious part of all this
is producing the translation themselves.  Each national team works at
its own pace.  Some are fast and aggressive, others are almost dormant.
That's why I suggest that you proceed to the marking step fairly soon,
so translations may be going while xgettext is being adapted, and gettext
either interfaced from Emacs or reimplemented in Emacs LISP.

-- 
François Pinard         ``Vivement GNU!''        pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info!