Internationalization

Internationalization

[Lars Magne Ingebrigtsen]

While reading a discussion on bad, bad translations of computer
programs on no.general, I suddenly got the urge to internationalize
Gnus.  Just imagine -- set the locale to "sweden", and Gnus will promt
you with "Vill du v{rklingen gj|ra detta?" instead of "Do you really
wanna do this?"  Neat!  

(I hate translations, but it sounds neat (to me) all the same.)

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?

Hm...  One could create mappings from the English prompts and messages
to the current countries' prompts and messages, using a hash table.
Providing that the different messages are unique in English.  Then one
just has to wrap all string in the source code with `(gnus-map "The
string")', and the `gnus-map' function could use a hash table built
from the tranlation file for the country during loadup...  Hm...  How
should the translations be specified in the translation files?  Uhm,
that could be done easily enough, with just about any syntax, with the
English originals as comments.  The skeleton translation file(s) could
be generated automatically by just looking for the `gnus-map' calls in
the source files...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Internationalization

[Andy Eskilsson]

/ Lars Magne Ingebrigtsen <larsi@ifi.uio.no> wrote:
| 
| Gnus.  Just imagine -- set the locale to "sweden", and Gnus will promt
| you with "Vill du v{rklingen gj|ra detta?" instead of "Do you really
| wanna do this?"  Neat!  

Arrgh guess we would all scream due to the speling :-) I believe the
screams would be so loud that you would hear it deep down in the dark
kingdom of Norway.. uh :-)

| 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?

Uhm thinking of it didn't I have problems when compiling some
gnu/fsf-utis due to they wanted some localization lib.. looking,
looking, maybe something you could use?

Ahh found it.. tar-1.11.8, something named NLS I believe.
"""
Notes on the GNU Translation Project
************************************

   This chapter presents some information about GNU packages providing
native language translation for their messages: configuration and
usage, contributing to translations, and obtaining GNU `gettext'.
"""

BTW are you also gonna do the same bugs as the german internet
explorer an substitute re: with(uhm what it now was.. I just made it
through my german classes..)

Hmm basically a great idea.. but.. hmm feels so tiny with a small
comment in the big emacs.. but OTOH maybe the small glimpse that makes
the day? Find the misspeling.

	/Andy

-- 
 Hi I am an alien .sig, and at the moment I am having sex to your
 mind, by looking at your smile I can see that you like it.

 Unsolicited commercial email is subject to an archival fee of $400.
 See <http://www.fukt.hk-r.se/~flognat/mail/> for more info.

Re: Internationalization

[Kai Grossjohann]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

>>>>> Andy Eskilsson writes:

  Andy> BTW are you also gonna do the same bugs as the german internet
  Andy> explorer an substitute re: with(uhm what it now was.. I just
  Andy> made it through my german classes..)

I have heard tales of a Siemens MX 500 (I think it was) who had an
implementation of SMTP where they said "NACHRICHT VON" rather than
"MAIL FROM".  Great that it was only in the Siemens `universe' and you
could just switch to a SysVile or BSD universe...

ARGH!

Btw, when my dad replies to my mail with his German MS Mail it sez
`AW' rather than `Re'.  That thing also replaces `ß' with `B' and `ä'
with `a'.  Yuck.  I guess their wires are too small so the Umlaut dots
won't fit...

kai
-- 
I wonder why nobody don't like me,
or is it de fact dat I'm ugly? -- Harry Belafonte

Re: Internationalization

[David Kågedal]

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

> 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?

Yes, it has been done. We here at Lysator have our own conferncing
system, LysKOM, with an Emacs client. (More information at
<URL:http://www.lysator.liu.se/lyskom/> (in Swedish) and
<URL:ftp://ftp.lysator.liu.se/pub/lyskom/>).

This elisp client is available in both Swedish and English, and in the
latest, unreleased, version it is possible to switch languages while
running. All strings are retrieved with (lyskom-get 'string-symbol),
and in the latest version you can also specify a message catalogue as
an optional second argument.

It was implemented as a simple alist before, but we have now moved to
useing symbol properties instead.

We use symbols to identify the strings. I don't believe it would be a
good idea to use strings for that.

Now for some example code:

;; lyskom-get-string gets a string from a message catalog (category)

(defsubst lyskom-get-string-internal (symbol category)
    (cdr (assq lyskom-language (get symbol category))))

(defsubst lyskom-get-string-error (function symbol category)
  (signal 'lyskom-internal-error
	  (list function (list symbol category ": string not found"))))

(defun lyskom-get-string (symbol &optional category)
  "Returns string assiciated with SYMBOL"
    (or (lyskom-get-string-internal symbol (or category 'lyskom-message))
        (lyskom-get-string-error 'lyskom-get-string
                                 symbol
                                 (or category 'lyskom-message))))

;; From file swedish-strings.el

(lyskom-language-strings lyskom-message sv
  '(
    (server-q . "LysKOM-server? (%#1s) ")
    (try-connect . "LysKOM elisp-klient version %#1s.\nF\366rs\366ker koppla upp mot %#2s.\n")
    (protocoll-error . "Protocol error. Servers says: %#1s")
    (connection-done . "Uppkopplingen klar. Serverns versionsnummer \344r %#1s.\n\n")
    (what-is-your-name . "Vad heter du? ")
    (password . "L\366senord? ")
    (wrong-password . "Fel l\366sen.\n")
    (are-logged-in . "Du \344r nu inloggad. V\344nta ett tag.\n")
    (you-have-motd . "\nDu har en lapp p\345 d\366rren:\n\n")
    ...))

;; From file english-strings.el

(lyskom-language-strings lyskom-message en 
  '(
    (server-q . "LysKOM server? (%#1s) ")
    (try-connect . "LysKOM elisp client version %#1s.\nAttempting to connect to %#2s.\n")
    (protocoll-error . "Protocol error. Servers says: %#1s")
    (connection-done . "Connection established. Server version is %#1s.\n\n")
    (what-is-your-name . "What is your name? ")
    (password . "Your Password? ")
    (wrong-password . "Incorrect password\n")
    (are-logged-in . "You have entered LysKOM. Please wait...\n")
    (you-have-motd . "\nYou have a note on your door:\n\n")
    ...))

We also have language-dependent keymaps, variables and menus.

If you're interested, I could send you the rest. You might even want
to try LysKOM yourself, it is quite addictive :-)

-- 
David Kågedal     Lysator Academic Computer Society       davidk@lysator.liu.se
http://www.lysator.liu.se/~davidk/                              +46-13 17 65 89

Re: Internationalization

[Steinar Bang]

>>>>> "David Kågedal" <davidk@lysator.liu.se>:

> We also have language-dependent keymaps, variables and menus.

> If you're interested, I could send you the rest. You might even want
> to try LysKOM yourself, it is quite addictive :-)

Nah... only if you add a Gnus backend to it...;-)

Re: Internationalization

[Lars Magne Ingebrigtsen]

"David Kågedal" <davidk@lysator.liu.se> writes:

> This elisp client is available in both Swedish and English, and in the
> latest, unreleased, version it is possible to switch languages while
> running. All strings are retrieved with (lyskom-get 'string-symbol),
> and in the latest version you can also specify a message catalogue as
> an optional second argument.

Well, the problem with using symbols is that you're polluting the
obarray with thousands of unneccesary entries.  I would prefer using
strings.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Internationalization

[visigoth]

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

> 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?
> 
> Hm...  One could create mappings from the English prompts and messages
> to the current countries' prompts and messages, using a hash table.
> Providing that the different messages are unique in English.  Then one
> just has to wrap all string in the source code with `(gnus-map "The
> string")', and the `gnus-map' function could use a hash table built
> from the tranlation file for the country during loadup...  Hm...  How
> should the translations be specified in the translation files?  Uhm,
> that could be done easily enough, with just about any syntax, with the
> English originals as comments.  The skeleton translation file(s) could
> be generated automatically by just looking for the `gnus-map' calls in
> the source files...

This sounds like an interesting way to start--I suspect that it would
be useful after a time to move the English version out to a file as
well.  So you would have something like:

(in gnus-art.el, lines around 386:)

	(format prompt (if (and gnus-number-of-articles-to-be-saved
                                (> gnus number-of-articles-to-be-saved 1))
                           (format (gnus-get-trans 'these-articles)
                                   gnus-number-of-articles-to-be-saved)
                        (gnus-get-trans 'this-article)))

On the other hand--that's really damned ugly.  Hmm.  It would be nice
if there were some better guarantee that things still work even when a
string changes, that would be good.  Maybe use a combination of these
two strategies.

(gnus-map "these %d articles" 'these-articles)

So this would use "these %d articles" if the language was set to use
the default strings, or look it up from the translation list using the
symbol.  This way, if the string changes, the symbol can stay the
same.  If it changes drastically, it's perhaps easier to recall that
it needs to be changed elsewhere, too.

And finally, you could also do something like:

gnus-text-these-D-articles => "these %d articles" or the
translation--and have a loaded file which sets up the mappings.  I
suppose this just wastes a lot of namespace, though.

The real problem is that anything that's easy to convert to from
having the quotes in-line has the consistency problem--and any other
method sort of uglifies things.  <frown>

And the real problem, unfortunately, is documentation strings.

John.

Re: Internationalization

[Lars Magne Ingebrigtsen]

visigoth@naiad.fac.cs.cmu.edu writes:

> This sounds like an interesting way to start--I suspect that it would
> be useful after a time to move the English version out to a file as
> well.  So you would have something like:
> 
> (in gnus-art.el, lines around 386:)
> 
> 	(format prompt (if (and gnus-number-of-articles-to-be-saved
>                                 (> gnus number-of-articles-to-be-saved 1))
>                            (format (gnus-get-trans 'these-articles)
>                                    gnus-number-of-articles-to-be-saved)
>                         (gnus-get-trans 'this-article)))
> 
> On the other hand--that's really damned ugly.

Well, even the English versions could be translations from the
strings.  So the source code wouldn't change (except for adding lots
of `gnus-get-trans'es around all the strings), and the first
translation would just be an indentity translation, but afterwards, if
I want to change the English version of the text, I'd have to edit the
English "translation" file.

> And the real problem, unfortunately, is documentation strings.

That's true.  They're difficult to do anything about without changing
the internals somewhat.  Not all that difficult, though -- you just
have to fiddle with the `documentation' function somewhat.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Internationalization

[David Moore]

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

> visigoth@naiad.fac.cs.cmu.edu writes:
> > And the real problem, unfortunately, is documentation strings.
> 
> That's true.  They're difficult to do anything about without changing
> the internals somewhat.  Not all that difficult, though -- you just
> have to fiddle with the `documentation' function somewhat.  

	Well, defadvice wraps the documention function for it's own
uses, you could use defadvice to wrapper it also (just in closer to the
original).  Then look up the doc string the same way as the other
strings.  You'd then probably want to change the elisp files to only
have small doc strings, like "Gnus document: gnus-group-update-group",
with the rest of it in the conversion file.

-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | Solo Furnace Creek 508 -- 1996!

Re: Internationalization

[Lars Magne Ingebrigtsen]

Perhaps this patch is a bit better.  It avoids creating garbage
strings when performing identity translations.  I've also moved it to
doc.c, which seemed a nicer place.  

`documentation' now runs all strings through `translate-string', so
xgettext for Elisp files should snarf both the `_' forms and all
documentation strings for interactive functions.  Probably.

*** doc.c.~1~	Wed Apr 10 00:08:50 1996
--- doc.c	Tue Nov 12 23:40:02 1996
***************
*** 36,41 ****
--- 36,46 ----
  #define O_RDONLY 0
  #endif
  
+ #define USE_GETTEXT 
+ #ifdef USE_GETTEXT
+ #include <libintl.h>
+ #endif
+ 
  #include "lisp.h"
  #include "buffer.h"
  #include "keyboard.h"
***************
*** 335,341 ****
        doc = Fsubstitute_command_keys (doc);
        UNGCPRO;
      }
!   return doc;
  }
  
  DEFUN ("documentation-property", Fdocumentation_property, Sdocumentation_property, 2, 3, 0,
--- 340,346 ----
        doc = Fsubstitute_command_keys (doc);
        UNGCPRO;
      }
!   return Ftranslate_string (doc);
  }
  
  DEFUN ("documentation-property", Fdocumentation_property, Sdocumentation_property, 2, 3, 0,
***************
*** 688,693 ****
--- 693,779 ----
    xfree (buf);
    RETURN_UNGCPRO (tem);
  }
+ 
+ 
+ \f
+ DEFUN ("translate-string", Ftranslate_string, Stranslate_string, 1, 1, "sTranslate string: ",
+        "Translate STRING using gettext.")
+      (string)
+      Lisp_Object string;
+ {
+   char *trans;
+   CHECK_STRING (string, 0);
+ 
+ #ifdef USE_GETTEXT
+   trans = gettext (XSTRING (string)->data);
+   /* Check whether the translation returned a new string.  If not,
+      just return the old string.  This avoids creating garbage strings. */
+   if (strcmp (XSTRING (string)->data, trans))
+     return build_string (trans);
+   else
+     return string;
+ #else
+   return string;
+ #endif
+ }
+ 
+ DEFUN ("set-translation-domain", Fset_translation_domain, Sset_translation_domain, 1, 1, 0,
+        "Set the current translation domain to STRING.")
+      (string)
+      Lisp_Object string;
+ {
+   CHECK_STRING (string, 0);
+ 
+ #ifdef USE_GETTEXT
+   textdomain (XSTRING (string)->data);
+   return string;
+ #else
+   return Qnil;
+ #endif
+ }
+ 
+ DEFUN ("get-translation-domain", Fget_translation_domain, Sget_translation_domain, 0, 0, 0,
+        "Return the current translation domain.")
+      ()
+ {
+ #ifdef USE_GETTEXT
+   return build_string (textdomain (NULL));
+ #else
+   return Qnil;
+ #endif
+ }
+ 
+ DEFUN ("set-translation-directory", Fset_translation_directory, Sset_translation_directory, 1, 1, 0,
+        "Set the current translation directory to STRING.")
+      (string)
+      Lisp_Object string;
+ {
+   CHECK_STRING (string, 0);
+ 
+ #ifdef USE_GETTEXT
+   bindtextdomain (textdomain (NULL), XSTRING (string)->data);
+   return string;
+ #else
+   return Qnil;
+ #endif
+ }
+ 
+ DEFUN ("get-translation-directory", Fget_translation_directory, Sget_translation_directory, 0, 0, 0,
+        "Return the current translation directory.")
+      ()
+ {
+   char *dir;
+ #ifdef USE_GETTEXT
+   if (dir = bindtextdomain (textdomain (NULL), NULL))
+     return build_string (dir);
+   else
+     return Qnil;
+ #else
+   return Qnil;
+ #endif
+ }
+ 
+ 
  \f
  syms_of_doc ()
  {
***************
*** 699,702 ****
--- 785,794 ----
    defsubr (&Sdocumentation_property);
    defsubr (&Ssnarf_documentation);
    defsubr (&Ssubstitute_command_keys);
+ 
+   defsubr (&Stranslate_string);
+   defsubr (&Sget_translation_domain);
+   defsubr (&Sset_translation_domain);
+   defsubr (&Sget_translation_directory);
+   defsubr (&Sset_translation_directory);
  }

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Internationalization

[Robert Bihlmeyer]

Hi,

>>>>> On 10 Nov 1996 16:31:18 +0100
>>>>> Lars Magne Ingebrigtsen <larsi@ifi.uio.no> said:

 Lars> If such a thing was to be done, how should one do it? Has there
 Lars> been done work in this area for other Elisp packages?

I think XEmacs has a function "gettext" that does something similar
(can't check it now - XEmacs is at home). Check this one out first.

	Robbe

Re: Internationalization

[Per Abrahamsen]

I hate the whole idea, but if it *must* be done I think there should
be at least these requirements:

* It must not be Gnus specific.

* There should be _zero_ overhead for a user of the English version.

* There should be _zero_ new stuff to learn for an English speaking
  programmer.

I suggested this implementation when someone wanted to make a French
version of AUC TeX.  It follows all 3 requirements.

;;; trans-fr.el --- French translation of message strings

;;; Code:

(fset 'raw-message (symbol-function 'message))
 
(defvar translate-message-alist
  '(("hello" "bonjour")))
 
(defun translate-message (format &rest args)
  (let ((trans (assoc format translate-message-alist)))
    (apply 'raw-message (or (nth 1 trans) format) args)))
 
(fset 'message (symbol-function 'translate-message))

(provide 'trans-fr)

;;; trans-fr.el ends here

Re: Internationalization

[William Perry]

Per Abrahamsen writes:
>
>
>I hate the whole idea, but if it *must* be done I think there should
>be at least these requirements:
>
>* It must not be Gnus specific.

  Correct.

>* There should be _zero_ overhead for a user of the English version.

  Well, I would rephrase this to be 'zero overhead for a user of the
originating language version'.  If lars all of a sudden decides to only
speak french (even in lisp), then so be it. :)

>* There should be _zero_ new stuff to learn for an English speaking
>  programmer.

  similar rephrasing to point #2.

>I suggested this implementation when someone wanted to make a French
>version of AUC TeX.  It follows all 3 requirements.
>
>;;; trans-fr.el --- French translation of message strings
>
>;;; Code:
>
>(fset 'raw-message (symbol-function 'message))
> 
>(defvar translate-message-alist
>  '(("hello" "bonjour")))
> 
>(defun translate-message (format &rest args)
>  (let ((trans (assoc format translate-message-alist)))
>    (apply 'raw-message (or (nth 1 trans) format) args)))
> 
>(fset 'message (symbol-function 'translate-message))

  You would have to hook more than 'message'.  You would definitely have to
hook error, and possible a few other places.  And any custom format-like
functions would have to be modified by the package author as well.

  I like the gettext() approach, and have been considering something
similar in Emacs-W3 for a while, just haven't gotten around to it.

-bill p.

Re: Internationalization

[Per Abrahamsen]

William Perry <wmperry@aventail.com> writes:

>   Well, I would rephrase this to be 'zero overhead for a user of the
> originating language version'.  If lars all of a sudden decides to only
> speak french (even in lisp), then so be it. :)

I'd say English.  The programmer responsible for maintaining a
consistent Emacs distribution should not have to be multi-lingual. 

[ Ignoring Gosling's original redisplay code, which were reputed to be
  written in a mix of Latin and Welsh. ]

Re: Internationalization

[François Pinard]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

| I hate the whole idea, but if it *must* be done I think there should
| be at least these requirements:
| 
| * It must not be Gnus specific.
| 
| * There should be _zero_ overhead for a user of the English version.
| 
| * There should be _zero_ new stuff to learn for an English speaking
|   programmer.

Hi, Per, and everybody.  You do not explain the origin of your
requirements, and they probably proceed from defendable grounds.  But just
to make sure, let me insist at clarifying an important thing.

People should be a bit shy asking for these three points.  It does not
look like an opened attitude to say: "English first, and all others then".
There is no defendable reason why French, Korean, Norwegian, German,
etc. would not deserve to obtain a very good service.  If English people
were to go backward a tiny bit, would it be on speed or on learning
duties, in view of all other nations to get a more equal service, they
should have wide-enough spirit to consider this overall goal as good.

The GNU translation project does reach your three goals.  This for making
the transition more smooth and easy.  But English people do not deserve,
by virtue or by nature, to get that much of an especially golden service.

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

Re: Internationalization

[Per Abrahamsen]

pinard@progiciels-bpi.ca (François Pinard) writes:

> People should be a bit shy asking for these three points.

Native English speaking people are a bit shy on these matters,
probably because they are embarrassed of their lack of language skills,
which is why it important the rest of us insist on these practical
matters.

> It does not look like an opened attitude to say: "English first, and
> all others then".

No, but for someone who thinks it should be enough to learn _one_
foreign language in order to conveniently maintain and contribute to
code in the GNU project, it is a very practical attitude.  It probably
wouldn't be a problem for me if Lars wrote in Bokmål, however having
to look up strings and comments in Masanobu UMEDA's original code in
some translation library would be a significant burden.  And if Lars
chose to write Gnus in Nynorsk, I'd probably never contribute anything.

> But English people do not deserve, by virtue or by nature, to get
> that much of an especially golden service.

I'm not sure it would be wise to try to explain the intrinsic
superiority of the English language to a Canadian with a French name,
so I'll refrain from doing this here.

Re: Internationalization

[François Pinard]

Per Abrahamsen <abraham@dina.kvl.dk> écrit:

| pinard@progiciels-bpi.ca (François Pinard) writes:
|
| > It does not look like an opened attitude to say: "English first, and
| > all others then".
| 
| No, but for someone who thinks it should be enough to learn _one_
| foreign language in order to conveniently maintain and contribute to
| code in the GNU project, it is a very practical attitude.

English *is* the universal language in computer science (and also for
other sciences).  I'm not denying this at all.  Moreover, it is very
convenient for all of us that you do no write in Danish, or me in French.
This `ding' list would not easily exist otherwise.  We agree on this.

But let me hang, when told that English people should observe _zero_
overhead, or just have _zero_ things to learn, if a package gets
internationalised.  English people already have their real big large part
of comfort and ease with all software flying around.

Computers are so important in the world nowadays that, through them,
English threatens many other natural languages.  It is fairly indecent to
reclaim that internationalisation effort should not be the cause of the
slightest disruption on English speaking people.  English is very widely
disrupting all other languages right now, and a tiny bit of movement
towards equilibrium should be considered as acceptable by everybody.

| I'm not sure it would be wise to try to explain the intrinsic superiority
| of the English language to a Canadian with a French name [...]

That would not be wise *because* declaring that any particular language
is intrinsically superior to all others is not wise in itself.  This is
fairly unrelated to the nationality of your interlocutor :-).


The point is, for Red Gnus, that Lars should consider internationalising
it, *even* if we were going to loose a few nanoseconds, here or there.

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

Re: Internationalization

[Ulrich Drepper]

pinard@progiciels-bpi.ca (François Pinard) writes:

> | No, but for someone who thinks it should be enough to learn _one_
> | foreign language in order to conveniently maintain and contribute to
> | code in the GNU project, it is a very practical attitude.

I don't know what you mean here.  As a developer/maintain you need
not even know a single foreign language.  Just follow the guidelines
we try to collect in the gettext manual and you should be able to
produce perfectly internationalized programs (at least in respect
to messages).

-- Uli
--------------.       drepper@cygnus.com  ,-.   Rubensstrasse 5
Ulrich Drepper \    ,--------------------'   \  76149 Karlsruhe/Germany
Cygnus Support  `--'  drepper@gnu.ai.mit.edu  `------------------------

Re: Internationalization

[François Pinard]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

| Ulrich Drepper <drepper@myware.rz.uni-karlsruhe.de> writes:
| 
| > You original mail claimed that for using the
| > internationalization features you need to understand that language.
| 
| No it did not.  I was saying that the i18n support in GNU should not
| be fair, so the code should read gettext ("hello") and not gettext
| ("bonjour") even if the original author is French.  This way, you only
| need to learn one foreign language (English), not two (English and
| French) to contribute to or maintain the program.

People *may* really do it the way they want, it will work anyway.  If I
want to write a software in French localisable in English, that's my sole
and own choice.

However, within GNU at least, partly for the reasons you give, the
original untranslated strings, as well as programmers' comments, have
to be in English.  I agree with you that this increases the overall
freedom of the program, since contributions are planetary, nowadays.
Yet checking, this constraint is not written in full in GNU standards
(an omission most probably, I'll check).

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

Re: Internationalization

[Lars Magne Ingebrigtsen]

Ok; so I'm kinda impatient.  :-)  Here's a patch to install the
gettext functions into Emacs.  It defines five subrs, `get-text',
`{g,s}et-text-domain' and `{g,s}et-text-directory'.  I think these
should all be renamed, and editfns.c is probably the wrong file for
these functions.  `translate' would be better than `get-text', and
`get-translation-domain' (etc) would follow naturally.

Is this all it takes to use gettext?  Kinda amazing.

*** editfns.c.~1~	Tue Aug  6 10:16:40 1996
--- editfns.c	Tue Nov 12 22:54:02 1996
***************
*** 2447,2452 ****
--- 2447,2537 ----
  }
  
  \f
+ 
+ #define USE_GETTEXT 
+ #include <libintl.h>
+ 
+ DEFUN ("get-text", Fget_text, Sget_text, 1, 1, "sTranslate string: ",
+        "Translate STRING using gettext.")
+      (string)
+      Lisp_Object string;
+ {
+   char *trans;
+   CHECK_STRING (string, 0);
+ 
+ #ifdef USE_GETTEXT
+   trans = gettext (XSTRING (string)->data);
+   return make_string (trans, strlen(trans));
+ #else
+   return string;
+ #endif
+ 
+ }
+ 
+ DEFUN ("set-text-domain", Fset_text_domain, Sset_text_domain, 1, 1, 0,
+        "Set the current translation domain to STRING.")
+      (string)
+      Lisp_Object string;
+ {
+   CHECK_STRING (string, 0);
+ 
+ #ifdef USE_GETTEXT
+   textdomain (XSTRING (string)->data);
+   return Qt;
+ #else
+   return Qnil;
+ #endif
+ 
+ }
+ 
+ DEFUN ("get-text-domain", Fget_text_domain, Sget_text_domain, 0, 0, 0,
+        "Return the current translation domain.")
+      ()
+ {
+   char *domain;
+ #ifdef USE_GETTEXT
+   domain = textdomain (NULL);
+   return make_string (domain, strlen (domain));
+ #else
+   return Qnil;
+ #endif
+ 
+ }
+ 
+ DEFUN ("set-text-directory", Fset_text_directory, Sset_text_directory, 1, 1, 0,
+        "Set the current translation directory to STRING.")
+      (string)
+      Lisp_Object string;
+ {
+   CHECK_STRING (string, 0);
+ 
+ #ifdef USE_GETTEXT
+   bindtextdomain (textdomain (NULL), XSTRING (string)->data);
+   return Qt;
+ #else
+   return Qnil;
+ #endif
+ 
+ }
+ 
+ DEFUN ("get-text-directory", Fget_text_directory, Sget_text_directory, 0, 0, 0,
+        "Return the current translation directory.")
+      ()
+ {
+   char *dir;
+ #ifdef USE_GETTEXT
+   if (dir = bindtextdomain (textdomain (NULL), NULL))
+     return make_string (dir, strlen (dir));
+   else
+     return Qnil;
+ #else
+   return Qnil;
+ #endif
+ 
+ }
+ 
+ 
+ \f
  void
  syms_of_editfns ()
  {
***************
*** 2558,2561 ****
--- 2643,2652 ----
    defsubr (&Snarrow_to_region);
    defsubr (&Ssave_restriction);
    defsubr (&Stranspose_regions);
+ 
+   defsubr (&Sget_text);
+   defsubr (&Sget_text_domain);
+   defsubr (&Sset_text_domain);
+   defsubr (&Sget_text_directory);
+   defsubr (&Sset_text_directory);
  }


-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Internationalization

[Jan Vroonhof]

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

> Ok; so I'm kinda impatient.  :-)  Here's a patch to install the
> gettext functions into Emacs.  It defines five subrs, `get-text',
> [..]
> 
> Is this all it takes to use gettext?  Kinda amazing.

Anybody know of there is something like this planned for XEmacs?

Jan

Re: Internationalization

[William Perry]

Jan Vroonhof writes:
>Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
>
>> Ok; so I'm kinda impatient.  :-)  Here's a patch to install the
>> gettext functions into Emacs.  It defines five subrs, `get-text',
>> [..]
>> 
>> Is this all it takes to use gettext?  Kinda amazing.
>
>Anybody know of there is something like this planned for XEmacs?

  This patch would probably work just fine on XEmacs.  I'll give it a whirl
this weekend maybe.... if I don't spend it all babying the baby.  Sick
toddlers aren't conducive to hacking. :)

-Bill P.

Re: Internationalization

[Ralph Schleicher]

William Perry <wmperry@aventail.com> cited below with "WP" writes:

WP>   This patch would probably work just fine on XEmacs.  I'll give it a whirl
WP> this weekend maybe.... if I don't spend it all babying the baby.  Sick
WP> toddlers aren't conducive to hacking. :)

I couldn't follow the complete thread so please allow me hooking in here.

Lars's patch is a little bit too simple.  You should treat every Emacs
buffer as an independent domain.  With Lars's patch, `_' have to be an
alias for

(progn
  (set-translation-domain DOMAIN)
  (translate-string MESSAGE))

I think that the following definition is better suited for Emacs
(`gettext-domain' and `gettext-locale' are buffer-local variables).

(defun gettext (domain message &optional locale)
  "Look up MESSAGE in the DOMAIN message catalog.
If not found, returns MESSAGE itself (the default text).
If DOMAIN is `nil', then look up MESSAGE in the current domain.
If DOMAIN is `\"\"', then look up MESSAGE in the `\"messages\"' domain.
Optional third argument LOCALE overrides the current locale."
  (cond ((equal domain nil)
	 (setq domain gettext-domain))
	((equal domain "")
	 (setq domain "messages")))
  (cond ((equal locale nil)
	 (setq locale gettext-locale))
	((equal locale "")
	 (setq locale "POSIX")))
  (let* ((messages (gettext-find-messages domain locale))
	 (symbol (and messages (intern-soft message messages))))
     (or (symbol-value symbol) message)))

-- 
Ralph * http://www.UL.BaWue.DE/~rs/

GNU -- vivat, crescat, floreat!

Re: Internationalization

[Jan Vroonhof]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I hate the whole idea, but if it *must* be done I think there should
> be at least these requirements:
>

* Key bindings should preferably not change (or you must be able to
  change them back easily)

* You must be able to always (that is ALWAYS) be able to switch to
  English!

Have you tried doing some more than just basic level stuff at your
girlfriend's work computer because she has to get her sheets ready NOW
and discovered that this a French version of the program?

Can you imagine was happens when you are helping someone and telling
him to select the File->Open-Special->Exec menu option while holding
the control key down and he cannot find the option and key because he
has Datei->Spezielles Öffnen->Befehl Ausfuhren and a Strg-taste?

One should be very carefull about translating things. (Whoever thought
of translating the macrolanguages of some PC products should never
come close to me).

Jan

Re: Internationalization

[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!

Re: Internationalization

[Ulrich Drepper]

pinard@progiciels-bpi.ca (François Pinard) writes:

> * 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.

I'm still not sure how we should solve the problem of parsing
ELisp code.  For bash and gawk it is/will be solved by having the
programs themselves having the possibility to dump the strings:

	bash --dump-strings --po-format sh-script

will produce a well-formed PO file which can be read by xgettext.
So xgettext will simply call bash and read the result in a pipe.
The same will hopefully happen with gawk.

But what is about Emacs?  Is it reasonable to call Emacs this way and
if yes will RMS agree to do these changes?  Of course the LISP syntax
isn't really difficult to parse but exceptions like doc strings
complicate things again.  Is the scanner/parser code separateble?

> 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.

Let me know before you start this, too.  It shouldn't be too
difficult to write the function is ELisp (at least if there is
the possibility to access the .mo files which are binary files).
In any case I should tell something about the upper-level things,
how to find the catalog file, the string itself etc.

-- Uli
--------------.       drepper@cygnus.com  ,-.   Rubensstrasse 5
Ulrich Drepper \    ,--------------------'   \  76149 Karlsruhe/Germany
Cygnus Support  `--'  drepper@gnu.ai.mit.edu  `------------------------

Re: Internationalization

[Lars Magne Ingebrigtsen]

pinard@progiciels-bpi.ca (François Pinard) writes:

> And since Red Gnus is a sizeable package, it would surely throw, as
> an example to all, an heavy pole in the good direction.

And since Gnus is a progressive package, it's a good testing ground
for things like this.  :-)

> 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.

I've installed gettext and I've started to create the .po file, but
the one thing that struck me is that by far the most text to be
translated in Gnus is the documentation strings.  And wrapping
documentation strings in the `_' calls will break things.  I also
think that writing (_"This is a string") seems a bit odd.  
#"This is a string" seems like a better idea to me...  or even 
#_"This is a string".  This will require some tiny changes in lread.c,
but nothing major...

> * 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.

Shouldn't it be rather simple to include the gettext subr in Emacs?
Just link libintl.a in and do the normal Emacs lisp interface thingie?
However, if we want to get this into Emacs, it has to be done
now(ish), or we'll have to wait for a while.  The Emacs 19.34.90 alpha
is being released today, I believe.  

If it's simple to include gettext in Emacs, could you run this by RMS
and see what he thinks about it?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Internationalization

[Ulrich Drepper]

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

> #"This is a string" seems like a better idea to me...  or even 
> #_"This is a string".  This will require some tiny changes in lread.c,
> but nothing major...

But this has a major drawback: you have to convince RMS.  With the
solution François currently propagates no change in Emacs is
necessary.

> If it's simple to include gettext in Emacs, could you run this by RMS
> and see what he thinks about it?

Somebody who participates in Emacs development should do this.
Principally it should be trivial.  Have we agreed on the interface
yet?  If I remember correctly we agreed that the simple `gettext'
function is of no big value since the current domain should always
be the one of the Emacs binary.

So we have two candidates: dgettext and dcgettext.  Since LISP can
handle optional argument we could unifiy this to simply provide a

	(defun gettext (domain string &optional category) ...)

In addition the bindtexdomain function is needed.  How this fits
in the #"..." scheme Lars proposed, I don't know.

BTW: in bash and ksh $"..." is used.  Would this be possible as well?

-- Uli
--------------.       drepper@cygnus.com  ,-.   Rubensstrasse 5
Ulrich Drepper \    ,--------------------'   \  76149 Karlsruhe/Germany
Cygnus Support  `--'  drepper@gnu.ai.mit.edu  `------------------------

Re: Internationalization

[François Pinard]

| From: Lars Magne Ingebrigtsen <larsi@ifi.uio.no>
|
| I've installed gettext and I've started to create the .po file, but
| the one thing that struck me is that by far the most text to be
| translated in Gnus is the documentation strings.  And wrapping
| documentation strings in the `_' calls will break things.

Very true.  Let me modify PO mode, at the next opportunity, so it skips
documentation strings automatically, merely considering such strings will
also be extracted automatically by the extracting parsers, and translated
automatically by Emacs (one of these days :-).  Thanks for the suggestion!

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

Re: Internationalization

[Ralph Schleicher]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> cited below with "Larsi"
writes:

Larsi> If such a thing was to be done, how should one do it?  Has there been
Larsi> done work in this area for other Elisp packages?

Yes, I've finished `gettext.el' that evening (many thanks to Ulrich
Drepper for all the comments in the source code of the `libintl'
library).  This Elisp package is intended for those users who cannot
patch their Emacs or if the user have to work with an old version of
Emacs not supporting GNU gettext.  BTW Larsi, have you talked with
RMS about your idea?

Nevertheless, we should synchronize the calling conventions of the C
and Lisp solution.  Here are the documentation strings of my public
definitions.  Any comments would be appreciated.


Variable: gettext-default-directory "/usr/share/locale"
Where the system's locale database can be found.


Variable: gettext-directory-alist nil
Alist of alternate domain locations.
Cons cells are of the form

    (DOMAIN . DIRECTORY)


Function: gettext-bind-domain (DOMAIN DIRECTORY)
Specify that the message catalogs of DOMAIN can be found in DIRECTORY.


Variable: gettext-domain "messages"
The current message catalog.
Automatically becomes buffer-local when set in any fashion.


Function: gettext-domain (DOMAIN)
Set the current message catalog to DOMAIN (a string).
If DOMAIN is `nil', then return the current domain.
If DOMAIN is `""', then reset to the default of `messages'.


Function: gettext-guess-locale ()
Guess value of current locale from environment variables.
This function first looks at the value of the environment variable
`LANGUAGE'; which is a GNU extension.  If `LANGUAGE' is not set, then
the standard POSIX variables `LC_ALL', `LC_MESSAGES', and `LANG' will
be looked up.  If none of these variables is set, then `"POSIX"' is
returned.


Variable: gettext-locale nil
The current locale.
Automatically becomes buffer-local when set in any fashion.


Function: gettext (DOMAIN MESSAGE &optional LOCALE-PATH)
Look up MESSAGE in the DOMAIN message catalog.
If not found, returns MESSAGE itself (the default text).
If DOMAIN is `nil', then look up MESSAGE in the current domain.
If DOMAIN is `""', then look up MESSAGE in the `messages' domain.
Optional third argument LOCALE-PATH overrides the current locale.

LOCALE-PATH is a colon-separated list of locales.  A single locale can be
specified in either XPG `language[_territory[.codeset]][@modifier]' or CEN
`language[_territory][+audience][+special][,sponsor][_revision]' syntax.
All parts except `language' are optional.  If a given locale can not be
found, then the most specific one is looked up by stripping of the optional
parts in the order `revision', `sponsor', `special', `codeset', `territory',
and `audience/modifier'.


Variable: little-endian
Byte order of little endian machines.


Variable: big-endian
Byte order of big endian machines.


Variable: pdp-endian
Byte order of PDP endian machines.


Function: byte-order
Byte order for this particular machine.


-- 
Ralph * http://www.UL.BaWue.DE/~rs/

GNU -- vivat, crescat, floreat!