[Top][All Lists]

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

Re: Emacs i18n

From: Paul Eggert
Subject: Re: Emacs i18n
Date: Thu, 7 Mar 2019 08:06:29 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 3/6/19 7:30 PM, Eli Zaretskii wrote:
> I don't see how relying on
> the function to perform the extraction will work with non-fixed
> strings.

Yes, if a caller computes a string and then passes it to 'message',
xgettext's static analysis won't find the string. Although these calls
are in the minority, they do happen, and they'll need to be rewritten.
This is standard practice when any application is internationalized, and
I've already given an example of this.

Of course Emacs is a much bigger project than a small program like 'cat'
or 'uniq', and so Emacs will take much more work to internationalize.
But this is a problem of quantity, not of technology. That is,
translators will need to do more work than usual (as there are more
messages to translate) and developers will need to do some more work (as
there are more "tricky" uses of 'message' in Emacs than there were
"tricky" uses of fprintf in 'cat'.) However, the standard GNU
internationalization technology should work just fine with Emacs.

> E.g., what to do
> with Org, which is in the core, but also distributed separately.
A simple way to address that problem is to have Org use and ship the
same message catalog that Emacs does. Alternatively, Org could ship a
separate message catalog that contains only Org's messages and is
therefore a subset of the Emacs catalog. However, I doubt whether the
hassle of doing the latter would be worth the effort.

reply via email to

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