Re: Before l10n, better practices for (message) ?

[Eli Zaretskii <eliz@gnu.org>]

> From: Jean-Christophe Helary <jean.christophe.helary@gmail.com>
> Date: Fri, 26 May 2017 23:21:59 +0900
> 
> >  (setq key1 "string1"
> >        key2 "string2")
> > 
> >> (message key1)
> >> (message key2)
> > 
> > One problem with this approach is that the programmer who writes the
> > original code and provides the messages in English will have to
> > manually create the English message catalog.
> 
> It just occurred to me that in gettext, "key" *is* the English string...

Yes.  But then you cannot use setq on literal strings.

> > Another problem is how to combine such catalogs from different source
> > files, and/or make sure the "keyN" names from different files don't
> > clash.
> 
> Is it very different from global variables clashing or not between packages?

No.  But the need to name messages with package qualifiers is a
significant nuisance, and will fill the "namespace" of a file with
many symbols.

> > IOW, the question of suitable infrastructure is still there, with any
> > approach.  That's why it is better to start by using whatever relevant
> > infrastructure is provided by gettext, because at least some of these
> > issues are already solved there, and because the package itself is
> > widely available.
> 
> Yes, but to me it looks like gettext works like it does this because C is not an interpreted language and forcing Lisp code to use the full gettext process does look a bit unnatural.

I didn't say we should use all of the capabilities of gettext.  We
just need to use what suits us.

> I can see that we use gettext to extract strings and create POTs to get POs. But once the POs are there, do we need to create binary MO blobs ? I'm not sure at all. So in the end gettext would be used only for string extraction and a few checks. But I may be missing something important here...

Figuring out which parts of gettext should be used is part of the
job.  Whatever we find useful will be net win, since we will not need
to develop and maintain that.

Also, even if we don't use some part, it could provide ideas for
similar infrastructure tailored to our needs.