Re: making gettext more like fluent

[Daniel Brooks]

Richard Stallman <rms@gnu.org> writes:

>   > > Is it feasible to write a small Fluent interpreter in C for this
>   > > purpose?
>
>   > Absolutely, but my personal preference is to write it in Elisp.
>
> An implementation in Elisp could be ok for Emacs, but Emacs is just
> one of hundreds of GNU packages, and one of thousands of packages in
> the GNU system.
>
> To fully adopt Fluent along with gettext as the GNU method of handling
> this, we need to make it work in C programs.  The only simple, clean
> and general way is to implement it in C.
>
> Maintainers will never adopt this if their programs need to link
> with Emacs or with Rust.

Certainly most programs cannot link to Emacs; Emacs isn't even designed
for that. Rust _is_ designed to be linked with C programs, and it is an
excellent language to write things in. It is only my opinion, but Rust
is a significant long-term threat to the ubiquity of GCC. Another
similar threat is the low quality of the C language itself. To counter
this, GCC should grow a Rust front-end. I hope that the work has already
begun.

But that is a topic for a different day.

I would not volunteer to write any large amount of C. I know C, and am
good enough with it, but suffering the aggravations of the language is
not my idea of a good time.

Again it's just my opinion, but Emacs could link against Rust code such
as fluent-rs if we wanted it to. The Rust compiler is free software, and
has become readily available in most Linux distributions. There are no
technical roadblocks either. I have no idea what it would take for
people to want it, but I'd volunteer to help if they did.

>   > The message catalog files (MO files) just have flat strings with no
>   > notion of substitutions or function calls. This is why my first
>   > inclination was to generate elisp code from a Fluent file.
>
> I don't follow how the beginning leads to the conclusion.

My apologies. It seems that I stated some of my conclusions and then
followed them up with supporting examples.

>   > The easiest way to mush gettext and fluent together is to put some
>   > syntax into the messages that is post-processed before being returned to
>   > the caller, turning it into an interpreter.
>
> That is too terse for me -- I am totally list.
>
>   > Something like this in a PO file:
>
>   > msgid "-sync-brand-name"
>   > msgstr "Firefox Account"
>
>   > msgid "sync-signedout-title"
>   > msgstr "Connect with your {-sync-brand-name}"
>
> I see what it says, but can you explain how that relates to "syntax
> that is post-processed before being returned to the caller"?  Terse
> references such as "the caller" leave me lost because I can't tell
> what they refer to.  The leap is too long for me to follow.

The caller is some part of Emacs, let's say. Emacs calls the hypthetical
igettext("sync-signedout-title"), and the translator wants Emacs to get
the string "Connect with your Firefox Account" (I've just copied this
example from projectfluent.org, which got it from the Firefox source
code). With this simple proposed syntax, igettext must inspect each
string that it retrieves from the message catalog to see if it contains
any substitutions. Those substitutions can be almost as recursive as a
real lisp program, and they can have conditional statements like lisp
programs.

Thus I would prefer to just compile the Fluent syntax into Lisp
functions rather than to write a new interpreter. One build step for
Emacs would be to read in the Fluent files for all available
translations, and output ordinary .el files. Those .el files would then
be loaded during the bootstrap process, just like all the existing lisp
source files.

It occurs to me that one way to refine this a little bit would be to
directly output a elisp bytecode to a .elc file after reading in a
Fluent file. This skips a step, and makes distributing packages
containing translations easier. Making `load' recognize Fluent files
seems like it would tie everything up nicely.

>   > Also, note that the original language wants to have the same
>   > substitution capabilities as the translations.
>
> What does "the original language" mean here?

Whatever language the user interface was originally written in. In the
case of Emacs, this is English.

The English "translation" of Emacs will want to use the same Fluent
capabilities that any translation would have access to.

db48x