[Top][All Lists]

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

Re: i18n/l10n summary

From: Philipp Stephani
Subject: Re: i18n/l10n summary
Date: Wed, 31 May 2017 22:18:11 +0000

Jean-Christophe Helary <address@hidden> schrieb am So., 28. Mai 2017 um 07:29 Uhr:
The discussion so far seems to point at modifying 'message' and the likes so that developers don't have to bother with any l10n mechanism on their part (besides for writing clean strings).

On May 27, 2017, at 10:52, Jean-Christophe Helary <address@hidden> wrote:

My very uninformed idea is that we need an independent function that handles the preferred language check and the catalog parsing based on a key, and all the string displaying functions (message etc) would be redefined to call that function when a non default preferred langage (currently English) is detected.

On May 27, 2017, at 16:43, Eli Zaretskii <address@hidden> wrote:

Yes but from what I've seen in package/el, a lot of translatable texts are not displayed with "message". Some
use "error", some use other mechanisms.

Internally, they all boil down to a small set of C functions, which is
where we should make these changes.

Since it's C, I'm not going to be able to contribute to that before I understand the language, and the function definitions. I guess it's time I open that K&R that's been on my shelves forever...

One small aspect would be to implement field numbers for `format' so that argument indices can be explicitly specified. That is probably quite important because the word order is different between languages, but it's also useful in other situations (e.g. when repeating an argument). I've implemented this in the attached patch. 

Attachment: 0001-Implement-field-numbers-in-format-strings.txt
Description: Text document

reply via email to

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