Re: i18n/l10n summary

[Jean-Christophe Helary]

> On Jun 1, 2017, at 7:18, Philipp Stephani <address@hidden> wrote:
> 
> 
>> 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.

That's really not a *small* aspect. Thank you for thinking about that. I'm in 
no position to review your work but I suppose others will.

Jean-Christophe