emacs-devel
[Top][All Lists]
Advanced

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

Re: i18n/gettext?


From: Eli Zaretskii
Subject: Re: i18n/gettext?
Date: Fri, 07 Dec 2001 10:33:51 +0200

As long as we are exchanging more-or-less random thoughts about this
issue, let me raise a few more ;-)

 - What will we do with packages which aren't distributed with
   Emacs?  Do we require them to come with their own separate message
   catalogs?  If so, we need to figure out where to install them, and
   how would Emacs find and load them.

 - For that matter, will every one of the *.el files in the standard
   distribution have its own catalog, or do we go with a single huge
   one for the entire Emacs?

 - What happens when a package is loaded or autoloaded?  How will its
   catalog be read and added to the data base?  (Am I even talking
   sense here?)

 - What encoding will we use in the catalogs?  Do we use emacs-mule
   (or the future Unicode-based internal representation), or do we
   use one of the external encodings (a.k.a. coding systems)?

 - Some complications will raise their ugly heads because Emacs itself
   takes care of the display of non-ASCII characters (as opposed to
   what a typical NLS-enabled console application does).  This affects
   the encoding in which the translated messages are delivered to
   Emacs.  Issues like character composition etc. in Far-Eastern
   languages is one example, but even the Latin-1 vs Latin-9 encoding
   could in some situations render the whole message unreadable
   (e.g., due to the lack of a Latin-9 font).  Bidirectional support,
   when available, will add another complication: Emacs will want the
   translated messages in logical order, whereas most, if not all,
   message catalogs for these languages use the visual order.

   This is even more complicated by the -batch operation, where the
   display engine is not used, and Emacs simply writes strings to the
   screen as a text-mode application.

 - We need to think about some machinery to take care of too-long
   translated strings which overflow fixed resources.  For example,
   the menu bar has to fit into a fixed-width field.

Well, I guess this is enough random thoughts for one day ;-)
Comments are welcome.



reply via email to

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