Re: Emacs i18n

[Eli Zaretskii]

> From: Jean-Christophe Helary <address@hidden>
> Date: Sat, 9 Mar 2019 11:44:09 +0900
> 
> >> Sure. I just meant that l10n issues (is PO "efficiency", etc.) are already 
> >> solved, but i18n in general has to be implemented from scratch.
> > 
> > No sure I understand: what part(s) we would need to implement from scratch? 
> >  We already have the capability of inserting arbitrary non-ASCII text into 
> > any buffer and displaying such text as echo area messages.
> 
> What I mean by "from scratch" is that we have the possibility to extract text 
> and insert text, but i18n is inexistant in emacs. So we have to build an i18n 
> system that works for emacs and that does not exist yet, at all.

I don't see how we can start implementing before deciding what and how
to implement.  This discussion hopefully will eventually lead to such
decisions.

> Also, the "how to load catalogs on demand" point that you mention below is 
> part of i18n and as you seem to say has to be developed from scratch.

If we decide that the gettext way is not entirely appropriate, yes.
But we didn't make that decision yet.

> > Also, how to merge several catalogs (the need for this might disappear if, 
> > for example, we decide that each .el file will have its own catalog),
> 
> Won't this depend on the extracting tool's options ?

Not directly, no.  It's actually the other way around: we should first
decide how to arrange the catalogs, and only after that see what
tools/options to use for that.

> And wouldn't that be more practical in the first place to not merge anything 
> but have one catalog per .el file ? (practical in terms of 
> translation/testing/management, as far as I can tell from experience, etc.)

If you are following the discussion, you know that not everyone agrees
with that.  There are advantages in having just one catalog or a small
number of large ones.

> > and how to load catalogs on demand when the corresponding code is 
> > loaded/executed.
> 
> I guess you mean the technicalities involved in the obvious (?) "we check the 
> user preferred locale and display the catalog corresponding to that locale" ?

I said "load", not "display".  If you have one catalog per .el file,
when do you load it into memory and when, if ever, do you unload it?
Loading everything at the start would be un-economical, to say the
least.

> >> Can't we start with a survey of the strings we want extracted in a given 
> >> number of emacs core packages ?
> > 
> > How would such a survey help us?  We generally want all of the strings that 
> > are displayed to the user translated.  We don't need any survey for that 
> > decision.
> 
> Of course, but a survey (sorry, I don't have a better word) of a few packages 
> can help us see the workload, build prototypes, test them, establish best 
> practices for developers, etc.

I don't think we have reached the point where building prototypes is
useful, since we don't yet have the basic design decisions for
prototyping.