Re: Emacs i18n

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > When you design a translation system, you have two personas:
  >   - the programmer,
  >   - the translator.

  > The translation system defines
  >   1) which information flows from the programmer to the translator,
  >      and in which format,
  >   2) which information flows back from the translator to the programmer,
    >      and in which format.

That argument is valid for gettext, but not for Emacs.

This is the part that doesn't fit Emacs:

  >   - The programmer, you can assume, can write and understand algorithms,
  >     but does not master the grammar of more than one language (usually).

In the development of Emacs there are many programmers, even some who
speak Russian.  We will have no difficulty implementing and
maintaining russian-masc, russian-nom, and so on.

These constructs do not need to be known to gettext.
For gettext, they will simply be part of the translation string.

We can do this for those languages in which it is convenient for us --
those that someone knows and decides to handle.  For other languages,
we can stick to the low-level gettext approach, which will work
for all languages.

    > - The translator, you can assume, can translate sentences and knows
    >   about the different meanings of words in different context. 

The Russian translation team for Emacs will not have difficulty using
russian-masc, russian-nom, and so on.  Being Russian speakers, they
will understand how these constructs make sense for Russian, once
they read the documentation for them.

  > In the gettext approach (where 1) are POT files and 2) are PO files) we
  > added plural form handling, which is just a small morphological variation,
  > and it required a significant amount of documentation and education for
  > translators. I would say, it is on the limit what we can make translators
  > grok.

The gettext approach requires coding the algorithm in the translations file.
My approach has the advantage of avoiding that.

  > Now, when you give a translator a string

  >    "russian-nom:%d байт%| скопирован%|, %s, %s"

  > you need to think about the appropriate tooling that will make the
  > translator understand
  >   - what 'russian-nom' means,
  >   - what the '|' characters mean,
  >   - what the '%' characters mean.

I picked that syntax on the spur of the moment because I thought it
would be natural and convenient.  If that isn't natural and convenient
for the translators, we can pick a different one.

  > Either the translator tool should somehow highlight these characters
  > and present on-line help,

That would be good to do.

  >  it should present it as a sequence of
  > strings to translate:

  >   Rule: russian-nom
  >   "%d байт"
  >   " скопирован"
  >   ", %s, %s"

Is this general enough to handle all the use cases?
I don't know -- I don't speak Russian.

  > For the plural form
  > handling alone, it took several years until the main tools had support for
  > it in their UI.

What sort of syntax do the tools support for plurals?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)