emacs-devel
[Top][All Lists]
Advanced

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

Re: i18n/gettext?


From: Paul Eggert
Subject: Re: i18n/gettext?
Date: Fri, 7 Dec 2001 11:16:00 -0800 (PST)

> From: Richard Stallman <address@hidden>
> Date: Thu, 6 Dec 2001 08:02:54 -0700 (MST)
> 
> There is a clear and large advantage in not marking the strings
> to be translated: marking them would be a gigantic job and would
> change most of the Lisp files.  Avoiding that gigantic job
> is a tremendous advantage.
> 
> So the question is, why is it hard to arrange not to mark them?

The basic problem is that there's no automatic way to determine which
strings should be translated, and which should not be translated.  Any
translation scheme must rely on some human intervention to determine
this.  Here are three possibilities:

* Most GNU programs use a simple scheme, where each literal string is
  surrounded by _() or N_() if the string should be translated.  This
  is a pain, as you mention.

* Another possibility would be to translate all strings, but rely on
  human translators to realize which strings should be kept in
  English.  I this would be too error-prone, though.  I tried this
  approach in a small experiment with GNU tar's copyright notices, and
  it didn't work well: some translators translated the copyright
  notices even though they were asked to keep them in English.

* A few GNU programs (e.g., GCC and GNU diff) have a more elaborate
  scheme, where a literal string doesn't need to be marked if it
  appears within an argument of a function that always translates that
  argument.  This relies on a method for marking functions that
  translate their arguments: the convention used by GCC and GNU diff
  is that if the function parameter name ends in "msgid", the function
  translates the corresponding argument.  This method greatly lessens
  the need for marking strings, but a few odd cases still need to be
  marked.

If I were going to do this for GNU Emacs, I would use the last scheme,
as it's less intrusive on existing code.



reply via email to

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