Emacs i18n

Emacs i18n

[Narendra Joshi]

Hi everyone,

Recently I was asked if Emacs can be configured to use a different language
in its interface, e.g. menu bars, org mode agenda, days of the week, etc. I
tried finding out if it is possible but only found documentation on
language environments. Are there translations for Emacs in other languages?


Best regards,
Narendra

Re: Emacs i18n

[Thibaut Verron]

Hi,

The days of the week in org timestamp cookies try to follow your
locale settings.

I'm not aware of any other part of Emacs which would be localized.

Best wishes,
Thibaut

Le sam. 17 juil. 2021 à 11:27, Narendra Joshi <narendraj9@gmail.com> a écrit :
>
> Hi everyone,
>
> Recently I was asked if Emacs can be configured to use a different language
> in its interface, e.g. menu bars, org mode agenda, days of the week, etc. I
> tried finding out if it is possible but only found documentation on
> language environments. Are there translations for Emacs in other languages?
>
>
> Best regards,
> Narendra

Re: Emacs i18n

[Eli Zaretskii]

> From: Narendra Joshi <narendraj9@gmail.com>
> Date: Sat, 17 Jul 2021 11:27:14 +0200
> 
> Are there translations for Emacs in other languages?

No, not at this time.  Translating the Emacs UI is a non-trivial
project, as past discussions have indicated, for several good reasons.
No one started to work on that seriously, AFAIK.

We do have the ngettext function, but (a) it has limited scope of only
supporting localization of echo-area and minibuffer messages; (b) it
is called only in a small number of places; and (c) we don't yet have
message catalogs, nor have we figured out how to distribute them in a
way that would allow a package to come with its own message catalog.

(Btw, "translation" in the UI context are not generally referred to as
"i18n", but as "localization", "l10n".)

Re: Emacs i18n

[mrf]

Eli Zaretskii writes:

> No, not at this time.  Translating the Emacs UI is a non-trivial
> project, as past discussions have indicated, for several good reasons.
> No one started to work on that seriously, AFAIK.
>
> We do have the ngettext function, but (a) it has limited scope of only
> supporting localization of echo-area and minibuffer messages; (b) it
> is called only in a small number of places; and (c) we don't yet have
> message catalogs, nor have we figured out how to distribute them in a
> way that would allow a package to come with its own message catalog.


Is UI Strings in C code fully translatable (especially in gtk UI
although I think they are fewer than elisp ones)?

Do you talk about elisp part of code when you say It is limited?

Re: Emacs i18n

[Eli Zaretskii]

> From: mrf <joinlaw@cock.li>
> Cc: help-gnu-emacs@gnu.org
> Date: Sat, 17 Jul 2021 16:32:08 +0300
> 
> Is UI Strings in C code fully translatable

No.  But those are indeed the minority; the vast majority is in Lisp.

> Do you talk about elisp part of code when you say It is limited?

It doesn't matter.  What does matter is that the echo-area messages,
whether they come from C or Lisp, are a small part of the text that
Emacs presents to the user as part of the UI.  We have special buffers
(like *Help* and *Apropos*) where we show information which won't fit
the echo-area, we have menus and dialogs, we have tooltips, etc. etc.
The names of commands and user options are all in English, and those
names have mnemonic value.

Let's face it: the classic i10n framework doesn't really work for a
program such as Emacs, which interacts with users via so many
different means.

Re: Emacs i18n

[Alexandre Garreau]

Le samedi 17 juillet 2021, 16:01:11 CEST Eli Zaretskii a écrit :
> > From: mrf <joinlaw@cock.li>
> > Cc: help-gnu-emacs@gnu.org
> > Date: Sat, 17 Jul 2021 16:32:08 +0300
> > 
> > Is UI Strings in C code fully translatable
> 
> No.  But those are indeed the minority; the vast majority is in Lisp.
> 
> > Do you talk about elisp part of code when you say It is limited?
> 
> It doesn't matter.  What does matter is that the echo-area messages,
> whether they come from C or Lisp, are a small part of the text that
> Emacs presents to the user as part of the UI.  We have special buffers
> (like *Help* and *Apropos*) where we show information which won't fit
> the echo-area, we have menus and dialogs, we have tooltips, etc. etc.
> The names of commands and user options are all in English, and those
> names have mnemonic value.
> 
> Let's face it: the classic i10n framework doesn't really work for a
> program such as Emacs, which interacts with users via so many
> different means.

Translating emacs would require to translate many identifiers, it would 
actually amount to translate a programming language, which has very rarely 
been done.  It usually only has been done through keyword, and translation 
of standard library, and mostly for education purposes, while any other 
use than educational is weirdly considered to be “professional” (while 
education wouldn’t?) hence to enables international collaboration, hence 
english.

I once heard from a friend called Jean-Philippe de Mengual aka Texou that 
he wanted to translate emacs but couldn’t because he rightfully heard that 
would mean translate commands and identifiers and programs, etc. 

It was a pity because he often runs a lot of accessibility-oriented work 
especially about blindness (as he’s blind too), and emacs through 
emacspeak is well reknown as a wonderful vocal desktop (it wouldn’t 
surprise me that it would be the most efficient and useful vocal interface 
in the world).  This is likely to amount to emacs’ extensibility, which 
enables to freely, and without permission nor (to a limited extent) 
coordination, implement new paradigms, such as advice-oriented programming 
(which emacspeak ubiquitously use, so that it keeps working while 
modifying almost all emacs behavior, while staying in sync with mainline 
emacs).

Emacspeak is sort of wonderful and sooo complete I guess because of 
dogfeeding, its dev uses it for everything… but dogfeeding has its limits, 
and afaik he’s amero-indian, so english is his native language… and indeed 
emacspeak is most likely the best UI for english-speaking people… as is 
emacs.

It is no new that english, on par (or even more) than technical skills, is 
a great bareer to user-friendliness of a program.  So if emacs could be 
translated, it could gain a loooot more users… on the other side, that 
would break compatibility between many user extensions which would be 
divided between them because of language bareer…  But what evolution 
theory teaches is that more barieer also means more diversity, more 
mutations, hence more ideas.  Plus that would represent programs written 
by non-english-speakers, that wouldn’t have been written at all otherwise, 
so no loss.

But the greatest and first difficulty is that emacs is big and fast, so it 
should be done progressively, from the low level up, so APIs should be 
clearly divided, and modular… while emacs lisp still lacks any proper 
namespace system u.u

Another further difficulty is that not only translation is hard, but it is 
also somewhat contextual… sometimes, in a .po file, you need to go back to 
the source to see the context (and sometimes even run the program! to see 
the context of use) to understand how to translate… unfortunately, 
translating a program would require to understand even more context!  So 
it would need a special UI to fully see the original program while 
translating, otherwise it would be a mess, because any inconsistent 
translation would imply a bug

A special would be even more needed so you only translate strings/
identifiers at their definition.  So that when low-level API X and Y has 
been translated, some high-level API Z that would use X and Y would 
already have its “working” translated, and what would need to be 
translated would only be new defined identifiers: first and foremost 
“exported” ones (first prompts, menu bars, commands, docstrings) and then 
the “less useful”, “secondary”, “required to hack” stuff (internal 
functions, variable names, etc.).

This has never been done anywhere, but I can see how the first place where 
that would be really needed would be emacs, and the place where it would 
be the easiest to implement would also be emacs.  And if emacs succeed, it 
would either be very difficult elsewhere and thus emacs (maybe other lisps 
in general) would have a significant advantage, either it would spread from 
emacs and gives emacs hackability great advertisement.

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Alexandre Garreau wrote:

> Translating emacs would require to translate many
> identifiers, it would actually amount to translate
> a programming language

I don't think anyone suggests doing that, I think what can be
translated is *the interface*, so for example in the menu
"Quit" or "Exit" or whatever it says (I'm not a menu user)
_that_ would be translated. I don't think there are a lot of
advantages doing this, and I do see some DISadvantages, so
I think it shouldn't be done, actually, but the suggestion
isn't "translate everything", that would be an insane, almost,
rather than a bad suggestion.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Jean-Christophe Helary]

> On Jul 18, 2021, at 5:57, Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> 
> Alexandre Garreau wrote:
> 
>> Translating emacs would require to translate many
>> identifiers, it would actually amount to translate
>> a programming language
> 
> I don't think anyone suggests doing that, I think what can be
> translated is *the interface*, so for example in the menu
> "Quit" or "Exit" or whatever it says (I'm not a menu user)
> _that_ would be translated.

Along with the help and the other user-facing strings (for ex, some strings in package.el)

Doing the UI only is not useful. The UI and the help would be tremendously useful.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs i18n

[Alexandre Garreau]

Le dimanche 18 juillet 2021, 00:06:03 CEST Jean-Christophe Helary a écrit 
:
> > On Jul 18, 2021, at 5:57, Emanuel Berg via Users list for the GNU
> > Emacs text editor <help-gnu-emacs@gnu.org> wrote:> 
> > Alexandre Garreau wrote:
> >> Translating emacs would require to translate many
> >> identifiers, it would actually amount to translate
> >> a programming language
> > 
> > I don't think anyone suggests doing that, I think what can be
> > translated is *the interface*, so for example in the menu
> > "Quit" or "Exit" or whatever it says (I'm not a menu user)
> > _that_ would be translated.
> 
> Along with the help and the other user-facing strings (for ex, some
> strings in package.el)
> 
> Doing the UI only is not useful. The UI and the help would be
> tremendously useful.

For me, a great deal of emacs UI are command + docstring, and I bet a 
great deal of menu comes from command and variable names…

But that makes me think that something really useful would be translating 
the manual, especially the less changing parts u.u

Re: Emacs i18n

[Jean-Christophe Helary]

> On Jul 18, 2021, at 7:55, Alexandre Garreau <galex-713@galex-713.eu> wrote:
> 
> Le dimanche 18 juillet 2021, 00:06:03 CEST Jean-Christophe Helary a écrit 
> :
>>> On Jul 18, 2021, at 5:57, Emanuel Berg via Users list for the GNU
>>> Emacs text editor <help-gnu-emacs@gnu.org> wrote:> 
>>> Alexandre Garreau wrote:
>>>> Translating emacs would require to translate many
>>>> identifiers, it would actually amount to translate
>>>> a programming language
>>> 
>>> I don't think anyone suggests doing that, I think what can be
>>> translated is *the interface*, so for example in the menu
>>> "Quit" or "Exit" or whatever it says (I'm not a menu user)
>>> _that_ would be translated.
>> 
>> Along with the help and the other user-facing strings (for ex, some
>> strings in package.el)
>> 
>> Doing the UI only is not useful. The UI and the help would be
>> tremendously useful.
> 
> For me, a great deal of emacs UI are command + docstring, and I bet a 
> great deal of menu comes from command and variable names…
> 
> But that makes me think that something really useful would be translating 
> the manual, especially the less changing parts u.u

Bienvenu au club.

https://traduc.org/Emacs



-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean-Christophe Helary wrote:

> Bienvenu au club.

Plan jihad in you spare time please.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Date: Sun, 18 Jul 2021 00:55:48 +0200
> 
> For me, a great deal of emacs UI are command + docstring, and I bet a 
> great deal of menu comes from command and variable names…

No, it doesn't, at least not by and large.

> But that makes me think that something really useful would be translating 
> the manual, especially the less changing parts u.u

Translating the manuals is a no-brainer, and doesn't need any
infrastructure (except the method of installing manuals in different
languages on the same system, but that issue is not specific to Emacs,
it's a general Texinfo issue).

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Alexandre Garreau wrote:

> But that makes me think that something really useful would
> be translating the manual, especially the less changing
> parts

The usefulness of that: zéro

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean-Christophe Helary wrote:

> Doing the UI only is not useful. The UI and the help would
> be tremendously useful.

Anglo-American beat French to world dominance, accept it.
It happened everywhere, including diplomacy, but in particular
it happened in the world of computers. Where we happen to be
right now. There is no miniature world of computers where
everyone speaks French or any other language who badly needs
translations, drop it.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Thibaut Verron]

Le lun. 19 juil. 2021 à 04:00, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> a écrit :
>
> Jean-Christophe Helary wrote:
>
> > Doing the UI only is not useful. The UI and the help would
> > be tremendously useful.
>
> Anglo-American beat French to world dominance, accept it.
> It happened everywhere, including diplomacy,

Don't diplomats have interprets?

> but in particular
> it happened in the world of computers. Where we happen to be
> right now. There is no miniature world of computers where
> everyone speaks French or any other language who badly needs
> translations, drop it.

You've clearly never been to France. :) More seriously, a lot of
people in China and Japan, including in the software industry, do not
speak English. Translations would be very useful for them.

And all over the world, a lot of students who do not feel confident
with English treat the lack of available translations as a significant
hurdle, or even a barrier. That's true for a lot of things, from
scientific literature to, yes, software documentation.

Your replies in this thread strike me as unusually hostile. Why is it
such a big problem that some want to translate the emacs help and
manual?

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Thibaut Verron wrote:

>> Anglo-American beat French to world dominance, accept it.
>> It happened everywhere, including diplomacy,
>
> Don't diplomats have interprets?

They used to speak French, now they speak English.

We see traces of this in for example the Euro Vision Song
Contest where they tell the score in English and French.

But numbers don't lie, pick up a book from your bookshelf and
have a look, find a ISBN number with 13 digits (a so-called
ISBN-13, they start with 978- or 979 which is the GS1 prefix),
and tell me, what is the number immediately following the
GS1 prefix - i.e., the 4th number?

Please, just deal with it and go on, this is so embarrassing
every time it comes up :(

> You've clearly never been to France. :)

I've been to France, I've been to Belgium, I've met French and
Belgian programmers, French and Belgian students, French and
Belgian activists [1] (that has nothing to do with computers,
even), they _all_ speak very good English! Just like you two
guys do!

> More seriously, a lot of people in China and Japan,
> including in the software industry, do not speak English.

Wrong! They do, and they do even more and better for each
year, and the very small group who don't, well, they have
a HUGE problem that should be fixed by them putting ALL their
efforts learning English as soon as possible - it is
*impossible* to be a tech/science person 2021 and not knowing
English - luckily, this isn't the case, but if there were more
people like you translating stuff not even then could you
ever, ever do it to any extent that would mean a positive to
those very few who don't know English, it would be a NEGATIVE
since they would only have access to a small fraction of the
material available, and in the worst case they would be
deluding themselves thinking they are so great, while actually
living in a bubble 10 000 miles behind everyone else!

Luckily this isn't the case at all - French tech people and
French people in general have no problem whatsoever mastering
English, they want to do it, they benefit from it, everyone
else benefit from it, and most of all, it is the REALITY that
we have that everyone needs to accept for their own benefit!

Speak French to people on the street all you want - of course
- but the language of science and technology 2021 is English,
Anglo-American, and to a large extent American English (writhe
"color" in source, not "colour", however write that in the UK
tabloids, by all means). It _is_ English and I don't care who
had a lousy colonial empire or not...

> Translations would be very useful for them.

No, on the contrary, it would be a negative to them.

> And all over the world, a lot of students who do not feel
> confident with English treat the lack of available
> translations as a significant hurdle, or even a barrier.

100% incorrect.

> Your replies in this thread strike me as unusually hostile.
> Why is it such a big problem that some want to translate the
> emacs help and manual?

Yes, because I've heard this so many times before, all the
incorrect arguments, and it is bit provoking that it is ALWAYS
the French who brings this up no matter what e-mail list or
what tent on G8 in Rostock you are on! Every meeting, start
with a vote which the French guys insist on (despite speaking
English), French people propose French as the language (what
a surprise) and then get voted down 21-4, 14-3, 45-11
every time.

Why aren't the Russian, German and so on people who are also
part of huge language and language groups making this "French
case" you think?

Can it be that they are a bit more modest with respect to
their own language? Or do they simply understand like everyone
else what a huge benefit it is to them _and everyone_ with
a common langauge for science and technology, and they are
enthusiastic about learning this for their own
information-input but also the ambition to give their own
information-output?

Which, BTW, is exactly like the French are, so why on Earth
keep up with this charade?

#@$%&!

PS. ha :)

[1] https://dataswamp.org/~incal/blog/index.html

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Alexandre Garreau]

Le mercredi 21 juillet 2021, 07:24:36 CEST Emanuel Berg via Users list for 
the GNU Emacs text editor a écrit :
> Thibaut Verron wrote:
> >> Anglo-American beat French to world dominance, accept it.
> >> It happened everywhere, including diplomacy,
> > 
> > Don't diplomats have interprets?
> 
> They used to speak French, now they speak English.
> 
> We see traces of this in for example the Euro Vision Song
> Contest where they tell the score in English and French.

you are trying to demonstrate english is the most dominant language, 
*that* is embarrassing: why are you trying to demonstrate the obvious 
while everybody already agrees? it would be as embarassing as someone 
trying to demonstrate very hard that north america + europe is more 
powerful than the rest of the globe combined… okay, so what? is there any 
pride in it? nobody even *questioned* it here.

> Please, just deal with it and go on, this is so embarrassing
> every time it comes up :(

you are not the final authority on what is supposed to be embarrassing u.u

> > You've clearly never been to France. :)
> 
> I've been to France, I've been to Belgium, I've met French and
> Belgian programmers, French and Belgian students, French and
> Belgian activists [1] (that has nothing to do with computers,
> even), they _all_ speak very good English! Just like you two
> guys do!

you’ve been mostly with educated people, not with people who struggle 
learning, or are in less educated portion of society.

but you could ignore them in two ways: saying “enough people know about 
computer science, we don’t need more” (many people will disagree), and 
saying “emacs is only for programmers” (same…).  But this is getting 
repetitive, you are purposedly avoiding relevant arguments u.u

> > More seriously, a lot of people in China and Japan,
> > including in the software industry, do not speak English.
> 
> Wrong! They do, and they do even more and better for each
> year, and the very small group who don't,

no really try going to these places, most of people really don’t.  it’s 
logical you’ve been to europe, but there is even worse.

Actually, try even to go to eastern europe: the situation is “better” than 
in eastern asia, but still a looooot “worse” than rest of europe.

> well, they have
> a HUGE problem that should be fixed by them putting ALL their
> efforts learning English as soon as possible - it is
> *impossible* to be a tech/science person 2021 and not knowing
> English

it seems to me both of you are mixing two different matters: tech/science 
people and general people.  general people most often don’t master english 
as good as us, and of course the situation is better for english in tech/
science.

now I know I’m not the only one who believe it’s not bad that it’s 
possible to do science/tech without english.  I mean people in the 
influence spheres of china and russia do that commonly.  and yet I’m for 
globalization, but this is some sort of dogmatism that seems weird to me… 
why imposing stuff to people? if something is so important, the compressed 
version of it will eventually be translated to english and reach the wider 
world anyway…

> - luckily, this isn't the case, but if there were more
> people like you translating stuff not even then could you
> ever, ever do it to any extent that would mean a positive to
> those very few who don't know English, it would be a NEGATIVE
> since they would only have access to a small fraction of the
> material available,

a fraction that would not have been available before, I don’t see how 
that’s negative

> Luckily this isn't the case at all - French tech people and
> French people in general have no problem whatsoever mastering
> English,

of course we don’t, 75% of your vocabulary comes from our language, the 
only issue is when you need to speak it aloud… once you become fluent at 
it, you just resign to your eternal inferiority at not being able to 
distinguish 22 different vowels (and french is not really better with 17 
vowels among whose 4 nasals), added to the common stress, insecurity and 
other psychological issues that are really common among frenches about 
languages in general

> they want to do it, they benefit from it, everyone
> else benefit from it, and most of all, it is the REALITY that
> we have that everyone needs to accept for their own benefit!

so it is… so why do you need to claim it so loud and verbosely? I’d really 
like to know, I’ve never observed that reaction yet

Is it that you are particularely afraid about translation? does it sound 
like something obscurantist to you?

> > And all over the world, a lot of students who do not feel
> > confident with English treat the lack of available
> > translations as a significant hurdle, or even a barrier.
> 
> 100% incorrect.

how do you know? I mean yet asserting something may need a little proof… 
denying it (as the existence of anything) would need a lot more than that: 
how can you be so assertive about it?

> > Your replies in this thread strike me as unusually hostile.
> > Why is it such a big problem that some want to translate the
> > emacs help and manual?
> 
> Yes, because I've heard this so many times before, all the
> incorrect arguments, and it is bit provoking that it is ALWAYS
> the French who brings this up no matter what e-mail list or
> what tent on G8 in Rostock you are on! Every meeting, start
> with a vote which the French guys insist on (despite speaking
> English), French people propose French as the language (what
> a surprise) and then get voted down 21-4, 14-3, 45-11
> every time.

this is really hillarous (I’ve heard it so many times but never saw it 
myself yet), it recalls me some really hillarous excerpt from some czeck 
writer, Kundera.

> Why aren't the Russian, German and so on people who are also
> part of huge language and language groups making this "French
> case" you think?

why german? I would have said russian and mandarin and spanish.

especially russian actually.

actually it happens, but around russia.

it’s weird it happens more often for russian than spanish, while spanish 
is considered easier, and simpler to speak.

> Can it be that they are a bit more modest with respect to
> their own language? Or do they simply understand like everyone
> else what a huge benefit it is to them _and everyone_ with
> a common langauge for science and technology,

there always have been a common language, don’t worry, be it greek, latin, 
english, there always will be one, that’s natural, there’s nothing to be 
afraid about.

> Which, BTW, is exactly like the French are, so why on Earth
> keep up with this charade?

good question, do you think they’re aren’t the same french? what are the 
sociological differences you noticed between each groups?

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Alexandre Garreau wrote:

> you've been mostly with educated people, not with people who
> struggle learning, or are in less educated portion
> of society.

But the case is people don't know it good enough!

You guys on the other hand know it so well you can even do
professional translations...

So you, the Elysium ones, will attempt to help the ignorant
masses by translating ... uhm, CS and programming software
manuals?!

Hey, just a suggestion, shouldn't you elite guys instead try
to bring literacy, basic math, and punctuality, to your poor
countrymen that cannot read English 2021?

Hahah THE FRENCH, the guys with the French Revolution, the
Enlightenment Movement, the Paris Commune, even the supersonic
airliner the Concorde :) HAHAHAH :D

OKAY I know this isn't what you mean because it doesn't make
any sense whatsoever, but it is how it sounds, I still don't
understand what you actually mean TBH ???

>> Which, BTW, is exactly like the French are, so why on Earth
>> keep up with this charade?
>
> good question, do you think they’re aren’t the same french?
> what are the sociological differences you noticed between
> each groups?

The French were probably used to everyone speaking French and
if there was a foreigner around either it was an international
guy who spoke French or some other type of international guy,
namely from the French colonial empire, and everyone loved and
spoke great beautiful and cultural French and there was never
any other annoying other language around to mess up this
orderly and fantastic state that everyone was happy with?

No, I don't know actually, but that would be one guess that
comes to hand, yes. So, if you don't want it to, yeah, stop
brining this up, is what I'd do.

-- 
underground experts united
https://dataswamp.org/~incal

Emacs i18n

[Christopher Dimech]

> Sent: Wednesday, July 21, 2021 at 9:45 PM
> From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> Alexandre Garreau wrote:
> 
> > you've been mostly with educated people, not with people who
> > struggle learning, or are in less educated portion
> > of society.
> 
> But the case is people don't know it good enough!
> 
> You guys on the other hand know it so well you can even do
> professional translations...
> 
> So you, the Elysium ones, will attempt to help the ignorant
> masses by translating ... uhm, CS and programming software
> manuals?!
> 
> Hey, just a suggestion, shouldn't you elite guys instead try
> to bring literacy, basic math, and punctuality, to your poor
> countrymen that cannot read English 2021?

Should not local schools do that?

I can function in one or two languages, but still not under any obligation
to bring literacy and mathematical expression.  I can certainly bring clarity
but I mostly do it in english.  If one wants to be a disciple of a guru, one
has to go beyond one's limitations, rather than expecting the guru to sustain
their ego. 
 
> Hahah THE FRENCH, the guys with the French Revolution, the
> Enlightenment Movement, the Paris Commune, even the supersonic
> airliner the Concorde :) HAHAHAH :D
> 
> OKAY I know this isn't what you mean because it doesn't make
> any sense whatsoever, but it is how it sounds, I still don't
> understand what you actually mean TBH ???
> 
> >> Which, BTW, is exactly like the French are, so why on Earth
> >> keep up with this charade?
> >
> > good question, do you think they’re aren’t the same french?
> > what are the sociological differences you noticed between
> > each groups?
> 
> The French were probably used to everyone speaking French and
> if there was a foreigner around either it was an international
> guy who spoke French or some other type of international guy,
> namely from the French colonial empire, and everyone loved and
> spoke great beautiful and cultural French and there was never
> any other annoying other language around to mess up this
> orderly and fantastic state that everyone was happy with?
> 
> No, I don't know actually, but that would be one guess that
> comes to hand, yes. So, if you don't want it to, yeah, stop
> brining this up, is what I'd do.
> 
> -- 
> underground experts united
> https://dataswamp.org/~incal
> 
> 
>

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Christopher Dimech wrote:

>>> you've been mostly with educated people, not with people
>>> who struggle learning, or are in less educated portion
>>> of society.
>> 
>> But the case is people don't know it good enough!
>> 
>> You guys on the other hand know it so well you can even do
>> professional translations...
>> 
>> So you, the Elysium ones, will attempt to help the ignorant
>> masses by translating ... uhm, CS and programming software
>> manuals?!
>> 
>> Hey, just a suggestion, shouldn't you elite guys instead
>> try to bring literacy, basic math, and punctuality, to your
>> poor countrymen that cannot read English 2021?
>
> Should not local schools do that?

Of course. The schools, the societies.

Speaking frankly, our French Emacs guys should do their
professions to the ever improving best of their abilities, and
when that is done ... uhm, there is something that comes to
mind ... their families? unsure, does that make sense?

If they have ANY time left after that there is one and only
one allowed activity: Emacs and Elisp.

Translate huge books from English to French? Oh no, can't
have that. Nop-e. 403 Forbidden. Is what it is!

Possible loophole: What if they use Emacs while translating?
Allowed, but only if they spend at least 50% of the time not
actually translating but instead working on perfecting the
Elisp CAT software and associated English-French database (and
French-English for that matter, we just reverse the lists and
transpose the matrixes). This is how far I got BTW, and there
is more on that from the people on this list...

  https://dataswamp.org/~incal/emacs-init/ecat-incal.el

Please use it as a ... head start!

I think this is an area where FOSS and GNU/Linux (BSD etc) and
Emacs is a little bit behind, so if you guys can put us on the
top there just like with Gnus for mail we are, inspired by the
ideology of techno-totalitarianism perhaps, willing to grant
certain favors and exceptions, to show our appreciation.
Maybe a compromise, can you write the manual simultaneously in
several languages, in English _and_ French for example?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Alexandre Garreau]

Le mercredi 21 juillet 2021, 14:08:13 CEST Emanuel Berg via Users list for 
the GNU Emacs text editor a écrit :
> Possible loophole: What if they use Emacs while translating?

of cooourse, what else? haha

first form of encouragement, that’s good

> Allowed, but only if they spend at least 50% of the time not
> actually translating but instead working on perfecting the
> Elisp CAT software and associated English-French database (and
> French-English for that matter, we just reverse the lists and
> transpose the matrixes). This is how far I got BTW, and there
> is more on that from the people on this list...

the mapping aren’t bijective… actually nor injective nor surjective, I 
mean there is no perfect mapping from one language to another :/ and 
french is particularely nasty in that it tends to *very* quickly develop 
false friends, especially wrt english (it’s pretty astounishing O.o)

>   https://dataswamp.org/~incal/emacs-init/ecat-incal.el
> 
> Please use it as a ... head start!
> 
> I think this is an area where FOSS and GNU/Linux (BSD etc) and
> Emacs is a little bit behind, so if you guys can put us on the
> top there just like with Gnus for mail we are, inspired by the
> ideology of techno-totalitarianism perhaps, willing to grant
> certain favors and exceptions, to show our appreciation.
> Maybe a compromise, can you write the manual simultaneously in
> several languages, in English _and_ French for example?

would be cool…

Emacs i18n

[Christopher Dimech]

> Sent: Wednesday, July 21, 2021 at 5:24 PM
> From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> Thibaut Verron wrote:
>
> >> Anglo-American beat French to world dominance, accept it.
> >> It happened everywhere, including diplomacy,
> >
> > Don't diplomats have interprets?
>
> They used to speak French, now they speak English.
>
> We see traces of this in for example the Euro Vision Song
> Contest where they tell the score in English and French.
>
> But numbers don't lie, pick up a book from your bookshelf and
> have a look, find a ISBN number with 13 digits (a so-called
> ISBN-13, they start with 978- or 979 which is the GS1 prefix),
> and tell me, what is the number immediately following the
> GS1 prefix - i.e., the 4th number?
>
> Please, just deal with it and go on, this is so embarrassing
> every time it comes up :(
>
> > You've clearly never been to France. :)
>
> I've been to France, I've been to Belgium, I've met French and
> Belgian programmers, French and Belgian students, French and
> Belgian activists [1] (that has nothing to do with computers,
> even), they _all_ speak very good English! Just like you two
> guys do!
>
> > More seriously, a lot of people in China and Japan,
> > including in the software industry, do not speak English.

It would be an opportunity to civilise them.  So that one day, they can do
what the East Germans did.

> Wrong! They do, and they do even more and better for each
> year, and the very small group who don't, well, they have
> a HUGE problem that should be fixed by them putting ALL their
> efforts learning English as soon as possible - it is
> *impossible* to be a tech/science person 2021 and not knowing
> English - luckily, this isn't the case, but if there were more
> people like you translating stuff not even then could you
> ever, ever do it to any extent that would mean a positive to
> those very few who don't know English, it would be a NEGATIVE
> since they would only have access to a small fraction of the
> material available, and in the worst case they would be
> deluding themselves thinking they are so great, while actually
> living in a bubble 10 000 miles behind everyone else!
>
> Luckily this isn't the case at all - French tech people and
> French people in general have no problem whatsoever mastering
> English, they want to do it, they benefit from it, everyone
> else benefit from it, and most of all, it is the REALITY that
> we have that everyone needs to accept for their own benefit!
>
> Speak French to people on the street all you want - of course
> - but the language of science and technology 2021 is English,
> Anglo-American, and to a large extent American English (writhe
> "color" in source, not "colour", however write that in the UK
> tabloids, by all means). It _is_ English and I don't care who
> had a lousy colonial empire or not...

If you want to function in tho world, you got to learn english.
Otherwise you are on your own.  Good luck with that!

> > Translations would be very useful for them.

Then they should do it.  Or pay someone to do it.

> No, on the contrary, it would be a negative to them.
>
> > And all over the world, a lot of students who do not feel
> > confident with English treat the lack of available
> > translations as a significant hurdle, or even a barrier.

This would not solve the problem of doing real work.  Nobody
would care about that piece of software if not written in english.
I wonder how we never got any programming languages not in the
english language.  Because all those people were either living
in the United States or the United Kingdom.  Could be that the
French are still in denial in accepting such fact.  They were the
original developers and authors of computing technology.


> 100% incorrect.
>
> > Your replies in this thread strike me as unusually hostile.
> > Why is it such a big problem that some want to translate the
> > emacs help and manual?

I do not see a problem.  The problem is who would do it !

> Yes, because I've heard this so many times before, all the
> incorrect arguments, and it is bit provoking that it is ALWAYS
> the French who brings this up no matter what e-mail list or
> what tent on G8 in Rostock you are on! Every meeting, start
> with a vote which the French guys insist on (despite speaking
> English), French people propose French as the language (what
> a surprise) and then get voted down 21-4, 14-3, 45-11
> every time.
>
> Why aren't the Russian, German and so on people who are also
> part of huge language and language groups making this "French
> case" you think?
>
> Can it be that they are a bit more modest with respect to
> their own language? Or do they simply understand like everyone
> else what a huge benefit it is to them _and everyone_ with
> a common langauge for science and technology, and they are
> enthusiastic about learning this for their own
> information-input but also the ambition to give their own
> information-output?

Perhaps they cannot stand the fact that their Napoleon got
swept onto his back by the british, and then had to wait for
the british to save them from hitler.

> Which, BTW, is exactly like the French are, so why on Earth
> keep up with this charade?
>
> #@$%&!
>
> PS. ha :)
>
> [1] https://dataswamp.org/~incal/blog/index.html
>
> --
> underground experts united
> https://dataswamp.org/~incal
>
>
>

Re: Emacs i18n

[tomas]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Wed, Jul 21, 2021 at 10:28:16AM +0200, Christopher Dimech wrote:

[...]

> > > More seriously, a lot of people in China and Japan,
> > > including in the software industry, do not speak English.
> 
> It would be an opportunity to civilise them.  So that one day, they can do
> what the East Germans did.

I'd hope that to be ironic. Or is it xenophobic crap?

> If you want to function in tho world, you got to learn english.
> Otherwise you are on your own.  Good luck with that!

Such a load of nonsense. 

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Emacs i18n

[Christopher Dimech]

> Sent: Wednesday, July 21, 2021 at 8:39 PM
> From: tomas@tuxteam.de
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> On Wed, Jul 21, 2021 at 10:28:16AM +0200, Christopher Dimech wrote:
>
> [...]
>
> > > > More seriously, a lot of people in China and Japan,
> > > > including in the software industry, do not speak English.
> >
> > It would be an opportunity to civilise them.  So that one day, they can do
> > what the East Germans did.
>
> I'd hope that to be ironic. Or is it xenophobic crap?

People in Hong Kong and Taiwan would have something to say about that.
China has been doing things in a brutal manner.  As they get out of
poverty, they will rebel and trash communism.

> > If you want to function in tho world, you got to learn english.
> > Otherwise you are on your own.  Good luck with that!
>
> Such a load of nonsense.

If you want to really see truly fantastic children with great aspirations
anywhere, you must see those that have a mastery of the english language.
Particularly if the focus is to grow the human body and the human brain
to its full potential, without any intention of what they will become.



>  - t
>

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Christopher Dimech wrote:

> If you want to really see truly fantastic children with
> great aspirations anywhere, you must see those that have
> a mastery of the english language.

Well, let's not hit the biggest drum perhaps, but _yes_,
that's correct. It is breathtaking to behold actually, the
next generation, and the one after that... so much talent and
confidence everywhere :O

I personally always thought the old-schoolers were cooler but
maybe that was just my personality, watching some of the kids
and youngsters today, it feels like there is no limit to what
they can do, the sky is the limit, if any, and they know it
(many of them) ...

Pretty soon everyone that excels ever so slightly in almost
any field, including fields we don't know about today because
they are still embryonic or doesn't even exist yet, these
people will have the English language as just another ace in
their coat arm, and they won't even think about it or ever
hesitate to use it in any from, spoken, written, it will just
be there and taken for granted and instead they will focus on
doing amazing things where English will be just one of their
many assets...

These people will come from all over the world.
The traditionally rich countries have a head start, a little
edge if you will, maybe that will be so for the foreseeable
future but again, there is so much talent everywhere whoever
relies on that edge alone is "ute i ogjort väder" :)

-- 
underground experts united
https://dataswamp.org/~incal

Emacs i18n

[Christopher Dimech]

> Sent: Wednesday, July 21, 2021 at 10:52 PM
> From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> Christopher Dimech wrote:
> 
> > If you want to really see truly fantastic children with
> > great aspirations anywhere, you must see those that have
> > a mastery of the english language.
> 
> Well, let's not hit the biggest drum perhaps, but _yes_,
> that's correct. It is breathtaking to behold actually, the
> next generation, and the one after that... so much talent and
> confidence everywhere :O
> 
> I personally always thought the old-schoolers were cooler but
> maybe that was just my personality, watching some of the kids
> and youngsters today, it feels like there is no limit to what
> they can do, the sky is the limit, if any, and they know it
> (many of them) ...

It is my hope and my blessing that they would do much better things 
than we would do.
 
> Pretty soon everyone that excels ever so slightly in almost
> any field, including fields we don't know about today because
> they are still embryonic or doesn't even exist yet, these
> people will have the English language as just another ace in
> their coat arm, and they won't even think about it or ever
> hesitate to use it in any from, spoken, written, it will just
> be there and taken for granted and instead they will focus on
> doing amazing things where English will be just one of their
> many assets...
> 
> These people will come from all over the world.
> The traditionally rich countries have a head start, a little
> edge if you will, maybe that will be so for the foreseeable
> future but again, there is so much talent everywhere whoever
> relies on that edge alone is "ute i ogjort väder" :)

What has to happen is to liberate publishing.  To get all published
works on their computer and do searches with artificial intelligence.

But governments don't want that.  Governments only want research organisations
approved by them to extract information from data mining algorithms.
Of course the restrictions would not apply to them, as we are currently
being enlightened by the recent revelations of the Pegasus Project.  

Citizens all across the world must unite to end corporate and state surveillance,
whilst bringing data mining capabilities possible for citizens.

 
> -- 
> underground experts united
> https://dataswamp.org/~incal
> 
> 
>

Re: Emacs i18n

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2021-07-21 11:29]:
> > > And all over the world, a lot of students who do not feel
> > > confident with English treat the lack of available
> > > translations as a significant hurdle, or even a barrier.
> 
> This would not solve the problem of doing real work.  Nobody
> would care about that piece of software if not written in english.

To contrary I think many would have benefits with software written in
their language.

> I wonder how we never got any programming languages not in the
> english language.

Here are some references in the list:
https://en.wikipedia.org/wiki/Non-English-based_programming_languages

>  Because all those people were either living in the United States or
> the United Kingdom.

Because the computer science is based in English countries.

> Could be that the French are still in denial in accepting such fact.
> They were the original developers and authors of computing
> technology.

French based programming languages are: Logo, RoboMind, Catrobat,
AppleScript, ALGOL 68, GOTO++, Linotte, LSE, BASICOIS, SPIP, 4th
Dimension, so that is all from the above reference.

I find the idea of translating programming language very
important. 

And not that I find it hard to implement:

- I would use any programming language as the starting language;

- Any description defined would be defined in chunks so that automated
  programming works better. For example names of variables would not
  be names, rathre pointers to ID of the variable which then has
  entries for each programming language; same for functions and other
  objects;

- Then one would generate the language in the starting language;

- If translated it would be generated in the other language.

- I would demand more literate function naming;

Translation would speed up computer level knowledge in many other countries.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> French based programming languages are: Logo, RoboMind,
> Catrobat, AppleScript, ALGOL 68, GOTO++, Linotte, LSE,
> BASICOIS, SPIP, 4th Dimension, so that is all from the
> above reference.

Sorry, I disagree 100% with everything in your post but yes,
for the record no one is making the case the French didn't
contribute to the computer world, on the contrary as you show
(cool) but that isn't the issue, well, it hasn't been so far
anyway, I've been speaking of the computer world langauge
only, which happens to be ... not French. And it doesn't
matter what they did or didn't do, sorry.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Thibaut Verron]

On 21/07/2021 15:23, Emanuel Berg via Users list for the GNU Emacs text 
editor wrote:
> Jean Louis wrote:
>
>> French based programming languages are: Logo, RoboMind,
>> Catrobat, AppleScript, ALGOL 68, GOTO++, Linotte, LSE,
>> BASICOIS, SPIP, 4th Dimension, so that is all from the
>> above reference.
> Sorry, I disagree 100% with everything in your post but yes,
> for the record no one is making the case the French didn't
> contribute to the computer world, on the contrary as you show
> (cool) but that isn't the issue, well, it hasn't been so far
> anyway, I've been speaking of the computer world langauge
> only, which happens to be ... not French. And it doesn't
> matter what they did or didn't do, sorry.
>
You misread what Jean said. This is not a list of programming languages 
coming from France, it is a list of languages where some or all the 
keywords are in French, by default or optionally.

I personally don't support translating programming languages. I had too 
many unpleasant experiences with Excel/Libreoffice (I don't remember 
which one was translating the functions to French, but not both, and it 
was very confusing).

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Thibaut Verron wrote:

> You misread what Jean said. This is not a list of
> programming languages coming from France, it is a list of
> languages where some or all the keywords are in French, by
> default or optionally.

Yeah, I didn't recognize even most of them I think, but there
are languages from France, Prolog, right?

   Prolog 1972 France, Alain Colmerauer, logic/AI programming

that is the only hit for "France" in my HIST file:

  https://dataswamp.org/~incal/COMP-HIST
  https://dataswamp.org/~incal/bot/scripts/hist
  https://dataswamp.org/~incal/#bot

What about Pascal? Nope, Switzerland

  Pascal      1970 Niklaus Wirth. Switzerland

"Pascal Sol" is French, don't know what that is tho...

  Pascal Sol was designed around 1983 by a French team to
  implement a Unix-like system named Sol. It was standard
  Pascal level-1 ... The Sol team later on moved to the
  ChorusOS project to design a distributed operating system."
  <https://en.wikipedia.org/wiki/Pascal_(programming_language)>

Doesn't sound like they had a lot of success tho, see?
Should have named it after the great US space-geometry
mathematician Yogi Berra instead...

But I haven't systematically added "nationality" in the HIST
file so maybe some more French connections there, check it
out, if you'd like...

Here is some Prolog from a person (me) who didn't understood
it, but understood it enough not to like it, well, not for
that project anyway:

  https://dataswamp.org/~incal/terror-2/
  https://dataswamp.org/~incal/#terror

Prolog, CS Sudoku-solver logic-programming thing, right?
Too much science for me anyway... But I'm sure it's good.
I BTW had a friend who made an interface from Prolog to some
database, that to my astonishment when I heard of it didn't
exist at that point, so that was a cool thing he did, on the
BSc level even! I wish I could CC him this one decade after he
probably completed it...

> I personally don't support translating programming languages.
> I had too many unpleasant experiences with Excel/Libreoffice
> (I don't remember which one was translating the functions to
> French, but not both, and it was very confusing).

ikr? 100%

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Thibaut Verron]

On 21/07/2021 16:05, Emanuel Berg via Users list for the GNU Emacs text 
editor wrote:
> Thibaut Verron wrote:
>
>> You misread what Jean said. This is not a list of
>> programming languages coming from France, it is a list of
>> languages where some or all the keywords are in French, by
>> default or optionally.
> Yeah, I didn't recognize even most of them I think, but there
> are languages from France, Prolog, right?
>
>     Prolog 1972 France, Alain Colmerauer, logic/AI programming
>
> that is the only hit for "France" in my HIST file:
>
>    https://dataswamp.org/~incal/COMP-HIST
>    https://dataswamp.org/~incal/bot/scripts/hist
>    https://dataswamp.org/~incal/#bot

Caml, OCaml, and Scilab come to mind.

None of those are in French language so they didn't appear on Jean's list.

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Thibaut Verron wrote:

> Caml, OCaml, and Scilab come to mind

Thanks, now the list is

  4th Dimension
  ALGOL 68
  AppleScript
  BASICOIS
  Caml
  Catrobat
  GOTO++
  Linotte
  Logo
  LSE
  OCaml
  RoboMind
  Scilab
  SPIP

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Thibaut Verron]

Le mer. 21 juil. 2021 à 20:00, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> a écrit :
>
> Thibaut Verron wrote:
>
> > Caml, OCaml, and Scilab come to mind
>
> Thanks, now the list is
>
>   4th Dimension
>   ALGOL 68
>   AppleScript
>   BASICOIS
>   Caml
>   Catrobat
>   GOTO++
>   Linotte
>   Logo
>   LSE
>   OCaml
>   RoboMind
>   Scilab
>   SPIP

What list is that exactly? I've told you twice already that what Jean
gave you is a list of languages supporting a French-language syntax.
This is NOT a list of made-in-France languages.

Heck, it has Applescript in it! Since when is Apple French?

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Thibaut Verron wrote:

> What list is that exactly? I've told you twice already that
> what Jean gave you is a list of languages supporting
> a French-language syntax. This is NOT a list of
> made-in-France languages.

Don't worry, I'll check every item individually on the English
Wikipedia, primarily to be able to give a meaningful and
correct summary, but that happens to include ensuring that no
programming language will be incorrectly attributed to the
French-language sphere of techno-science practitioners.

-- 
underground experts united
https://dataswamp.org/~incal

Emacs i18n

[Christopher Dimech]

> Sent: Thursday, July 22, 2021 at 6:15 AM
> From: "Thibaut Verron" <thibaut.verron@gmail.com>
> To: "Emanuel Berg" <moasenwood@zoho.eu>, "help-gnu-emacs" <help-gnu-emacs@gnu.org>
> Subject: Re: Emacs i18n
>
> Le mer. 21 juil. 2021 à 20:00, Emanuel Berg via Users list for the GNU
> Emacs text editor <help-gnu-emacs@gnu.org> a écrit :
> >
> > Thibaut Verron wrote:
> >
> > > Caml, OCaml, and Scilab come to mind
> >
> > Thanks, now the list is
> >
> >   4th Dimension
> >   ALGOL 68
> >   AppleScript
> >   BASICOIS
> >   Caml
> >   Catrobat
> >   GOTO++
> >   Linotte
> >   Logo
> >   LSE
> >   OCaml
> >   RoboMind
> >   Scilab
> >   SPIP
> 
> What list is that exactly? I've told you twice already that what Jean
> gave you is a list of languages supporting a French-language syntax.
> This is NOT a list of made-in-France languages.

I can see reasons why learning to read mathematical works in French will be 
a better investment than in the other languages (assuming you already know 
English, of course).  

There is still a significant, though diminishing, proportion of papers, textbooks,
and research books which are written in French.   The proportion is about 1-2%.  
The production of research in any other language than English and French has essentially
come to a halt.
 
> Heck, it has Applescript in it! Since when is Apple French?
> 
>

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Christopher Dimech wrote:

> There is still a significant, though diminishing, proportion
> of papers, textbooks, and research books which are written
> in French. The proportion is about 1-2%. The production of
> research in any other language than English and French has
> essentially come to a halt.

ikr?

These algorithms from the paleo-scientific era of computing
are discontinued.

But: Can you verify these digits (1-2%, ->0) and/or give us
references, please?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

>> There is still a significant, though diminishing,
>> proportion of papers, textbooks, and research books which
>> are written in French. The proportion is about 1-2%.
>> The production of research in any other language than
>> English and French has essentially come to a halt.
>
> ikr?
>
> These algorithms from the paleo-scientific era of computing
> are discontinued.
>
> But: Can you verify these digits (1-2%, ->0) and/or give us
> references, please?

> ikr?
>
> These algorithms from the paleo-scientific era of computing
> are discontinued.
>
> But: Can you verify these digits (1-2%, ->0) and/or give us
> references, please?

Now we are getting somewhere, let's see, here where I live we
have three specifically computer-related educations on the
university level, namely

  * Computer Science
  (in theory the most theoretic but in practice the most
   practical one; master programs are (1) HCI, (2) CS which is
   more theory, perhaps for real this time [as in computations
   on real time models, indeed], and (3) embedded systems
   which is the coolest and most difficult one IMO because of
   the practical component and addition to theory, HCI should
   be the easiest altho nothing is "easy" on this level)

  * Information Technology Engineers
  (this is very close to CS actually and is as difficult and
   time-consuming, it has more math than CS and also a couple
   of random society-oriented courses, other than that they
   are virtually the same I'd say, and this also show in the
   big overlap with respect to courses and students; I always
   considered the IT guys as good as us and having virtually
   the same inclinations and comintment to "the cause")

  * Information Systems
  (this is something different, no overlap at all in courses
   or students with the CS and IT guys; I'd describe it as
   burocratic and administrative support systems for
   business - it is by far the least in-depth tech.
   this education isn't easy but not difficult, students who
   work moderately hard deal with it with no problems)

Can we get the stats - BSc, MSc, and PhD - what language? -
can we get the stats for these three internationally somehow?
to be able to compare and settle this for good with
hard facts?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Stefan Monnier via Users list for the GNU Emacs text editor]

> The production of research in any other language than English and
> French has essentially come to a halt.

That's what it looks like from the (big) bubble we're in, yes.
But I think China would beg to differ.


        Stefan

Emacs i18n

[Christopher Dimech]

> Sent: Thursday, July 22, 2021 at 7:40 AM
> From: "Stefan Monnier via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> > The production of research in any other language than English and
> > French has essentially come to a halt.
>
> That's what it looks like from the (big) bubble we're in, yes.
> But I think China would beg to differ.
>
>         Stefan

China's opinion is irrelevant and full of shit.

The Chinese Academy of Sciences approved the construction of a Bio-Security Level
4 laboratory in Wuhan in 2003, only because it was designed and constructed with
French assistance as part of a 2004 cooperative agreement.  China lacks experience.

Academic corruption is rampant in China with the prevalence of fraud, plagiarism
and fabricated research in academic publishing.  It is the nation with the most
retracted papers and fake peer-review as from 2010.

With more than 50% of all articles retracted by scientific journals worldwide for
articles submitted by Chinese authors.

Re: Emacs i18n

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> > The production of research in any other language than English and
>> > French has essentially come to a halt.
>> That's what it looks like from the (big) bubble we're in, yes.
>> But I think China would beg to differ.
> China's opinion is irrelevant and full of shit.

Your prejudice doesn't change the fact that a significant (and arguably
an increasing) amount of research is done in chinese.


        Stefan

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> China's opinion is irrelevant and full of shit.
>
> Your prejudice doesn't change the fact that a significant
> (and arguably an increasing) amount of research is done
> in chinese.

I believe you, but how do you know that?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Stefan Monnier via Users list for the GNU Emacs text editor]

Emanuel Berg via Users list for the GNU Emacs text editor [2021-07-21 23:58:31] wrote:
> Stefan Monnier via Users list for the GNU Emacs text editor wrote:
>>> China's opinion is irrelevant and full of shit.
>> Your prejudice doesn't change the fact that a significant
>> (and arguably an increasing) amount of research is done
>> in Chinese.
> I believe you, but how do you know that?

Only occasional anectodal "evidence", sorry.

But for example https://www.nature.com/articles/d41586-021-01076-x
refers to a major increase in funding in China, and while AFAIK top
research from China still aims to publish in English venues (which are
still more prestigious and give more exposure), I expect a large
fraction of that research is only published in Chinese (after all, the
Chinese speaking audience is already fairly large ;-)


        Stefan


PS: While the above talks about science in general, my own experience is
limited to computer science, where English is arguably even more
entrenched than in other fields.

Emacs i18n

[Christopher Dimech]

Nature is a predatory journal.

How many chinese language articles have you read?  What really important information
do they contain, and how are they crucial to read?  When a similar thing was done
in russia, almost everything has by now been forgotten.

> Sent: Thursday, July 22, 2021 at 10:55 AM
> From: "Stefan Monnier via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> Emanuel Berg via Users list for the GNU Emacs text editor [2021-07-21 23:58:31] wrote:
> > Stefan Monnier via Users list for the GNU Emacs text editor wrote:
> >>> China's opinion is irrelevant and full of shit.
> >> Your prejudice doesn't change the fact that a significant
> >> (and arguably an increasing) amount of research is done
> >> in Chinese.
> > I believe you, but how do you know that?
>
> Only occasional anectodal "evidence", sorry.
>
> But for example https://www.nature.com/articles/d41586-021-01076-x
> refers to a major increase in funding in China, and while AFAIK top
> research from China still aims to publish in English venues (which are
> still more prestigious and give more exposure), I expect a large
> fraction of that research is only published in Chinese (after all, the
> Chinese speaking audience is already fairly large ;-)
>
>
>         Stefan
>
>
> PS: While the above talks about science in general, my own experience is
> limited to computer science, where English is arguably even more
> entrenched than in other fields.
>
>
>

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Christopher Dimech wrote:

> How many chinese language articles have you read?
> What really important information do they contain, and how
> are they crucial to read?

Don't the citation system determine this for us?

What's the most quoted paper in Computer Science?

That's the best one by definition, if these are the rules.

Indeed, were are the rules anyone, and where are the stats?

Because then everyone could just look at the stats and decide
for themselves in 1 second?

> When a similar thing was done in russia, almost everything
> has by now been forgotten.

Heh, check out the URL below for Putin's fake thesis. In the
book, which is anti-Putin BTW, it says Putin was that much of
a stand-up guy after becoming president, he never claimed to
have or mentioned that "degree" of his to anyone :)

%% Maria Alexandrovna Gessen
%% Putin's purchased thesis: https://www.rferl.org/a/1067113.html
@book{mannen-utan-ansikte,
  author     = {Masha Gessen},
  isbn       = {978-91-7337-484-2},
  preface    = {Stig Fredrikson},
  pages      = {436},
  publisher  = {Bromberg},
  title      = {Mannen utan ansikte (The Man Without a Face: The Unlikely Rise of Vladimir Putin)},
  translator = {Nille Lindgren},
  year       = {2013 (2012)}
}

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[tomas]

[-- Attachment #1: Type: text/plain, Size: 159 bytes --]


On Thu, Jul 22, 2021 at 10:11:22AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
[...]
emacs-tangents, please. Pretty please.

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Emacs i18n

[Christopher Dimech]

----- Christopher Dimech
Administrator General - Naiad Informatics - Gnu Project

Society has become too quick to pass judgement and declare someone
Persona Non-Grata, the most extreme form of censure a country can
bestow.

In a new era of destructive authoritarianism, I support Richard
Stallman.  Times of great crisis are also times of great
opportunity.  I call upon you to make this struggle yours as well !

https://stallmansupport.org/
https://www.fsf.org/     https://www.gnu.org/


> Sent: Thursday, July 22, 2021 at 8:11 PM
> From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> Christopher Dimech wrote:
>
> > How many chinese language articles have you read?
> > What really important information do they contain, and how
> > are they crucial to read?
>
> Don't the citation system determine this for us?
>
> What's the most quoted paper in Computer Science?

It is the highly influential paper of how products can be made cheap,
and with the highest profit margins.  Which the Chinese Manufacturing
Companies do by outsourcing in Africa.  Welcome to the New Slave Trade.

> That's the best one by definition, if these are the rules.
>
> Indeed, were are the rules anyone, and where are the stats?
>
> Because then everyone could just look at the stats and decide
> for themselves in 1 second?
>
> > When a similar thing was done in russia, almost everything
> > has by now been forgotten.
>
> Heh, check out the URL below for Putin's fake thesis. In the
> book, which is anti-Putin BTW, it says Putin was that much of
> a stand-up guy after becoming president, he never claimed to
> have or mentioned that "degree" of his to anyone :)
>
> %% Maria Alexandrovna Gessen
> %% Putin's purchased thesis: https://www.rferl.org/a/1067113.html
> @book{mannen-utan-ansikte,
>   author     = {Masha Gessen},
>   isbn       = {978-91-7337-484-2},
>   preface    = {Stig Fredrikson},
>   pages      = {436},
>   publisher  = {Bromberg},
>   title      = {Mannen utan ansikte (The Man Without a Face: The Unlikely Rise of Vladimir Putin)},
>   translator = {Nille Lindgren},
>   year       = {2013 (2012)}
> }
>
> --
> underground experts united
> https://dataswamp.org/~incal
>
>
>

Re: Emacs i18n

[Eli Zaretskii]

> Date: Wed, 21 Jul 2021 17:44:46 -0400
> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> >> > The production of research in any other language than English and
> >> > French has essentially come to a halt.
> >> That's what it looks like from the (big) bubble we're in, yes.
> >> But I think China would beg to differ.
> > China's opinion is irrelevant and full of shit.
> 
> Your prejudice doesn't change the fact that a significant (and arguably
> an increasing) amount of research is done in chinese.

This tangent should either stop or be taken to emacs-tangents.

I urger everyone to please stop posting about this stuff here.

Emacs i18n

[Christopher Dimech]

> Sent: Thursday, July 22, 2021 at 9:44 AM
> From: "Stefan Monnier via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> >> > The production of research in any other language than English and
> >> > French has essentially come to a halt.
> >> That's what it looks like from the (big) bubble we're in, yes.
> >> But I think China would beg to differ.
> > China's opinion is irrelevant and full of shit.
>
> Your prejudice doesn't change the fact that a significant (and arguably
> an increasing) amount of research is done in chinese.

To get really back on topic, nobody started to work on multilingualisation
seriously.  I support the idea of a multilingualisation framework, but a focus
on particular languages such as chinese is misguided.

Peaple conversant in particular language can then have the capability
of doing that specific work.

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> The production of research in any other language than
>> English and French has essentially come to a halt.
>
> That's what it looks like from the (big) bubble we're in,
> yes. But I think China would beg to differ.

Is it possible to get hard facts, as in digits somewhere?

For the FOSS world: mailing list traffic (either in K or
perhaps more easily in the number of posts) in the devel and
user/help lists for a set of iconic software, e.g., CL,
Debian, Emacs, irssi, Linux, rsync, ssh, tmux, X, xterm,
and zsh?

How many posts are in the general (English) lists and how many
posts in other language-specific lists, dealing with the same
software, e.g. the corresponding French list, if available?

And for the university world: say math, CS, IT, Information
systems, and Engineering physics? How many BSc, MSc, and PhD
papers are in English and how many in other languages, e.g.
how many are in French?

And yes data for China as well would be nice. The more the
merrier...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[tomas]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Wed, Jul 21, 2021 at 11:57:40PM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Stefan Monnier via Users list for the GNU Emacs text editor wrote:
> 
> >> The production of research in any other language than
> >> English and French has essentially come to a halt.
> >
> > That's what it looks like from the (big) bubble we're in,
> > yes. But I think China would beg to differ.
> 
> Is it possible to get hard facts, as in digits somewhere?

emacs-tangents, please.

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

>>>> The production of research in any other language than
>>>> English and French has essentially come to a halt.
>>>
>>> That's what it looks like from the (big) bubble we're in,
>>> yes. But I think China would beg to differ.
>> 
>> Is it possible to get hard facts, as in digits somewhere?
>
> emacs-tangents, please.

The Computer Science university and research world is relevant
to Emacs, and we want to be relevant there with our software.

And stats and facts make discussions more on-topic, not less,
don't you think?

Then all the ranting could be replaced by, "Mes braves, take
a look at the stats, think, and decide for yourself."

-- 
underground experts united
https://dataswamp.org/~incal

Emacs i18n

[lisa-asket]

From: Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: Emacs i18n
Date: 22/07/2021 10:17:14 Europe/Paris

tomas wrote:

>>>> The production of research in any other language than
>>>> English and French has essentially come to a halt.
>>>
>>> That's what it looks like from the (big) bubble we're in,
>>> yes. But I think China would beg to differ.
>> 
>> Is it possible to get hard facts, as in digits somewhere?
>
> emacs-tangents, please.

>The Computer Science university and research world is relevant
>to Emacs, and we want to be relevant there with our software.



The argument is to convince us to write in Chinese so we can be relevant ?

If they want they can do that themselves ! 

RE: [External] : Re: Emacs i18n

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

> > The production of research in any other language than English and
> > French has essentially come to a halt.
> 
> That's what it looks like from the (big) bubble we're in, yes.
> But I think China would beg to differ.

+1

And no need to beg.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 14184 bytes --]

Re: [External] : Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>>> The production of research in any other language than
>>> English and French has essentially come to a halt.
>> 
>> That's what it looks like from the (big) bubble we're in,
>> yes. But I think China would beg to differ.
>
> +1
>
> And no need to beg.

What is "research" here, the PhD level?

There are only three languages active on that level, English,
French, and Chinese?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Emacs i18n

[tomas]

[-- Attachment #1: Type: text/plain, Size: 145 bytes --]

On Thu, Jul 22, 2021 at 06:08:49AM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:

[...]

emacs-tangents, please.

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> French based programming languages are: Logo, RoboMind,
> Catrobat, AppleScript, ALGOL 68, GOTO++, Linotte, LSE,
> BASICOIS, SPIP, 4th Dimension, so that is all from the
> above reference.

"French-based", uhm, what does that mean? ALGOL 68 seems to be
a Swiss/Dutch thing?
<https://en.wikipedia.org/wiki/ALGOL>

Switzerland, is that what you mean? In Belgium they speak
French in the capital which is more international I guess, but
I heard the administration does everything double! And also in
the southern part (~half) around Liège which has dominated
politically historically, or am I wrong? But the Dutch guys,
what do they speak? Dutch? Which is close to German,
absolutely not French? But they speak French in Switzerland
(among other languages) so that what you mean?

Anyway big thanks for that list Jean, looks very exotic!
I only know (have heard of) Logo and ALGOL. I'll add them to
the HIST file sometime soon, God willing! Keep 'em coming,
French or not...

  https://dataswamp.org/~incal/COMP-HIST
  https://dataswamp.org/~incal/bot/scripts/hist
  https://dataswamp.org/~incal/#bot

-- 
underground experts united
https://dataswamp.org/~incal

Emacs i18n

[Christopher Dimech]

> Sent: Thursday, July 22, 2021 at 12:56 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org, moasenwood@zoho.eu
> Subject: Re: Emacs i18n
>
> * Christopher Dimech <dimech@gmx.com> [2021-07-21 11:29]:
> > > > And all over the world, a lot of students who do not feel
> > > > confident with English treat the lack of available
> > > > translations as a significant hurdle, or even a barrier.
> >
> > This would not solve the problem of doing real work.  Nobody
> > would care about that piece of software if not written in english.
>
> To contrary I think many would have benefits with software written in
> their language.
>
> > I wonder how we never got any programming languages not in the
> > english language.
>
> Here are some references in the list:
> https://en.wikipedia.org/wiki/Non-English-based_programming_languages
>
> >  Because all those people were either living in the United States or
> > the United Kingdom.
>
> Because the computer science is based in English countries.
>
> > Could be that the French are still in denial in accepting such fact.
> > They were the original developers and authors of computing
> > technology.
>
> French based programming languages are: Logo, RoboMind, Catrobat,
> AppleScript, ALGOL 68, GOTO++, Linotte, LSE, BASICOIS, SPIP, 4th
> Dimension, so that is all from the above reference.
>
> I find the idea of translating programming language very
> important.

It is the same problem of translating english publications to other languages.
Rarely happens.  Although the best works almost always get translated, because
there exists a market for them.

The Adventures of Pinocchio is best :)

Alice's Adventures in Wonderland
Andersen's Fairy Tales
El Ingenioso Hidalgo Don Quijote de la Mancha
The Adventures of Asterix
The Adventures of Tintin
Harry Potter
Bhagavad Gita
The Diary of a Young Girl
Winnie-the-Pooh
Pippi Longstocking
The Alchemist
The Adventures of Huckleberry Finn
Nineteen Eighty-Four
Isha Upanishad


> And not that I find it hard to implement:
>
> - I would use any programming language as the starting language;
>
> - Any description defined would be defined in chunks so that automated
>   programming works better. For example names of variables would not
>   be names, rathre pointers to ID of the variable which then has
>   entries for each programming language; same for functions and other
>   objects;
>
> - Then one would generate the language in the starting language;
>
> - If translated it would be generated in the other language.
>
> - I would demand more literate function naming;
>
> Translation would speed up computer level knowledge in many other countries.
>
>
> --
> Jean
>
> Take action in Free Software Foundation campaigns:
> https://www.fsf.org/campaigns
>
> In support of Richard M. Stallman
> https://stallmansupport.org/
>
>

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Christopher Dimech wrote:

> It is the same problem of translating english publications
> to other languages. Rarely happens. Although the best works
> almost always get translated, because there exists a market
> for them.
>
> The Adventures of Pinocchio is best :)
>
> Alice's Adventures in Wonderland
> Andersen's Fairy Tales
> El Ingenioso Hidalgo Don Quijote de la Mancha
> The Adventures of Asterix
> The Adventures of Tintin
> Harry Potter
> Bhagavad Gita
> The Diary of a Young Girl
> Winnie-the-Pooh
> Pippi Longstocking
> The Alchemist
> The Adventures of Huckleberry Finn
> Nineteen Eighty-Four
> Isha Upanishad

From the Franco-Belgian comic book bande dessinée industry,
craft, and art form:

  Blueberry
  The Incal (not in the list below)
  The Metabarons (*)
  Thorgal
  ... and many others

(*) Here the script author, Alejandro Jodorowsky, is Chilean
    (or Chilean-French they say officially, that's news for
    me, he is more South American than French to the style
    anyway)
    <https://en.wikipedia.org/wiki/Alejandro_Jodorowsky> and
    the artist, Juan Giménez, is from Argentine, but they
    belong to the French Métal Hurlant sphere nonthesame, and
    Jean Giraud AKA Moebius (of France) drew old-school Incal
    ("L'Incal") where the Metabaron appeared as a character,
    so it is French despite or much thanks to the awesome work
    of Giménez, Giraud, and Jodorowsky.
    
https://dataswamp.org/~incal/books/books.bib

%%%% Thorgal

@book{thorgal,
  author     = {Jean Van Hamme and Grzegorz Rosinski},
  isbn       = {91-7089-710-7},
  publisher  = {Casablanca},
  title      = {Thorgal: Den onde guden},
  year       = {1993 (1987)}
}

@book{thorgals-varld-kriss-3,
  author     = {De Vita and Sente and Dorison and Mariolle and Surzhenko},
  isbn       = {978-91-88897-00-8},
  publisher  = {Cobolt},
  title      = {Thorgals värld: Kriss från Valnor 3},
  year       = {2019 (2014-2015)}
}

@book{thorgals-varld-kriss-2,
  author     = {De Vita and Yves Sente},
  isbn       = {978-91-87861-74-1},
  publisher  = {Cobolt},
  title      = {Thorgals värld: Kriss från Valnor 2: Krigardrottningen},
  year       = {2018}
}

@book{thorgal-5,
  author     = {Jean Van Hamme and Grzegorz Rosinski},
  isbn       = {978-91-87861-68-0},
  publisher  = {Cobolt},
  title      = {Thorgal 5: Genom tid och rum},
  year       = {2017 (1989-91)}
}

@book{thorgal-3,
  author     = {Jean Van Hamme and Grzegorz Rosinski},
  isbn       = {978-91-87861-21-5},
  publisher  = {Cobolt},
  title      = {Thorgal 3: Vikingar och gudar},
  year       = {2016 (1988)}
}

@book{thorgal-2,
  author     = {Jean Van Hamme and Grzegorz Rosinski},
  isbn       = {978-91-87861-12-3},
  publisher  = {Cobolt},
  title      = {Thorgal 2: I fiendens spår},
  year       = {2015}
}

%%%% Metabarons

@book{metabarons-poet-and-killer,
  author     = {Alexandro Jodorowsky and Juan Giménez},
  isbn       = 1930652232,
  publisher  = {Humanoids},
  title      = {Metabarons: Poet and Killer},
  year       = {2002}
}

@book{metabarons-path-of-the-warrior,
  author     = {Alexandro Jodorowsky and Juan Giménez},
  isbn       = {193065247X},
  publisher  = {Humanoids},
  title      = {Metabarons: Path of the Warrior},
  year       = {2002}
}

%%%% Blueberry

@book{blueberry-8,
  author     = {Jean-Michael Charlier and Jean Giraud},
  isbn       = {978-91-87861-99-4},
  publisher  = {Cobolt},
  title      = {Blueberry 8},
  year       = {2019 (1990-1999)}
}

@book{blueberry-6,
  author     = {Jean-Michael Charlier and Jean Giraud},
  isbn       = {978-91-87861-84-0},
  publisher  = {Cobolt},
  title      = {Blueberry 6},
  year       = {2018 (1974-1980)}
}

@book{blueberry-5,
  author     = {Jean-Michael Charlier and Jean Giraud},
  isbn       = {978-91-87861-67-3},
  publisher  = {Cobolt},
  title      = {Blueberry 5},
  year       = {2017}
}

@book{blueberry-4,
  author     = {Jean-Michael Charlier and Jean Giraud},
  isbn       = {978-91-87861-54-3},
  publisher  = {Cobolt},
  title      = {Blueberry 4},
  year       = {2017 (1968-1970)}
}

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Alexandre Garreau]

Le lundi 19 juillet 2021, 03:51:08 CEST Emanuel Berg via Users list for 
the GNU Emacs text editor a écrit :
> Jean-Christophe Helary wrote:
> > Doing the UI only is not useful. The UI and the help would
> > be tremendously useful.
> 
> Anglo-American beat French to world dominance, accept it.

Nobody told in this thread French had any world dominance.  Although you 
may note that the concern about english is often raised by french people, 
and maybe for some sort of inconscious nationalism or rempent national 
aversion toward english due to that previous context, the concern stays 
valid, and you cannot cancel an argument validity due to the people who 
raise it.

> There is no miniature world of computers where
> everyone speaks French or any other language who badly needs
> translations, drop it.

There is, not only in france, but any non-germanic place I have been 
through.  English, just like french, is a difficult language, with lot of 
vocabulary.  You’re living is a small-world utopia that’s nowhere near 
even realistic.

Even those who *fluently* speak english are commonly *tired* with it.  Even 
I, and actually anybody because that’s natural, would choose to read 
something in their native(s) language(s) rather than a foreign one, and 
doing that would imply less effort, energy spent, hence more reading and 
work done than if done through english.

Just to be sure, you’re a native speaker of english right? so how could 
you even *know* that? or have you tried to work in mandarin on the ground 
that its syntax is said to be simple and flexionless, to say it’s as easy 
as in your native language? otherwise, do you have studies showing the 
opposite? since you’re not the one bringing the argument, the burden of 
proof should fall on us, and currently I’m being lazy at it, but if anyone 
brings such studies (which shouldn’t be any more difficult to find than any 
study, but I’m bad at searching) I doubt you would have anything to oppose 
to that u.u

There are everywhere teachings of CS in english *as a special matter*, 
that’s a way to *train* for english because that training is *needed* 
because it is nonnatural, and it is a difficulty and people try lowering it 
by confronting to it… yet most of courses are in the national language, 
not english.  Some vocabulary obviously comes from english, and 
englishisms are present more often than not, but the grammar, phonology, 
orthography, syntax, and most of vocabulary we use stay our national (or 
even sometimes, with luck (that means not in france) the local one) 
language.

It is up to the point I’ve personally observed that something translated 
is perceived as more “user-friendly” than something graphical, variable-
spaced and colored, up to the point that this common cliché of white 
monospace text on black background with no graphics, no mouse and none 
input but keyboard, that scares many outsiders, newcomers, etc., stays 
less deterring than an all english interface.  In this respect emacs still 
performs badly, and I can’t recommend it to many people I know, especially 
non-programmers, because of that (and it would be sad for you to take as 
argument “emacs is only for programmers and CS-ists”).

That would be the kind of “user-friendliness”, btw, that may have an 
effective impact on making more women or minorities join CS, and moreover 
less occidental, as that concern has come more into fashion recently.

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Alexandre Garreau wrote:

>> Anglo-American beat French to world dominance, accept it.
>
> Nobody told in this thread French had any world dominance.
> Although you may note that the concern about english is
> often raised by french people

They are the ONLY people who EVER brings this up.

> and maybe for some sort of inconscious nationalism or
> rempent national aversion toward english due to that
> previous context, the concern stays valid, and you cannot
> cancel an argument validity due to the people who raise it.

We WANT the French-speaking people, and they are here already
as we clearly see, but this isn't the 70s anymore where there
were one "expert" on the same subject in every god damned
country who had read a couple of 12 books on the subject and
wrote a nice summary on in, resembling pretty much exactly
what some other dude did in some other country reading his 12
books! The langauge of science and technology IS English, it
if had been French I would have written the same thing, only
in defense of French - but it _isn't_ French, and everyone
understands that - even the French, as we clearly see - but
unlike everyone else, the French pretends or do not accept
this in some places of their minds, so they bring this up over
and over, #$&%@!

>> There is no miniature world of computers where everyone
>> speaks French or any other language who badly needs
>> translations, drop it.
>
> There is

THERE IS NOT, and whatever fraction there is is getting
smaller by the day, it isn't a place were you yourself would
like to be restricted to, so why ever would you like that for
your compatriots that are, BTW, fully capable of learning
English just like everyone else? In fact, the French language
is much closer to English than a lot of other languages, there
is no disadvantage at all in any sense or in anyway, and we
see this every day when we speak English to people from the
French-speaking world!

> not only in france, but any non-germanic place I have been
> through. English, just like french, is a difficult language

No, because of popular culture, technology, and proximity of
languages it is very easy for anyone these days to learn
English, if the have any ambitions whatsoever with science and
technology they already know English before they even enter
the university?

> with lot of vocabulary. You’re living is a small-world
> utopia that’s nowhere near even realistic.

We live in the same world of science and technology where the
language is English, maybe it made sense in the 70-80s to
translate the man pages or whatever (the French were the only
ones who got close BTW, that said French programmers today are
typically _not_ using that old, incomplete, un-updated stuff
were you have to wonder - even if it was perfect, which it is
not and cannot be, so no disrespect to the translators - even it
if was perfect they'd still have to wonder about what
everything is, what is interface, hash algorithm, API, proxy, client-server,
raster, shading langauge, checksum, compression with the use
of tagged chunks, Alice and Bob in French? why aren't the
English-language software options congruent with ... wait,
what terms are we using, even? The French or the English?
(Oh, I know Alice and Bob - Abelard et Héloïse, n'est-ce pas?)

> Even those who *fluently* speak english are commonly *tired*
> with it.

No, that is true only in the initial, beginner phase, then on
the contrary one gets tired of reading it in a language that
is _foreign_ to it, the _native_ language is always the best
and the native language in the science and technology world is
English, US English in particular.

> Even I, and actually anybody because that’s natural, would
> choose to read something in their native(s) language(s)
> rather than a foreign one

English isn't foreign here, it is the native language of
the field.

> Just to be sure, you’re a native speaker of english right?

Hahaha :) Are you kidding, I'm Swedish! That said, these
rantings are to be put on my account solely, I'm sure many of
my countrymen who reads this thinks I'm insane or something...
ha :)

> or have you tried to work in mandarin

This instant, in another buffer I have a friend on IRC from
ROC and he speaks better English than me (he thinks that at
least :)) and I was a CS student when Sweden offered courses
free of charge (now they do that only to EU contrives) so every
course, taught in English, was like 50% people from China!
I lived in a student house for 7 years with a configuration of
Chinese people ALWAYS present at one time or the other,
EVERYONE spoke English, all the books were in English, exams
were in English, the Chinese guys were sometimes a weird bunch
to deal with on an everyday basis but the problem was _never_
their or mine or anyone else's (certainly not the French who
were also there, but in much smaller numbers) NO ONE had any
problem whatsoever with the English, trust me!

> on the ground that its syntax is said to be simple and
> flexionless, to say it’s as easy as in your native language?

I'm not saying I or anyone else is as good with English as we
are with our own languages, except for when speaking of one
thing - technology. The language is of course not perfect, how
could it ever be, but it is "good enough for government work",
good enough for the intended purpose. (I don't think my
English as in English in general is that good actually, maybe
my ROC friend is right.)

> otherwise, do you have studies showing the opposite?

We don't need studies, we have something stronger, reality.

> There are everywhere teachings of CS in english *as
> a special matter*, that’s a way to *train* for english
> because that training is *needed* because it is nonnatural,
> and it is a difficulty and people try lowering it by
> confronting to it... yet most of courses are in the national
> language, not english.

Not here. But that's OK, I'm not saying all universities that
teach technology must necessarily do everything in English
this very instant. But that's were we are heading anyway.
In the 70s everyone wrote their PhDs in their own languages.
Now people even write their BSc in English. There will only be
more and more of this and that's a good thing. Those who don't
will be at a disadvantage. Those who do not know _any_ English
will be at such a disadvantage they won't be able to
contribute or acquire information in a way that make them even
belong, sorry.

> Some vocabulary obviously comes from english, and
> englishisms are present more often than not, but the
> grammar, phonology, orthography, syntax, and most of
> vocabulary we use stay our national (or even sometimes, with
> luck (that means not in france) the local one) language.

Yes, of course, but it isn't about that, it is about English
as a tool to communicate about technology, it isn't about the
beauty of the language, I'm sure some of the things I write
would make a Grammar School teacher blush, but that's OK, it
is at this point unavoidable and perhaps that will always be
like that, even, but even now and long before I write this
people have collaborated on zillion projects speaking English -
and French and Russian also, and Swedish even - only these
languages didn't make it to the #1 position that English has,
right here and right now - so instead of translating, if you
want to help "your" people (not necessary IMO, but OK) what
you should do is became English _teachers_, not translators,
and teach the very, very rare technology GENIUS who can do
EVERYTHING with a keyboard but cannot speak or write a word
of English - I don't believe these people exist in their
miniature worlds consisting of themselves and equally
language-blind friends hacking the Pentagon and Fort Knox - but
if you find them, YES, do us all a favor and tech them English
so we all can be helped by their marvelous work, and maybe
help them a bit as well hehe :)

> emacs is only for programmers and CS-ists

Yes, but it is much, much broader than that, you don't have to
be a programmer, it is enough to have a smartphone and
smart-TV and god damn computer, this has already contributed
A LOT to how people speak English, Germans at 20 for example
speak much better English than I did, when I was 20 (and then
I thought Germans couldn't speak English at all, maybe), so
NO, it is not necessary for you to be an Emacs user or
programmer, everyone that uses technology is benefited
tremendously for knowing English and it works both ways,
technology makes you better at English (ordinary English,
between humans) as well, because English is not the langauge
of just nations like the US, England <3, Australia <3 and so
on, it is also the language of TECHNOLOGY, so make people
COME, don't work on things that will make them NOT COME @%&#$!

> That would be the kind of "user-friendliness", btw, that may
> have an effective impact on making more women or minorities
> join CS, and moreover less occidental, as that concern has
> come more into fashion recently.

Women are already almost 100% binary and they are better at
communicating than men some would say so they would have no
problem because of the English language to join the tech world
and if we take a look on reality this has been the case for as
long as I don't know.

As for minorities that have historically had a position of
disadvantage the more technology and the more English to them
the better!

PS. ha :) stop it...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

> but this isn't the 70s anymore where there were one "expert"
> on the same subject in every god damned country who had read
> a couple of 12 books on the subject and wrote a nice summary
> on in, resembling pretty much exactly what some other dude
> did in some other country reading his 12 books

Oh, I shouldn't have said that, or not in that way at least,
for the record, just because there was this tendency here and
there and that was possible because of the general situation
that doesn't mean everyone or even the majority were like
this, there were of course very good researchers and
scientists in the 70s, some who wrote great stuff in their
native languages and some who knew like 5 languages and wrote
in several languages as well.

Apologies if anyone took that the wrong way...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Thibaut Verron wrote:

>> They used to speak French, now they speak English.
>>
>
> I don't know what they used to speak, but nowadays they
> speak their own language afaik.

They used to speak French, that was the langauge of diplomacy,
now they speak English.

> We see the effect of this when all EU treaties are
> translated in all the official languages of the EU (which,
> luckily, still include English).

Well, they have resources to do that, and hire themselves and
each other to do the job for the right price. A lot is for
political reasons, also. But, obviously I don't know how
everything happens there, but of course the international
language is English there as well as everywhere else.

>> We see traces of this in for example the Euro Vision Song
>> Contest where they tell the score in English and French.
>
> Is that diplomacy now? :)

I think it is! It is a competition between nation and about
national pride. But it is also just a show, of course.
Commercial, monetary. Just like IIHF, too bad the French
didn't have a team this year (they play the B tournament, with
a bunch of Canadian guys, I think, so hopefully we see them
again soon).

FYI I've played ice hockey with Canadian guys from Quebec -
you know of course that they were separatists in the 70s - now
(well, this was 5-10 years ago) now these guys spoke English
in a way that was inseparable from any US or English-speaking
Canadian dude, no French accent, nothing. Reality, "man".

> Okay my bad. Might I still assume that I have met more
> French scientists and programmers than you? Most of them
> speak very broken English, and hate it.

Then it is a matter of attitude. Most Swedish people enjoy
speaking English a lot actually, and in the tech world it
makes sense as well, but even so most people get over it after
the initial love affair, of course we don't want to speak
English to countrymen we meet in the street or to our parents
(who speak good enough, sometimes excellent English, my mother
speaks good French as well BTW, and German, and Spanish, my
father's English is so-so, he speaks OK German tho, I speak
and write English fluently but not always correctly of course,
I can read French to some extent and I speak get-by Russian,
this may sound like a lot of languages everywhere but
I consider my skills at a pretty basic or low level, I didn't
score the top marks in school by any means, and if it hadn't
been for technology, education, student life, and talking like
this on Usenet/mailing lists and IRC, I don't think my English
had been on a so-so (or lower) level as well).

> I'm flattered that you take me as an example, but I speak
> and write English on a daily basis precisely because I don't
> live in France.

Yes, hah, you are allowed to speak French about technology in
France and everywhere else where you meet French-speaking
people, sweet heavens! It is just very impractical for you and
everyone else if you for example write source in French, and
you will put yourself at a huge disadvantage if you cannot
read books and source and web pages in English, and _we_ then
also cannot benefit from _you_ if you choose that path, as
I've said many times now. But you are not so no worries about
that, it is just this charade over and over, unbelievable!

> In France I was speaking 99.9% French, including at work.
> We would be writing a paper in English and discussing in
> French about which words to use.

The French students I met were 20-25 years old and they were
fluent speaking English, in a couple of years or a decade at
the most the French people will be as fluent as them, only at
15-20 instead, it is inevitable, French people are proud of
their engineering skills and everyone wants to take part of
the international world, including the French, you can pretend
to be annoyed by it all you want, as long as you still do it,
which is the case clearly, I'm fine... well, I am annoyed by
the whole charade, which the French are the only ones who do,
interestingly enough, but I know you are here anyway so it
doesn't matter really. And those who are not will come.

And a couple of generations more it will be all natural, no
one will even think about not doing it.

> And France is far from the worst place to speak English.
> Try a random Chinese or Japanese or Russian student.
> Try a random Turkish or Thai or Ivorian student.

No! Well, Thai or Ivorian students I never met but Chinese,
Japanese, Russian, and Turkish I all met, a lot, my dad even
has a house in Turkey, their technology students speak English
excellent, just fine, or are getting there, Russians in
particular are a weird bunch in this respect, ha, there are
some who refuse and some who are like Western Europe (i.e.,
very good), but it is inevitable, their education has always
been awesome and they are into everything Western, it is
inevitable that the "English-speakers" will win that battle,
and it doesn't have to take that long, these processes are all
under way sine long... (And actually it isn't a battle, the
Russians that "refuse" do that because they think they cannot,
they are in a "blocked mode", often they rely on a friend who
speaks excellent English but they themselves want to speak as
well and one forces them to speak they are happy about that
and learn very fast, if you think I'm generalizing now I am
but I've seen it so many times I know its true, ha.)

> And to be clear, it's not about the people. Some languages
> are extremely different from English (how hard is it to
> learn English from Swedish?). Some countries have extremely
> poor English teaching in lower education.

No, no, everyone is capable of learning English, some small
(or smallish) countries and language groups (e.g., Sweden, the
Netherlands, ...) has had a head start since it was so
apparently necessary for one reason, and there are other
reasons as well, but everyone else is equally and more than
capable and as we have seen with Russians and in particular
with the Germans who has had a rocket-career in this respect
it doesn't have to take that long, it will all come, so
whatever head start Sweden or other countries might have had -
well, good for us :) we were always clever merchants and
warriors at the same time :)) - but the point is that head
start for us won't mean anything sooner than we would like,
actually :)

>> Wrong! They do, and they do even more and better for each
>> year, and the very small group who don't, well, they have
>> a HUGE problem that should be fixed by them putting ALL
>> their efforts learning English as soon as possible
>
> Not realistic. Instead, they think that their English is
> good enough and will improve as they go.

Those who don't learn English will be at a disadvantage in
every aspect. People don't want that, it doesn't benefit them
or their games and it isn't fun, girls want to talk to foreign
guys and guys want to play games and watch stupid movies and
so on and so forth etc etc etc - I mean, why on Earth would
one not do that in general? And in particular a tech or
science person? I don't understand, why? The Swedish world is
small but the French world isn't big enough by far, sorry.
Deal with it...

> But learning a difficult topic will always be easier in your
> own language.

No, not with technology once you have made that step, then it
is more difficult, well, more _impractical_ I should say, to
speak about it, and in particular _write_ about it, in your
own language, actually. English is already the international
language and the language of technology and science, if you
want to be an international warrior you need this gun in your
belt as well, use only the French guns - you are gunned down,
sorry.

> Yes. But to those who know some English but for whom it
> requires effort, it would mean that they get a first contact
> with new difficult topics without language hurdles.
> They will still be able to access the complete documentation
> in English when needed.

They must and they will take the step, I'm positive, I'm 100%
convinced. Go to a party with 20 year old, as a field trip.
Go to the cutest, most intelligent girl and the guy who is
most skilled with tools and the guy who is most skilled with
sport. They ALL SPEAK ENGLISH and see no problem with it.
This decides everything already at this point!

Translating huge books is just an immense wasted effort that
also have several negative effects that I've mentioned
already. For example this book

@book{introduction-to-algorithms,
  author     = {Cormen and Leiserson and Rivest and Stein},
  edition    = {2nd edition},
  isbn       = {0-268-53196-8},
  publisher  = {MIT Press},
  title      = {Introduction to Algorithms},
  year       = {2001}
}

It is 1184 pages!

And that format (book heft) isn't uncommon!

Are you going to translate this to French because some French
guys aren't good enough English readers? This reasoning is
insane, I don't know how you get it to work in your heads,
that are rational in every other sense, including this one,
but only for your personal life and activities? Are your
compatriots that stupid? And you some kind of elite or
something? And you are gonna translate 1084 page books on
algorithms to remedy that? Ha, listen, it doesn't make any
sense any of it! Hahaha :)

>> and in the worst case they would be deluding themselves
>> thinking they are so great, while actually living in
>> a bubble 10 000 miles behind everyone else!
>
> With this kind of attitude, some of them just might.
> Talk about delusions...

But it is true, remove English from the world of technology
you can never keep up and you are restricted to work in the
fields were other people have translated stuff. French people
had I think with feudalism, right? That's what's gonna happen?
Haha :)

Native French output in terms of computers and programming and
(technology and science in general) cannot in any sense or in
any way be compared to the corresponding output in English.
Restrict yourself to French, that's the stupidest move in
anyone's personal or professional career, you just have to
deal with that reality, that doesn't work anymore -if it ever
did that world is long GONE. Gone but not forgotten, it would
seem! Hah. But know you will come and be here just as everyone
else, this recurring charade notwithstanding...

> Books get translated. Wikipedia is translated. Is it all
> negative to you?

Yes, if the explicit or implicit reason is that people are bad
at English! Of course there can be commercial, personal,
emotional etc reasons to do whatever but in terms of
technology restricting oneself to one's native language (well,
unless that's English, d'oh) that would be a huge blunder, no
one should do it and certainly not live under the illusion
that translations can make one not have to come HERE, where
the game is! You think French hockey players should only play
in the French league? NO, they should come to use here to
Sweden and Finland, where the level is ... another :)
Meanwhile WE should aim for the NHL and KHL, ha :) If enough
of them come, after their careers peak, they will not be good
enough for Sweden and Finland so they'll go back to France,
where they will bring the level up with their skills and
experience, and before you know it the French league can be
competitive with perhaps Germany, Litva, Belarus, Kazakhstan
... well, if you send A LOT of players anyway! But you will
never ever be at the level of Sweden or Finland and never ever
in a million years will the French hockey league be competitive
with NHL and the Russian Super League. So the only way you can
compete with the NHL and KHL is _in_ the NHL or KHL, and these
guys show it is indeed possible: (3 French guys in the NHL)
<https://www.quanthockey.com/nhl/nationality/active-french-nhl-players-career-stats.html>

There are 50 Swedish guys in the NHL BTW:
<https://www.quanthockey.com/nhl/nationality/active-french-nhl-players-career-stats.html>

and 50 Finnish guys:
<https://www.quanthockey.com/nhl/nationality/active-finnish-nhl-players-career-stats.html>

> Heck, *you* wrote a book in Swedish!

Please, you or anyone else get me a contract in NYC (which is
the publishing capital of the world BTW, tho the biggest
publishing house is English, Penguin, right? I think Hachette
Livre is number 2 but they also have their HQ in NYC) - you or
anyone else offer me a contract and instead of ranting here
I'd be more than happy to translate it to English or write
another book in English for that matter :) How about a book on
a tree house project?
<https://dataswamp.org/~incal/blog/index.html>
Or Elisp robotics?
<https://dataswamp.org/~incal/#terror>

>>> And all over the world, a lot of students who do not feel
>>> confident with English treat the lack of available
>>> translations as a significant hurdle, or even a barrier.
>>
>> 100% incorrect
>
> You really have no idea

I know so many people have take the step and those who don't
will be at a disadvantage, I don't think they like that so
they too will take the step, it makes sense and we see it
everywhere every day, why on Earth would it NOT happen? It is
already happening all over the world! Even here, I can go to
one of the student house quarters right now and there will be
people from all over the world - we have 42 559 students here
<https://en.wikipedia.org/wiki/Uppsala_University> - all of
them will speak excellent English, and if we ask about their
parent some will say their parents speak good English, some
so-so, and some not at all, but guess what, these people are
soon parents _themselves_, people use more and more technology
and consume more and more culture, watch movies, read
magazines, watch DIY YouTube videos how to demolish their
carbon bicycles, while trying to raise the saddle and learning
something in the process - it is inevitable. RESISTANCE IS
FUTILE!

> It's not really the same thing. Nobody asks *you* to write
> or read a manual in French or Chinese.

OF COURSE everyone is allowed to do it, I'm not going to do
anything more that write these messages, actually I'm getting
a little tired of it by now, I think I'll bookmark these 3-4
rantings the next time the French connection get their way up
to Annapurna (the first 8000+ mountain to be summited BTW, by
a French expedition, everyone gives them credit for this -
except the Swiss. why? because of langauge? can't have
a brother succeed? but Swiss mountaineering expertise is
beyond question - Mt. Everest OTOH was first summited by the
English but none of the two people reaching the top was from
England, ha, typical of them :) maybe the most difficult
mountain in the world, K2, was first summited by the Italians.
of the Polar explorers we have respect for the English
super-human efforts but there is no doubt in our minds the
best in this respect were the Norwegians.)

> But yes, I guess French diplomats make it a point to remind
> everyone that English domination should not be taken for
> granted. You can call it tradition. :)

Yep, Frenchh hangup (Frenchh = French and only French)

> But when I say that translated manuals are helpful, it's not
> part of that tradition, it's from my experience meeting and
> teaching to French students. Many of them simply do not
> bother or are blocked from learning a topic because there is
> no entry-level material in their language. That's a fact.

Manuals - maybe in the 70-80s but I'm not sure, now - harmful.

Textbooks - sure, if you have the manpower and resources and
political and individual desire to do that instead of
something more interesting, ha, but remember that
English-language university undergraduate textbooks are often
~1000 pages. They call everything before or below PhD
"Introduction" which is fun because again the books are
often >1000 pages. So if you want to translate the "intros" by
all means, do it.

And before you say it, what about the French production, which
is in French already? That is a competitive bout but not
close, and certainly not a draw. If you try to compete in that
sense you will loose. The only way for you to compete is to do
it in English like everyone else. You already do it, now you
have to 1) deal with it; and 2) do it even more, and the
French honor will be restored, despite the IT and computing
setback to the accursed Anglo-Americans...

-- 
underground experts united
https://dataswamp.org/~incal

Emacs i18n

[Christopher Dimech]

> Sent: Wednesday, July 21, 2021 at 8:43 PM
> From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> Thibaut Verron wrote:
>
> >> They used to speak French, now they speak English.
> >>
> >
> > I don't know what they used to speak, but nowadays they
> > speak their own language afaik.
>
> They used to speak French, that was the langauge of diplomacy,
> now they speak English.
>
> > We see the effect of this when all EU treaties are
> > translated in all the official languages of the EU (which,
> > luckily, still include English).
>
> Well, they have resources to do that, and hire themselves and
> each other to do the job for the right price. A lot is for
> political reasons, also. But, obviously I don't know how
> everything happens there, but of course the international
> language is English there as well as everywhere else.
>
> >> We see traces of this in for example the Euro Vision Song
> >> Contest where they tell the score in English and French.
> >
> > Is that diplomacy now? :)
>
> I think it is! It is a competition between nation and about
> national pride.

All this focus on identification with a nation must go away.
Particularly in a today's market economy (capitalism is long gone).

After the collapse of the berlin wall, many thought about freedom,
but all we got since then has been more borders and isolation.
A dystopian reality rather than an opportunity for exploration
and seeking.

> But it is also just a show, of course.
> Commercial, monetary. Just like IIHF, too bad the French
> didn't have a team this year (they play the B tournament, with
> a bunch of Canadian guys, I think, so hopefully we see them
> again soon).
>
> FYI I've played ice hockey with Canadian guys from Quebec -
> you know of course that they were separatists in the 70s - now
> (well, this was 5-10 years ago) now these guys spoke English
> in a way that was inseparable from any US or English-speaking
> Canadian dude, no French accent, nothing. Reality, "man".
>
> > Okay my bad. Might I still assume that I have met more
> > French scientists and programmers than you? Most of them
> > speak very broken English, and hate it.
>
> Then it is a matter of attitude. Most Swedish people enjoy
> speaking English a lot actually, and in the tech world it
> makes sense as well, but even so most people get over it after
> the initial love affair, of course we don't want to speak
> English to countrymen we meet in the street or to our parents
> (who speak good enough, sometimes excellent English, my mother
> speaks good French as well BTW, and German, and Spanish, my
> father's English is so-so, he speaks OK German tho, I speak
> and write English fluently but not always correctly of course,
> I can read French to some extent and I speak get-by Russian,
> this may sound like a lot of languages everywhere but
> I consider my skills at a pretty basic or low level, I didn't
> score the top marks in school by any means, and if it hadn't
> been for technology, education, student life, and talking like
> this on Usenet/mailing lists and IRC, I don't think my English
> had been on a so-so (or lower) level as well).

I also speak many languages.

> > I'm flattered that you take me as an example, but I speak
> > and write English on a daily basis precisely because I don't
> > live in France.
>
> Yes, hah, you are allowed to speak French about technology in
> France and everywhere else where you meet French-speaking
> people, sweet heavens! It is just very impractical for you and
> everyone else if you for example write source in French, and
> you will put yourself at a huge disadvantage if you cannot
> read books and source and web pages in English, and _we_ then
> also cannot benefit from _you_ if you choose that path, as
> I've said many times now. But you are not so no worries about
> that, it is just this charade over and over, unbelievable!

The biggest problem today is people identifying with this and that.

> > In France I was speaking 99.9% French, including at work.
> > We would be writing a paper in English and discussing in
> > French about which words to use.

I did part of my education in France.  And was respected for my capabilities.
Same happened in England, Spain, Russia.  When I wanted to get a piece of meat
I spoke spanish in spain.

> The French students I met were 20-25 years old and they were
> fluent speaking English, in a couple of years or a decade at
> the most the French people will be as fluent as them, only at
> 15-20 instead, it is inevitable, French people are proud of
> their engineering skills and everyone wants to take part of
> the international world, including the French, you can pretend
> to be annoyed by it all you want, as long as you still do it,
> which is the case clearly, I'm fine... well, I am annoyed by
> the whole charade, which the French are the only ones who do,
> interestingly enough, but I know you are here anyway so it
> doesn't matter really. And those who are not will come.
>
> And a couple of generations more it will be all natural, no
> one will even think about not doing it.
>
> > And France is far from the worst place to speak English.
> > Try a random Chinese or Japanese or Russian student.
> > Try a random Turkish or Thai or Ivorian student.
>
> No! Well, Thai or Ivorian students I never met but Chinese,
> Japanese, Russian, and Turkish I all met, a lot, my dad even
> has a house in Turkey, their technology students speak English
> excellent, just fine, or are getting there, Russians in
> particular are a weird bunch in this respect, ha, there are
> some who refuse and some who are like Western Europe (i.e.,
> very good), but it is inevitable, their education has always
> been awesome and they are into everything Western, it is
> inevitable that the "English-speakers" will win that battle,
> and it doesn't have to take that long, these processes are all
> under way sine long... (And actually it isn't a battle, the
> Russians that "refuse" do that because they think they cannot,
> they are in a "blocked mode", often they rely on a friend who
> speaks excellent English but they themselves want to speak as
> well and one forces them to speak they are happy about that
> and learn very fast, if you think I'm generalizing now I am
> but I've seen it so many times I know its true, ha.)
>
> > And to be clear, it's not about the people. Some languages
> > are extremely different from English (how hard is it to
> > learn English from Swedish?). Some countries have extremely
> > poor English teaching in lower education.
>
> No, no, everyone is capable of learning English, some small
> (or smallish) countries and language groups (e.g., Sweden, the
> Netherlands, ...) has had a head start since it was so
> apparently necessary for one reason, and there are other
> reasons as well, but everyone else is equally and more than
> capable and as we have seen with Russians and in particular
> with the Germans who has had a rocket-career in this respect
> it doesn't have to take that long, it will all come, so
> whatever head start Sweden or other countries might have had -
> well, good for us :) we were always clever merchants and
> warriors at the same time :)) - but the point is that head
> start for us won't mean anything sooner than we would like,
> actually :)
>
> >> Wrong! They do, and they do even more and better for each
> >> year, and the very small group who don't, well, they have
> >> a HUGE problem that should be fixed by them putting ALL
> >> their efforts learning English as soon as possible
> >
> > Not realistic. Instead, they think that their English is
> > good enough and will improve as they go.
>
> Those who don't learn English will be at a disadvantage in
> every aspect. People don't want that, it doesn't benefit them
> or their games and it isn't fun, girls want to talk to foreign
> guys and guys want to play games and watch stupid movies and
> so on and so forth etc etc etc - I mean, why on Earth would
> one not do that in general? And in particular a tech or
> science person? I don't understand, why? The Swedish world is
> small but the French world isn't big enough by far, sorry.
> Deal with it...
>
> > But learning a difficult topic will always be easier in your
> > own language.

Should there not be enough people in france to do translations in french
if need be.  Which means they see value in what  non-french people write.
People can argue how much they want, but one cannot force other to read
your stuff if they don't want to.


> No, not with technology once you have made that step, then it
> is more difficult, well, more _impractical_ I should say, to
> speak about it, and in particular _write_ about it, in your
> own language, actually. English is already the international
> language and the language of technology and science, if you
> want to be an international warrior you need this gun in your
> belt as well, use only the French guns - you are gunned down,
> sorry.
>
> > Yes. But to those who know some English but for whom it
> > requires effort, it would mean that they get a first contact
> > with new difficult topics without language hurdles.
> > They will still be able to access the complete documentation
> > in English when needed.
>
> They must and they will take the step, I'm positive, I'm 100%
> convinced. Go to a party with 20 year old, as a field trip.
> Go to the cutest, most intelligent girl and the guy who is
> most skilled with tools and the guy who is most skilled with
> sport. They ALL SPEAK ENGLISH and see no problem with it.
> This decides everything already at this point!

Local languages were useful at a time where people stayed and
functioned within their community.  It worked as a support
system.  If something terrible happened in your life, you could
go back to your clan and they would accept you and help you.

> Translating huge books is just an immense wasted effort that
> also have several negative effects that I've mentioned
> already. For example this book
>
> @book{introduction-to-algorithms,
>   author     = {Cormen and Leiserson and Rivest and Stein},
>   edition    = {2nd edition},
>   isbn       = {0-268-53196-8},
>   publisher  = {MIT Press},
>   title      = {Introduction to Algorithms},
>   year       = {2001}
> }
>
> It is 1184 pages!
>
> And that format (book heft) isn't uncommon!

Perhaps one day artificial intelligence could do it.  That would
make great possibilities.

I have read articles in french, spanish, portugese.  If those writings
are valuable to you, you will put the effort to learn or get a translation.

You can learn one or two languages pretty well to write, but beyond that,
becomes too much work and people usually have a quite limited life-span
if you have big aspirations.

> Are you going to translate this to French because some French
> guys aren't good enough English readers? This reasoning is
> insane, I don't know how you get it to work in your heads,
> that are rational in every other sense, including this one,
> but only for your personal life and activities? Are your
> compatriots that stupid? And you some kind of elite or
> something? And you are gonna translate 1084 page books on
> algorithms to remedy that? Ha, listen, it doesn't make any
> sense any of it! Hahaha :)

There is a group of mathematicians, called the Bourbaki Group, originally intended
to make a textbook in analysis.  Eventually became a group french mathematical
purists that became too rigid in their approach.  Applied mathematicians consider
the approach too restrictive in solving current problems of computation.

> >> and in the worst case they would be deluding themselves
> >> thinking they are so great, while actually living in
> >> a bubble 10 000 miles behind everyone else!
> >
> > With this kind of attitude, some of them just might.
> > Talk about delusions...
>
> But it is true, remove English from the world of technology
> you can never keep up and you are restricted to work in the
> fields were other people have translated stuff. French people
> had I think with feudalism, right? That's what's gonna happen?
> Haha :)
>
> Native French output in terms of computers and programming and
> (technology and science in general) cannot in any sense or in
> any way be compared to the corresponding output in English.
> Restrict yourself to French, that's the stupidest move in
> anyone's personal or professional career, you just have to
> deal with that reality, that doesn't work anymore -if it ever
> did that world is long GONE. Gone but not forgotten, it would
> seem! Hah. But know you will come and be here just as everyone
> else, this recurring charade notwithstanding...
>
> > Books get translated. Wikipedia is translated. Is it all
> > negative to you?
>
> Yes, if the explicit or implicit reason is that people are bad
> at English! Of course there can be commercial, personal,
> emotional etc reasons to do whatever but in terms of
> technology restricting oneself to one's native language (well,
> unless that's English, d'oh) that would be a huge blunder, no
> one should do it and certainly not live under the illusion
> that translations can make one not have to come HERE, where
> the game is! You think French hockey players should only play
> in the French league? NO, they should come to use here to
> Sweden and Finland, where the level is ... another :)
> Meanwhile WE should aim for the NHL and KHL, ha :) If enough
> of them come, after their careers peak, they will not be good
> enough for Sweden and Finland so they'll go back to France,
> where they will bring the level up with their skills and
> experience, and before you know it the French league can be
> competitive with perhaps Germany, Litva, Belarus, Kazakhstan
> ... well, if you send A LOT of players anyway! But you will
> never ever be at the level of Sweden or Finland and never ever
> in a million years will the French hockey league be competitive
> with NHL and the Russian Super League. So the only way you can
> compete with the NHL and KHL is _in_ the NHL or KHL, and these
> guys show it is indeed possible: (3 French guys in the NHL)
> <https://www.quanthockey.com/nhl/nationality/active-french-nhl-players-career-stats.html>
>
> There are 50 Swedish guys in the NHL BTW:
> <https://www.quanthockey.com/nhl/nationality/active-french-nhl-players-career-stats.html>
>
> and 50 Finnish guys:
> <https://www.quanthockey.com/nhl/nationality/active-finnish-nhl-players-career-stats.html>
>
> > Heck, *you* wrote a book in Swedish!
>
> Please, you or anyone else get me a contract in NYC (which is
> the publishing capital of the world BTW, tho the biggest
> publishing house is English, Penguin, right? I think Hachette
> Livre is number 2 but they also have their HQ in NYC) - you or
> anyone else offer me a contract and instead of ranting here
> I'd be more than happy to translate it to English or write
> another book in English for that matter :) How about a book on
> a tree house project?
> <https://dataswamp.org/~incal/blog/index.html>
> Or Elisp robotics?
> <https://dataswamp.org/~incal/#terror>
>
> >>> And all over the world, a lot of students who do not feel
> >>> confident with English treat the lack of available
> >>> translations as a significant hurdle, or even a barrier.
> >>
> >> 100% incorrect
> >
> > You really have no idea
>
> I know so many people have take the step and those who don't
> will be at a disadvantage, I don't think they like that so
> they too will take the step, it makes sense and we see it
> everywhere every day, why on Earth would it NOT happen? It is
> already happening all over the world! Even here, I can go to
> one of the student house quarters right now and there will be
> people from all over the world - we have 42 559 students here
> <https://en.wikipedia.org/wiki/Uppsala_University> - all of
> them will speak excellent English, and if we ask about their
> parent some will say their parents speak good English, some
> so-so, and some not at all, but guess what, these people are
> soon parents _themselves_, people use more and more technology
> and consume more and more culture, watch movies, read
> magazines, watch DIY YouTube videos how to demolish their
> carbon bicycles, while trying to raise the saddle and learning
> something in the process - it is inevitable. RESISTANCE IS
> FUTILE!
>
> > It's not really the same thing. Nobody asks *you* to write
> > or read a manual in French or Chinese.
>
> OF COURSE everyone is allowed to do it, I'm not going to do
> anything more that write these messages, actually I'm getting
> a little tired of it by now, I think I'll bookmark these 3-4
> rantings the next time the French connection get their way up
> to Annapurna (the first 8000+ mountain to be summited BTW, by
> a French expedition, everyone gives them credit for this -
> except the Swiss. why? because of langauge? can't have
> a brother succeed? but Swiss mountaineering expertise is
> beyond question - Mt. Everest OTOH was first summited by the
> English but none of the two people reaching the top was from
> England, ha, typical of them :) maybe the most difficult
> mountain in the world, K2, was first summited by the Italians.
> of the Polar explorers we have respect for the English
> super-human efforts but there is no doubt in our minds the
> best in this respect were the Norwegians.)
>
> > But yes, I guess French diplomats make it a point to remind
> > everyone that English domination should not be taken for
> > granted. You can call it tradition. :)
>
> Yep, Frenchh hangup (Frenchh = French and only French)
>
> > But when I say that translated manuals are helpful, it's not
> > part of that tradition, it's from my experience meeting and
> > teaching to French students. Many of them simply do not
> > bother or are blocked from learning a topic because there is
> > no entry-level material in their language. That's a fact.
>
> Manuals - maybe in the 70-80s but I'm not sure, now - harmful.
>
> Textbooks - sure, if you have the manpower and resources and
> political and individual desire to do that instead of
> something more interesting, ha, but remember that
> English-language university undergraduate textbooks are often
> ~1000 pages. They call everything before or below PhD
> "Introduction" which is fun because again the books are
> often >1000 pages. So if you want to translate the "intros" by
> all means, do it.
>
> And before you say it, what about the French production, which
> is in French already? That is a competitive bout but not
> close, and certainly not a draw. If you try to compete in that
> sense you will loose. The only way for you to compete is to do
> it in English like everyone else. You already do it, now you
> have to 1) deal with it; and 2) do it even more, and the
> French honor will be restored, despite the IT and computing
> setback to the accursed Anglo-Americans...

Perelman could have written in russian, but who would have read
them ! The most important people working in the field were american
or british.  And we all think highly of Grisha.

> --
> underground experts united
> https://dataswamp.org/~incal
>
>
>

Re: Emacs i18n

[tomas]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On Wed, Jul 21, 2021 at 12:04:59PM +0200, Christopher Dimech wrote:
> > Sent: Wednesday, July 21, 2021 at 8:43 PM
> > From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>

[...]

> > > Is that diplomacy now? :)
> >
> > I think it is! It is a competition between nation and about
> > national pride.

Hey, folks -- could you be so nice to take that to emacs-tangents?
That's what it is for, after all.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Emacs i18n

[Alexandre Garreau]

Emanuel, you talk a lot about competition and restriction, I’m skimming 
anything about nationalism (that’s getting wayyyy too irrelevant):

you say “why would people put themselves at disadvantage” while not 
everyone lives with unique main purpose to be “the best”, and not doing an 
effort to be above some level is not “purposedly putting oneself at 
disadvantage”.

you say restricting oneself to a non-english language is stupid hence 
translating from english is stupid, but as we already said, many people 
*already speak english* and yet prefer to read in their native language, 
and yet a book in english might be a barrieer.  A ~1000 pages book might 
be considered difficult to begin with, if it’s in the native language it 
will be deemed a lot easier.  Same for manuals, references, etc.

On the other hand, speaking and reading are two very different activity, 
with different phrasing, and different difficulty.  You could easily speak 
english if that’s the only solution available, you could easily write in 
it, that’s still easy, since it comes from your brain… but reading in it 
is going to require more cognitive load than reading in one’s native 
language.

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Alexandre Garreau wrote:

> you say “why would people put themselves at disadvantage”
> while not everyone lives with unique main purpose to be “the
> best”, and not doing an effort to be above some level is not
> “purposedly putting oneself at disadvantage”.

Ah, "the best", you don't have to aim for that to be
benefited, but if you aim for at least one of the better
versions of yourself, that's honorable! When I was healthy
physically and mentally, I aimed for the say top 5% best
version of myself, now I have both been forced and learned to
take life less seriously, so say I now aim for a top 20%
version of myself or something like that, It is just a digit;
but yes, let me say this, if we are talking young people and
young adults in an education and/or technology setting, most
definitely they should do as I and aim for the top 5% of
themselves or even higher if that's their inclination,
absolutely, and if they find people to compete with in
a healthy and balanced way - I mean, it doesn't matter what
I say, this is already what happens everywhere anyway - GO FOR
IT, and most definitely their ambitions should include
mastering English good enough for all practical purposes and
situations they will encounter in their careers as
practitioners, craftsmen, athletes, family members, all of it,
human beings! People are certainly not perfect and that
includes me but I did at least some good things, that said I'm
confident the generations younger than me will beat me without
any super-human effort from their part :)

> you say restricting oneself to a non-english language is
> stupid hence translating from english is stupid, but as we
> already said, many people *already speak english* and yet
> prefer to read in their native language, and yet a book in
> english might be a barrieer. A ~1000 pages book might be
> considered difficult to begin with, if it’s in the native
> language it will be deemed a lot easier. Same for manuals,
> references, etc.

But how long will it take to translate it? How much money and
how many man hours, how much skill? Why waste it on something
that will help a very small group of people, and then only
marginally (it's debatable, if they are benefited even, as
said)? All this to offer something that is already there in
its original, intended form and will take what, 1-2 years to
translate, typeset, print, ship? Something that the proposed
audience could just grab without delay and with nothing "lost
in translation", literally, if they would just master English?
Which they should do anyway if they have any ambitions in
a field where English is so dominant, actually even more so
than everywhere else, where English happens to also be
completely dominant? Does this make any sense to you?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-07-21 11:57]:
> Well, they have resources to do that, and hire themselves and
> each other to do the job for the right price. A lot is for
> political reasons, also. But, obviously I don't know how
> everything happens there, but of course the international
> language is English there as well as everywhere else.

What means international? Is it for all countries or just few
countries?

Maybe interpretation is too narrow.

https://en.wikipedia.org/wiki/List_of_languages_by_total_number_of_speakers

Order the table by the number of first language speakers.

Look at the number one language spoken in the world, which is which?
Chinese. 1.12 billion speakers! It is definitely international
language by definition.

Spanish is second language by first language speakers. It is
international.

Then comes English, Hindi, Portuguese.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> What means international? Is it for all countries or just
> few countries?

OK, clarification of terminology, there is one HUGE and
totally dominating Computer World *language*, which is
English. There are a couple of miniature - not worlds - but
national fragments, note that these fragment's sizes are
absolutely not proportional to the sizes of their language
groups in general on the planet Earth, so while English is big
internationally in general among other big and small groups,
in the computer world in particular English outclasses
everyone else completely, even if we would put all the
fragments together, i.e. "English vs. The Rest of the World",
that's a no contest in terms of technology in general and
computers in particular, it _is_ English. Deal with it...

You can verify this yourself, the LKML (Linux Kernel Mailing
List) often has 10 000+ messages in _a single week_. (Linux,
written by a Finish guy who speaks Finnish and Swedish and
English and now lives in the US, who did it as a CS student
with the help a bunch of convenient tools from the GNU project
which happens to be American, doing the all-American Unix
again, with a graphic system from MIT...

OK, that said, let the number talk: 10 000 posts/1 week

So let's examine the "alternative world" theory, which I know
is false but whatever... let's go nuts, please you guys
present the corresponding Linux kernel development mailing
lists in whatever native language anyone feels like pushing
for, and how many posts they have every week in average and
what is their influence on Linux compared to LKML one might
wonder wonder?

Now I sound mean, maybe disrespectful, but actual this
doesn't mean - and it isn't like that! - that the
US/English/etc takes the whole cred for Linux, just because
they - AND EVERYONE ELSE - use their language, on the contrary
the French, German, Russian guys etc are ALSO on the LKML and
that is BTW numerically speaking part of the reason (a good
reason, don't change that whatever you do) why the non-English
computer fragments are so small. You think the US guys can
muster 10 000 in a week all by themselves? No.

Even in the 90s, if you remember IRC or USENET back then, the
national and language-specific dimension was 1000 times more
present (OK, that number I just made up), now it is all
English, English, English... Please deal it.

PS. Programming languages in different languages BTW is many
    times more crazy than translation of books, which at least
    has the form of a rational activity and in many eras and
    circumstances and field were or mighty well could have
    been, just here and now isn't, or arguably isn't anyway;
    programming languages in different languages (the same
    language? A Swedish Lisp, anyone? sw-lisp? SL? OK, let's
    go here

    ööö ... vaf ?

    (låt-associeringslista
      (punkt-symbolnotation ... ?)
      (om tillstånd (emellertid ...

    ?????

Have you lost it? :)

Hahaha :) (I laugh at the mere thought which is just bizarre.)

--

underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Alexandre Garreau]

Le mercredi 21 juillet 2021, 15:01:54 CEST Jean Louis a écrit :
> * Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-
emacs@gnu.org> [2021-07-21 11:57]:
> > Well, they have resources to do that, and hire themselves and
> > each other to do the job for the right price. A lot is for
> > political reasons, also. But, obviously I don't know how
> > everything happens there, but of course the international
> > language is English there as well as everywhere else.
> 
> What means international? Is it for all countries or just few
> countries?

several countries

the main point of what he says is not “international” but “the”.  maybe he 
mostly tries to say “vehicular”.

> Maybe interpretation is too narrow.
> 
> https://en.wikipedia.org/wiki/List_of_languages_by_total_number_of_speak
> ers
> 
> Order the table by the number of first language speakers.
> 
> Look at the number one language spoken in the world, which is which?
> Chinese. 1.12 billion speakers! It is definitely international
> language by definition.

“international” does not mean “big” but “among several nations” or 
“outside of only one nation”.  You may consider chinese international if 
you consider mandarin, cantonese, etc. to be different nations.

> Spanish is second language by first language speakers. It is
> international.
> 
> Then comes English, Hindi, Portuguese.

Re: Emacs i18n

[Yuri Khan]

On Wed, 21 Jul 2021 at 15:55, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> Translating huge books is just an immense wasted effort that
> also have several negative effects that I've mentioned
> already. For example this book
>
> @book{introduction-to-algorithms,
>   author     = {Cormen and Leiserson and Rivest and Stein},
>   edition    = {2nd edition},
>   isbn       = {0-268-53196-8},
>   publisher  = {MIT Press},
>   title      = {Introduction to Algorithms},
>   year       = {2001}
> }
>
> It is 1184 pages!
>
> And that format (book heft) isn't uncommon!
>
> Are you going to translate this to French because some French
> guys aren't good enough English readers?

[This one?][1] It has been translated into Russian and it is being
sold at ~73 USD. Which is a lot for a book, and still it seems there
is demand for it.

(As for me, if I personally wanted to own a copy of that book, I could
probably buy it in English on Amazon for cheaper. I’ve seen enough
books whose translations were inaccurate, inelegant or any combination
of the above.)

[1]: https://www.ozon.ru/product/algoritmy-postroenie-i-analiz-33769775/

Re: Emacs i18n

[Alexandre Garreau]

Le jeudi 22 juillet 2021, 19:32:49 CEST Yuri Khan a écrit :
> On Wed, 21 Jul 2021 at 15:55, Emanuel Berg via Users list for the GNU
> 
> Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> > Translating huge books is just an immense wasted effort that
> > also have several negative effects that I've mentioned
> > already. For example this book
> > 
> > @book{introduction-to-algorithms,
> > 
> >   author     = {Cormen and Leiserson and Rivest and Stein},
> >   edition    = {2nd edition},
> >   isbn       = {0-268-53196-8},
> >   publisher  = {MIT Press},
> >   title      = {Introduction to Algorithms},
> >   year       = {2001}
> > 
> > }
> > 
> > It is 1184 pages!
> > 
> > And that format (book heft) isn't uncommon!
> > 
> > Are you going to translate this to French because some French
> > guys aren't good enough English readers?
> 
> [This one?][1] It has been translated into Russian and it is being
> sold at ~73 USD. Which is a lot for a book, and still it seems there
> is demand for it.
> 
> (As for me, if I personally wanted to own a copy of that book, I could
> probably buy it in English on Amazon for cheaper. I’ve seen enough
> books whose translations were inaccurate, inelegant or any combination
> of the above.)

Same for me, I regularely noticed that.  Yet I own french translations of 
some important books, such as this one (and I got it from another user of 
emacs, btw, met on emacs french irc channel), and first edition sicp (which 
was translated in my university).

But as nothing is perfect, absolute and rarely objective, there can be 
stuff you can sometimes like in old editions, for instance the first edition 
of sicp contains some additional exercises (some of which are unsolvable, 
yet amusing to try to solve), and I dislike the “object.notation” of third 
ed. of cormen, which does not appear in french edition which is from 
second ed.

More generally, if books used a tailor-made translation infrastructure, 
such as GNUnation, or anything allowing to translate only changed/added 
paragraphs, and only portion of them, that would make translation of new 
editions much easier… but I’m pretty sure it’s not done because (1) 
copyright unhelps, (2) it’s obviously already profitable anyway, even being 
horribly expensive, (3) the interest in it and profitability, especially in 
smaller audiance, may be a lot more chaotic and variable, so it may not 
remain always as interesting to translate.

But more generally a few errors and (correctable!) unaccuracies are worth 
the increased easiness reading.

Anyway *that* is the core, DH0 [0] point of it.  And you may attack it 
pretty efficiently (but maybe you don’t want that but just hope everybody 
feels like you more generally dismissing everything else) on its *own* 
playground (the political field) in this way: having a wide and rich enough 
linguistic sphere for benefiting from it is a privilege, that currently 
mostly benefit the most powerful imperialist nations (france, russia, 
china, japan, hispanophone and lusophone countries, arabic countries), 
dismissing most of other languages

So it would not even be efficient (*at all*) at protecting languages from 
extinction (beside that side effect that english would spread less fast and 
extinguish them more slowly).

A counter-argument, which, contrarily to the uneasiness of reading a 
foreign language, may by chance not be scientifically studied upon, is that 
it’s still easier to learn a similar language, from the same family, 
rather than just english.  Except Japan which is an isolate, and Iberic 
ones which are totally unrelated to american languages (well except 
vocabulary nowadays…), there are many arabic (maybe semitic in general), 
chinese, slavic, and latin languages out there… yet some very important 
families are missing from that imperialist game, such as austronesian, and 
many african, american, indian (and asian in general) ones.

Actually, if I wanted to approach from adressing your core, DH0 [0] point, 
of shared culture, I may say that centralization (except maybe in some 
“utopia” where all languages are extinguished) is not the most efficient way 
of doing it… just as broadcasting everything, in a horizontal, 
decentralized and most importantly *indirect* network such as the internet 
(or more generally human relations), is less efficient as *multicasting* in 
a tree-shaped way: translating most important stuff to main languages of 
most important linguistic families, that would then be learned by most 
people may be easier, as for the fact that most of the human population 
still is *ignorant* (it’s not necessarily elitism, it’s just a fact, not a 
researched goal or an immutable truth) about science and technology, we 
could maybe in this way approach more the goal of making them *aware* of 
what’s important in it.

Most important knowledge is not the one that change most often.  Classical 
mechanics are still used, and it’s good that books on it are translated in 
most of languages (in it could be in *all* languages that’d be great).  

I’m *sure* translating Knuth would be wonderful, once he’s dead (I hope he 
authorizes it, but under american copyright law maybe he’s not even 
allowed to free his own work after publishing so well…).

[0] http://www.paulgraham.com/disagree.html

Re: Emacs i18n

[Alexandre Garreau]

Le mercredi 21 juillet 2021, 08:11:36 CEST Emanuel Berg via Users list for 
the GNU Emacs text editor a écrit :
> Alexandre Garreau wrote:
> >> Anglo-American beat French to world dominance, accept it.
> > 
> > Nobody told in this thread French had any world dominance.
> > Although you may note that the concern about english is
> > often raised by french people
> 
> They are the ONLY people who EVER brings this up.

ok so what? that a french says something does not make it automatically 
wrong.  and if you already contradicted other frenches in the same way 
well we are not all connected through a shared mind so you cannot expect 
us to learn that once for all.

> > and maybe for some sort of inconscious nationalism or
> > rempent national aversion toward english due to that
> > previous context, the concern stays valid, and you cannot
> > cancel an argument validity due to the people who raise it.
> 
> We WANT the French-speaking people, and they are here already
> as we clearly see, but this isn't the 70s anymore where there
> were one "expert" on the same subject in every god damned
> country who had read a couple of 12 books on the subject and
> wrote a nice summary on in, resembling pretty much exactly
> what some other dude did in some other country reading his 12
> books! The langauge of science and technology IS English, it
> if had been French I would have written the same thing, only
> in defense of French - but it _isn't_ French, and everyone
> understands that - even the French, as we clearly see - but
> unlike everyone else, the French pretends or do not accept
> this in some places of their minds, so they bring this up over
> and over, #$&%@!

indeed, so nobody is arguing about that, so why bring it on?

> >> There is no miniature world of computers where everyone
> >> speaks French or any other language who badly needs
> >> translations, drop it.
> > 
> > There is
> 
> THERE IS NOT, and whatever fraction there is is getting
> smaller by the day, it isn't a place were you yourself would
> like to be restricted to, so why ever would you like that for
> your compatriots that are, BTW, fully capable of learning
> English just like everyone else?

some people don’t, sometimes by inability (yet I can concede that ability 
is usually very connected with the needed abilities to be competent in CS… 
yet there is (unfortunately?) a strong pressure to put more people inside 
CS than the quantity of people that may be competent in it), sometimes 
hindered by some psychological issue (btw that same kind of issues is what 
drives many people away from CS, especially womyns… yet these are 
unrelated).

> In fact, the French language
> is much closer to English than a lot of other languages, there
> is no disadvantage at all in any sense or in anyway, and we
> see this every day when we speak English to people from the
> French-speaking world!

our languages are equally unspokable with unneededly complex phonology, 
unlike most languages on the earth, also

> > not only in france, but any non-germanic place I have been
> > through. English, just like french, is a difficult language
> 
> No, because of popular culture, technology, and proximity of
> languages it is very easy for anyone these days to learn
> English, if the have any ambitions whatsoever with science and
> technology they already know English before they even enter
> the university?

I guess according that viewpoint of yours many people entering university 
just do without “ambitions”, so we should bar that from them.

english may be, because of its dominance, a lot facilitated, but in 
comparison with many languages it is difficult, mostly because of its 
phonology and imprecision.  but french is equally bad about that.  if it 
had been mandarin or russian I’d find it better (but if you start talking 
about tones or number of verb forms and how that would make that 
impossible, you would get the point the same issue arise with english 
making it somehow impossible for some people).

> > with lot of vocabulary. You’re living is a small-world
> > utopia that’s nowhere near even realistic.
> 
> We live in the same world of science and technology where the
> language is English, maybe it made sense in the 70-80s to
> translate the man pages or whatever (the French were the only
> ones who got close BTW, that said French programmers today are
> typically _not_ using that old, incomplete, un-updated stuff
> were you have to wonder -

I swear they do

> even if it was perfect, which it is
> not and cannot be, so no disrespect to the translators

you are doing the very opposite from respect telling their work is 
negative :') but well everybody should be allowed to tell a whole 
discipline is useless or even negative, who knows that may be right (I 
usually think that way about english teachers (I mean, people speaking 
english for real never do that because of teachers, that’s so much money 
wasted)).

> - even it
> if was perfect they'd still have to wonder about what
> everything is, what is interface,

interface

> hash algorithm, 

algorithme de hachage

> API,

the english term is just used (but pronounced in french), but it seems to 
be used only in modern context or by younger people, in other cases 
“interface” (or the translation of library, by metonymy)

> proxy,

used as is

> client-server,

those words are from french

> raster,

used as is

> shading langauge,

same

> checksum,

often same, otherwise “somme de contrôle” when you want to sound formal

> compression with the
> use
> of tagged chunks, Alice and Bob in French? why aren't the
> English-language software options congruent with ... wait,
> what terms are we using, even? The French or the English?
> (Oh, I know Alice and Bob - Abelard et Héloïse, n'est-ce pas?)

Alice is commonly used in France, but not Bob (yet it is known), so we use 
them as well when explaining cryptography (same for Eve (though most 
frenchs aren’t aware about the pun with “evesdropping”), etc.), the last 
two french names sound from the past century.

I mean most languages, especially with technology, just do that: copy 
words.  That’s precisely why 75% of english vocabulary comes from french, 
whose a great part comes straight from latin, whose a great part comes 
straight from greek, whose some part comes from egyptian (or other semitic 
language at some other point of time)…

I mean, when two people in a country speaking the same language need to 
talk about their discipline, do you really believe they use english? 
orally? that would be extremely painful, even if both often are fluent, and 
write most of their stuff in english, and publish only in english.

the fact technology globalize (and it always have) doesn’t makes languages 
disappear

capitalism added to imperialism and nationalism eventually makes languages 
disappear, but france has purposedly made disappear enough languages so 
for it to be obvious.

> > Even those who *fluently* speak english are commonly *tired*
> > with it.
> 
> No, that is true only in the initial, beginner phase,

I’m speak english fluently since a decade, you pretend I speak it well, and 
yet it makes me tired, for real.

some languages are less tiring than others, spanish and russian are kinda 
okay, but english is really tiring because I *all the time* try to 
pronounce stuff correctly, which is of course impossible, and a huge 
distraction, and I could just try to make up some weird pseudo-italian 
accent that would look russian and I would be less distracted but it 
sounds weird enough that I quickly resume back to trying to fake original 
english accent and here we go…

I’m not the only one, I mean you are trying to counterargument very very 
very obvious stuff and wasting most of your credit to any english-non-
native reader u.u

> then on
> the contrary one gets tired of reading it in a language that
> is _foreign_ to it,

to what?

> the _native_ language is always the best
> and the native language in the science and technology world is
> English, US English in particular.

native in this context does not mean anything. in linguistics, sociology, 
demography, history, etc. native has a very specific meaning, and you are 
trying to borrow a weird meaning, most likely from a metaphor inside CS, 
except it is conflicting with some other science so it’s not understandable 
anymore

> > Even I, and actually anybody because that’s natural, would
> > choose to read something in their native(s) language(s)
> > rather than a foreign one
> 
> English isn't foreign here, it is the native language of
> the field.

and yet I can’t be sure you’re right or trolling me about the meaning of 
foreign…

understand “non-native to said person” if you prefer… my point still 
holds.

> > Just to be sure, you’re a native speaker of english right?
> 
> Hahaha :) Are you kidding, I'm Swedish!

well at least that’s still a germanic language u.u and english is a lot 
more common in your countries than in latin ones (and in these it is still 
more than anywhere else)

> That said, these
> rantings are to be put on my account solely, I'm sure many of
> my countrymen who reads this thinks I'm insane or something...
> ha :)

well it is reassuring that you’re aware of the level of the point you’re 
trying to make, at least I won’t generalize anything and keep in mind that 
it’s only you saying that, because otherwise it would have been very 
desperating u.u (I mean for instance lately I’ve had a “chance” to speak 
to a lot more extreme-right-wing ppl, and I wouldn’t wanted another such 
novelty…)

> > or have you tried to work in mandarin
> 
> This instant, in another buffer I have a friend on IRC from
> ROC

wait what’s roc?

> and he speaks better English than me (he thinks that at
> least :)) and I was a CS student when Sweden offered courses
> free of charge (now they do that only to EU contrives) so every
> course, taught in English, was like 50% people from China!
> I lived in a student house for 7 years with a configuration of
> Chinese people ALWAYS present at one time or the other,
> EVERYONE spoke English, all the books were in English, exams
> were in English, the Chinese guys were sometimes a weird bunch
> to deal with on an everyday basis but the problem was _never_
> their or mine or anyone else's (certainly not the French who
> were also there, but in much smaller numbers) NO ONE had any
> problem whatsoever with the English, trust me!

you realize you (a) did not answer about mandarin, (b) that this cannot be 
representative in any way, because china already holds more than a eigth 
of current humankind right?

> > on the ground that its syntax is said to be simple and
> > flexionless, to say it’s as easy as in your native language?
> 
> I'm not saying I or anyone else is as good with English as we
> are with our own languages,

it sometimes really looked like it.  I guess you must admit some “small 
areas of exception”, but not acknowledging the tire of speaking a 
different-from-native language really looks like it…

> except for when speaking of one
> thing - technology. The language is of course not perfect, how
> could it ever be, but it is "good enough for government work",
> good enough for the intended purpose. (I don't think my
> English as in English in general is that good actually, maybe
> my ROC friend is right.)
> 
> > otherwise, do you have studies showing the opposite?
> 
> We don't need studies, we have something stronger, reality.

oh ok it’s a joke, haha ^^

> > There are everywhere teachings of CS in english *as
> > a special matter*, that’s a way to *train* for english
> > because that training is *needed* because it is nonnatural,
> > and it is a difficulty and people try lowering it by
> > confronting to it... yet most of courses are in the national
> > language, not english.
> 
> Not here. But that's OK, I'm not saying all universities that
> teach technology must necessarily do everything in English
> this very instant.

can’t wait all germanic languages extinguish into english so at least that 
kind of argument won’t be held anymore.  maybe one or two generations 
would be sufficient…

> But that's were we are heading anyway.
> In the 70s everyone wrote their PhDs in their own languages.

I bet ukrainians unfortunately didn’t do that in ukrainian…

> Now people even write their BSc in English. There will only be
> more and more of this and that's a good thing. Those who don't
> will be at a disadvantage.

even doing it, not having english as a native language puts you at a 
disadvantage.  just look at the native language of most current 
billionaires…

actually the best thing would be “just get born into an english-speaking 
country”, tbh. but this has been said a lot of times.

> Those who do not know _any_ English
> will be at such a disadvantage they won't be able to
> contribute or acquire information in a way that make them even
> belong, sorry.

belong to what?

I’m sure there are people in korea and china doing very relevant work in 
technology, that is only afterwards translated into english.

> > Some vocabulary obviously comes from english, and
> > englishisms are present more often than not, but the
> > grammar, phonology, orthography, syntax, and most of
> > vocabulary we use stay our national (or even sometimes, with
> > luck (that means not in france) the local one) language.
> 
> Yes, of course, but it isn't about that, it is about English
> as a tool to communicate about technology, it isn't about the
> beauty of the language,

I didn’t bring that on in this paragraph

> I'm sure some of the things I write
> would make a Grammar School teacher blush, but that's OK, it
> is at this point unavoidable and perhaps that will always be
> like that, even, but even now and long before I write this
> people have collaborated on zillion projects speaking English -
> and French and Russian also, and Swedish even - only these
> languages didn't make it to the #1 position that English has,
> right here and right now - so instead of translating, if you
> want to help "your" people (not necessary IMO, but OK) what
> you should do is became English _teachers_,

this is a despiceable job.  you learn a language by using it, not by 
studying it.  writing interesting material in the said language is more 
productive than teaching it.  also language teaching is extremely bad in 
this country, and nobody exactly understands why (but possibly because of 
french and how french people relate to it (that may explain why many 
french people bring that on))
 
> > emacs is only for programmers and CS-ists
> 
> Yes, but it is much, much broader than that, you don't have to
> be a programmer, it is enough to have a smartphone and
> smart-TV and god damn computer, this has already contributed
> A LOT to how people speak English, Germans at 20 for example
> speak much better English than I did, when I was 20 (and then
> I thought Germans couldn't speak English at all, maybe), so
> NO, it is not necessary for you to be an Emacs user or
> programmer, everyone that uses technology is benefited
> tremendously for knowing English and it works both ways,
> technology makes you better at English (ordinary English,
> between humans) as well, because English is not the langauge
> of just nations like the US, England <3, Australia <3 and so
> on

the term you are searching for is “US + commonwealth”.

> it is also the language of TECHNOLOGY, so make people
> COME, don't work on things that will make them NOT COME @%&#$!

actually I don’t care, to me anything of value will be translated in the 
needed language (be it english) eventually, and the disadvantages is small 
and not worth the effort.

I would think differently if languages weren’t disappearing at a faster 
pace than we are registering them (and understanding them, as linguistics 
as a human science is still incomplete and unable to fully restore 
languages features), and/or if the dominant language was less horrible 
than english or french (russian, esperanto, quechua, or korean would be 
enough), so that’s partly esthetics indeed, *here*

But that’s happening anyway! and translation is a hard and difficult and 
tiresome work, so… your discourse is pretty useless I think… given the 
direction in which we are heading, I think you would be a lot more 
productive and useful if you spent all that time arguing about how we can 
totally get rid of biodiversity with that being a great thing.

> > That would be the kind of "user-friendliness", btw, that may
> > have an effective impact on making more women or minorities
> > join CS, and moreover less occidental, as that concern has
> > come more into fashion recently.
> 
> Women are already almost 100% binary

wdym?

> and they are better at
> communicating than men some would say so they would have no
> problem because of the English language to join the tech world

that reasoning is unconvincing

> As for minorities that have historically had a position of
> disadvantage the more technology and the more English to them
> the better!

this looks like “let’s get the rich richers and the poorer people will 
naturally get some more money so the inequality problem will be solved”, 
this reasoning is broken.

> PS. ha :) stop it...

that could count both ways…

PS: that trolling is becoming amusing, the caricature you are building 
could be a very efficient strawman, I’m thinking about conserving and 
pointing at that discussion later (but carefully, I don’t want to tarnish 
emacs’ reputation)

Re: Emacs i18n

[Thibaut Verron]

> > > or have you tried to work in mandarin
> >
> > This instant, in another buffer I have a friend on IRC from
> > ROC
>
> wait what’s roc?

Either Republic of Congo or Republic of China (Taiwan), based on
context I'd say Taiwan. But afaik English is much more commonly taught
and spoken in Taiwan than in PRC.

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Thibaut Verron wrote:

>>>> or have you tried to work in mandarin
>>>
>>> This instant, in another buffer I have a friend on IRC
>>> from ROC
>>
>> wait what’s roc?
>
> Either Republic of Congo or Republic of China (Taiwan),
> based on context I'd say Taiwan. But afaik English is much
> more commonly taught and spoken in Taiwan than in PRC.

I guess it depends who you ask if Taiwan is China or not :)

-- 
underground experts united
https://dataswamp.org/~incal

Emacs i18n

[Christopher Dimech]

> Sent: Wednesday, July 21, 2021 at 9:59 PM
> From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> Thibaut Verron wrote:
> 
> >>>> or have you tried to work in mandarin
> >>>
> >>> This instant, in another buffer I have a friend on IRC
> >>> from ROC
> >>
> >> wait what’s roc?
> >
> > Either Republic of Congo or Republic of China (Taiwan),
> > based on context I'd say Taiwan. But afaik English is much
> > more commonly taught and spoken in Taiwan than in PRC.
> 
> I guess it depends who you ask if Taiwan is China or not :)

People in Taiwan are chinese who rejected the intrusion of the chinese 
communist party, which trampled chinese culture with brutal communist
ideology.

Taiwan is mostly a rugged mountain landscape, not the well behaved alluvial
plains you get in China.  May China become more like Taiwan.
 
> -- 
> underground experts united
> https://dataswamp.org/~incal
> 
> 
>

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Christopher Dimech wrote:

> People in Taiwan are chinese who rejected the intrusion of
> the chinese communist party, which trampled chinese culture
> with brutal communist ideology.

Well, yeah, it was an extremely bloody revolution and
decade-long civil war that laid waste to the country, the
loosing Nationalist side escaped to Taiwan because they lost,
since then the mainland China Communist regime has been
claiming they want Taiwan back but actually they are happy
that ROC brings money and expertise to the Chinese people that
actually benefits them as well, indirectly and thru various
mazes, but in time yes and they know it; and they are also
happy to have a remote enemy (which is protected by the US) so
they can drum up nationalism and spend money on their
so-called People's Liberation Army (well, "once" perhaps is
the word, again depending on who you ask). This army actually
beat the US at least to some extent in the Korean War (mainly
because of a huge advantage in numbers, which is nothing to be
ashamed of BTW, on the contrary it is an excellent way of
winning wars that almost _never_ fails) - well, anyway they
partly beat the US and _in the 50s_ at that, that was as you
know the US time in world history if ever there was one, and
you don't do that without popular support - anyway now the
Communist ideology and society have left many traces thruout
Chinese society but that's it, on the whole it's just another
form of capitalism or market economy competition between
people and companies and various groups within the ruling
burocratic superstructure (well, they have a tradition of that
so maybe its their way, heck do I know, remember that in
Imperial China the elite DIDN'T rule as one may think, instead
ruling was done by a super-educated bureaucracy), it isn't
like anywhere else exactly, their own brand of it, but still.
Taiwan was once the workshop of the world, then that position
went on to China and Taiwan moved on to the most advanced
stuff, like instead of doing combination wrenches (spanners)
they did torque wrenches, and of course inevitably China will
travel the same path and they already do all kinds of advanced
consumer goods (e.g., my supposedly/actually (?) Japanese
power tools from Ryobi [pronounced "ióbi"] and Hitachi
["stási"] and Casio ["cásio"] wrist watch, all that made in
the RRC since forever, almost), and they are also innovative,
not on the "old Asia", Europe, or US level per capita but in
absolute numbers they are more than competitive, the only area
where China isn't a superpower is actually, surprisingly, the
military one, where they are out-scooped by both the US and
Russia - contrast this to Russia who is a superpower in one
and only one sense - the awesome and enormous might of its
military establishment: the army (undisputed #1 in the world),
the navy, the air force - including not the least the defense
industry, basically the only Russian smash hit (no pun
intended) on the international market save for natural
resources that is good by all means but it makes them
a regional power perhaps, certainly not a superpower from that
alone, and to be honest their skills on the individual, human
level - yeah, it is a poor state, they shouldn't stay at that
level with all the human talent they have in such a huge
country...

So step one for Russia and China to step up their game

                       *drumroll*

                        *fanfare*

you guessed it, inprove their English skills, in particular
among the educated or to-be educated youth and young adults.

-- 
underground experts united
https://dataswamp.org/~incal

Emacs i18n

[Christopher Dimech]

> Sent: Wednesday, July 21, 2021 at 11:49 PM
> From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> Christopher Dimech wrote:
> 
> > People in Taiwan are chinese who rejected the intrusion of
> > the chinese communist party, which trampled chinese culture
> > with brutal communist ideology.
> 
> Well, yeah, it was an extremely bloody revolution and
> decade-long civil war that laid waste to the country, the
> loosing Nationalist side escaped to Taiwan because they lost,

They have not lost, they are keeping chinese culture and traditions alive.

> since then the mainland China Communist regime has been
> claiming they want Taiwan back but actually they are happy
> that ROC brings money and expertise to the Chinese people that
> actually benefits them as well, indirectly and thru various
> mazes, but in time yes and they know it; and they are also
> happy to have a remote enemy (which is protected by the US) so
> they can drum up nationalism and spend money on their
> so-called People's Liberation Army (well, "once" perhaps is
> the word, again depending on who you ask). This army actually
> beat the US at least to some extent in the Korean War (mainly
> because of a huge advantage in numbers, which is nothing to be
> ashamed of BTW, on the contrary it is an excellent way of
> winning wars that almost _never_ fails) - well, anyway they
> partly beat the US and _in the 50s_ at that, that was as you
> know the US time in world history if ever there was one, and
> you don't do that without popular support - anyway now the
> Communist ideology and society have left many traces thruout
> Chinese society but that's it, on the whole it's just another
> form of capitalism or market economy competition between
> people and companies and various groups within the ruling
> burocratic superstructure (well, they have a tradition of that
> so maybe its their way, heck do I know, remember that in
> Imperial China the elite DIDN'T rule as one may think, instead
> ruling was done by a super-educated bureaucracy), it isn't
> like anywhere else exactly, their own brand of it, but still.
> Taiwan was once the workshop of the world, then that position
> went on to China and Taiwan moved on to the most advanced
> stuff, like instead of doing combination wrenches (spanners)
> they did torque wrenches, and of course inevitably China will
> travel the same path and they already do all kinds of advanced
> consumer goods (e.g., my supposedly/actually (?) Japanese
> power tools from Ryobi [pronounced "ióbi"] and Hitachi
> ["stási"] and Casio ["cásio"] wrist watch, all that made in
> the RRC since forever, almost), and they are also innovative,
> not on the "old Asia", Europe, or US level per capita but in
> absolute numbers they are more than competitive, the only area
> where China isn't a superpower is actually, surprisingly, the
> military one, where they are out-scooped by both the US and
> Russia - contrast this to Russia who is a superpower in one
> and only one sense - the awesome and enormous might of its
> military establishment: the army (undisputed #1 in the world),
> the navy, the air force - including not the least the defense
> industry, basically the only Russian smash hit (no pun
> intended) on the international market save for natural
> resources that is good by all means but it makes them
> a regional power perhaps, certainly not a superpower from that
> alone, and to be honest their skills on the individual, human
> level - yeah, it is a poor state, they shouldn't stay at that
> level with all the human talent they have in such a huge
> country...
> 
> So step one for Russia and China to step up their game
> 
>                        *drumroll*
> 
>                         *fanfare*
> 
> you guessed it, inprove their English skills, in particular
> among the educated or to-be educated youth and young adults.

Tho russian realised that long ago after they began publishing their books
about their tortured tales of human suffering in tho western world.
It made many people warm their heart and fall in love with Russian literature. 

Samizdat was their equivalent of the free software movement long before
its application by Stallman.

> -- 
> underground experts united
> https://dataswamp.org/~incal
> 
> 
>

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Christopher Dimech wrote:

> Tho russian realised that long ago after they began
> publishing their books about their tortured tales of human
> suffering in tho western world. It made many people warm
> their heart and fall in love with Russian literature.

But that's in the past, I don't think Russia is a superpower
in terms of literature and international publishing *today*.
With their very educated population there should be a big
_internal_ market that to some extent is near-international
(their diaspora or otherwise Russian readers in Ukraine,
Belarus, Latvia, Kazakhstan etc). But I think it is nothing,
virtually, compared to NYC where all the European publishing
powerhouses reside (and the US market for that matter), these
guys probably think they are kings or something ... well, some
of the books they publish are awesome, no doubt, so maybe they
earned it? *hesitant*

I've said like one decade now we should have an essay or
coffee table book on Emacs, called the "Emacs World", a super
polished product with screenshot and tables of all thinkable
data, that would be one way to get back at them, for sure!
But it could also be a unique, cool product. There are TONS of
money in the book business and that is reachable without
a huge effort (write one book page a day, you have a heft book
in one year). I happen to know from my biblio-intelligence
software biblio-int.el that there are public libraries all over
the world that have bookshelf after bookshelf with computer
books in English, most often without a single book on Emacs.
The last time I brought up the idea I got the response they
should get the Emacs manual! Ha :) Well, I agree, they should,
however clearly it doesn't work like this.

Here are a bunch of books that are good, except for one, which
is horrible, yeah, you guessed it, RMS's "semi-biography"
written by a "non-programmer" :D Well, I laugh because it is
sad. Assange's book is also poor, but not as bad. The rest are
OK or good, and in particular 'Generation 500' (Amiga),
'Generation 64' (C64), and the one first mentioned,
'A Quarter Century of UNIX' could be used as templates what we
could do with Emacs, easily.

Here are some book-related resources that might interest
someone, maybe:

https://dataswamp.org/~incal/#isbn
https://dataswamp.org/~incal/books/isbn.txt
https://dataswamp.org/~incal/emacs-init/isbn-verify.el
https://dataswamp.org/~incal/emacs-init/issn-verify.el
https://dataswamp.org/~incal/emacs-init/bibtex-incal.el
https://dataswamp.org/~incal/emacs-init/latex.el
https://dataswamp.org/~incal/books/books.bib
https://dataswamp.org/~incal/books/
https://dataswamp.org/~incal/emacs-init/ecat-incal.el

%%%% computer culture

@book{quarter-century-of-unix,
  author     = {Peter Salus},
  isbn       = 0201547775,
  publisher  = {Addison-Wesley},
  title      = {A Quarter Century of UNIX},
  year       = {1994}
}

@book{just-for-fun,
  author     = {Linus Torvalds},
  isbn       = 9780066620732,
  publisher  = {Harper},
  title      = {Just for Fun: The Story of an Accidental Revolutionary},
  year       = {2002 (2001)}
}

@book{generation-500,
  author     = {Jimmy Wilhelmsson},
  isbn       = {978-91-76293-70-6},
  publisher  = {Bokfabriken},
  title      = {Generation 500},
  year       = {2017}
}

@book{i-allmanhetens-tjanst-permanent-record,
  author     = {Edward Snowden},
  isbn       = {978-91-7343-975-6},
  publisher  = {Leopard},
  title      = {I allmänhetens tjänst (Permanent Record)},
  translator = {Stefan Lindgren},
  year       = {2019 (2019)}
}

@book{free-as-in-freedom,
  author     = {Richard Stallman and Sam Williams},
  isbn       = 0983159211,
  publisher  = {FSF},
  title      = {Free as in Freedom 2.0},
  year       = {2010}
}

@book{svenska-hackare,
  author     = {Daniel Goldberg och Linus Larsson},
  isbn       = {978-91-1-303964-0},
  publisher  = {Norstedts},
  title      = {Svenska hackare},
  year       = {2011}
}

@book{generation-64,
  author     = {Jimmy Wilhelmsson},
  isbn       = {91-630-9465-7},
  publisher  = {Bokfabriken},
  title      = {Generation 64},
  year       = {2014}
}

@book{copyright-finns-inte,
  author     = {Linus Walleij},
  isbn       = {91-630-9465-7},
  publisher  = {RootGear},
  title      = {Copyright finns inte},
  year       = {1999}
}

@book{memoarer-ar-prostitution,
  author     = {Julian Assange},
  isbn       = {978-91-1-303764-6},
  publisher  = {Norstedt},
  title      = {"Memoarer är prostitution": en omtvistad självbiografi},
  year       = {2011}
}

@book{programmers-at-work,
  author     = {Susan Lammers},
  isbn       = 1556152116,
  publisher  = {Tempus Books},
  title      = {Programmers at Work},
  year       = {1989}
}

@book{quarter-century-of-unix,
  author     = {Peter Salus},
  isbn       = 0201547775,
  publisher  = {Addison-Wesley},
  title      = {A Quarter Century of UNIX},
  year       = {1994}
}

%%%% Apple

@book{steve-jobs-en-biografi,
  author     = {Walter Isaacson},
  isbn       = {978-91-7429-285-5},
  publisher  = {Bonnier},
  title      = {Steve Jobs - en biografi (Steve Jobs)},
  year       = {2012 (2011)}
}

@book{iwoz,
  author     = {Steve Wozniak},
  isbn       = {0-393-06143-4},
  publisher  = {Norton \& Company},
  title      = {iWoz},
  year       = {2006}
}

Re: Russia, they are a superpower in terms of their military
strength, both as employed by them and because of their
defence industry, Rosoboronexport (Russian Arms Export,
maybe).

Another industry/area where they are absolutely top notch is
space! Even the US guys were mere passengers aboard their
Sojuz shuttles ever since cancelling their own space shuttle
programs. But maybe the US guys are returning to the field?
(or sphere I guess :))

That's it I'm afraid, weapons (both their own employment of
them and exporting them) and space, or am I wrong?
Natural resources are good but they don't really impress the
man on the street this day and age, sorry.

> Samizdat was their equivalent of the free software movement
> long before its application by Stallman.

I like the connection, didn't think of that, but even so the
past is the past. Past merits, while no one can take them away
from you, last 2 years, tops, typically...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-07-17 23:58]:
> Alexandre Garreau wrote:
> 
> > Translating emacs would require to translate many
> > identifiers, it would actually amount to translate
> > a programming language
> 
> I don't think anyone suggests doing that, I think what can be
> translated is *the interface*, so for example in the menu
> "Quit" or "Exit" or whatever it says (I'm not a menu user)
> _that_ would be translated. I don't think there are a lot of
> advantages doing this, and I do see some DISadvantages, so
> I think it shouldn't be done, actually, but the suggestion
> isn't "translate everything", that would be an insane, almost,
> rather than a bad suggestion.

Many things could be translated, it is about GNU Project to organize
translation efforts:

- TUTORIAL is translated in many languages, it could be done in more,
  this is first essential document to start with.

- Emacs Lisp Intro and Manual could be translated in other languages;
  let us say if it is translated into German language then this would
  be the jumping board or starting point to continue translation of
  other parts of Emacs;

- Menu system definitely could be translate, but maybe it is just like
  so much software uses gettext, I would not know. I would say not
  even to translate it if Emacs Lisp Intro and Manual are not yet
  ready in the same language.

- GNU MANIFESTO (I don't find it), GNU Project and other GNU website
  pages as linked from Emacs are I guess already translated in many
  languages. I did not test it but I doubt that Emacs is checking for
  locale settings and fetching the right translated page from website,
  it should. If user is on German language then Emacs should fetch
  German version from GNU Project website;


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Christ, I shouldn't have engaged in this discussion the way
I did, I was a bit out of my head that night, anyway this is
the same case as everycase else where everyone is just seeing
everything from their perspective and when one tilted reality
collide with another that is also tilted this is what happens.

No one has a monopoly on interpreting reality! So no one
should act like that either.

For example just looking at this pic from my birthday party
one might easily get the wrong idea:

  https://dataswamp.org/~incal/pimgs/pharty.png

-- 
underground experts united
https://dataswamp.org/~incal

Emacs i18n

[Christopher Dimech]

There was a difference in focus about the task.  I took a dimension that makes
a more powerful engine.  But one is a success if one is not a slave to another
person's idea.  So we're ok ;)

Felicitations
Christopher



> Sent: Friday, July 23, 2021 at 9:22 PM
> From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: Emacs i18n
>
> Christ, I shouldn't have engaged in this discussion the way
> I did, I was a bit out of my head that night, anyway this is
> the same case as everycase else where everyone is just seeing
> everything from their perspective and when one tilted reality
> collide with another that is also tilted this is what happens.
>
> No one has a monopoly on interpreting reality! So no one
> should act like that either.
>
> For example just looking at this pic from my birthday party
> one might easily get the wrong idea:
>
>   https://dataswamp.org/~incal/pimgs/pharty.png
>
> --
> underground experts united
> https://dataswamp.org/~incal
>
>
>

Re: Emacs i18n

[Jean-Christophe Helary]

> On Jul 18, 2021, at 5:00, Alexandre Garreau <galex-713@galex-713.eu> wrote:
> 
> Translating emacs would require to translate many identifiers, it would 
> actually amount to translate a programming language,


No. Eli mentioned that the commands indeed have a mnemonic function but localizing emacs can also start with the help and the UI strings *just like any other software*. The rest is a bonus.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs i18n

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean-Christophe Helary wrote:

> localizing emacs can also start with the help and the UI
> strings *just like any other software*. The rest is a bonus.

?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs i18n

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Date: Sat, 17 Jul 2021 22:00:51 +0200
> 
> Translating emacs would require to translate many identifiers, it would 
> actually amount to translate a programming language

I think this is too radical, even impractical.  There's no need to
translate the language and the identifiers, we need "only" find a way
of providing their equivalents in other languages where that matters.
For example, a *Help* buffer describing a variable could include a
line which interprets the important parts of the variable's name in
the target language.  Or something along those lines.

Re: Emacs i18n

[Alexandre Garreau]

Le samedi 17 juillet 2021, 11:53:24 CEST Eli Zaretskii a écrit :
> > From: Narendra Joshi <narendraj9@gmail.com>
> > Date: Sat, 17 Jul 2021 11:27:14 +0200
> > 
> > Are there translations for Emacs in other languages?
> 
> No, not at this time.  Translating the Emacs UI is a non-trivial
> project, as past discussions have indicated, for several good reasons.
> No one started to work on that seriously, AFAIK.

For new people and people like me who haven’t always seriously followed 
everything everytimes… when and what were these discussions?  Would you 
have (from memory, taking more of your time may be exagerated) some dates 
(year + trimester) or keywords (to search that would been used in topics).  
Were there many such discussions in the past? 1? 2? 3-4? more?

Re: Emacs i18n

[Jean-Christophe Helary]

> On Jul 18, 2021, at 5:06, Alexandre Garreau <galex-713@galex-713.eu> wrote:
> 
> Le samedi 17 juillet 2021, 11:53:24 CEST Eli Zaretskii a écrit :
>>> From: Narendra Joshi <narendraj9@gmail.com>
>>> Date: Sat, 17 Jul 2021 11:27:14 +0200
>>> 
>>> Are there translations for Emacs in other languages?
>> 
>> No, not at this time.  Translating the Emacs UI is a non-trivial
>> project, as past discussions have indicated, for several good reasons.
>> No one started to work on that seriously, AFAIK.
> 
> For new people and people like me who haven’t always seriously followed 
> everything everytimes… when and what were these discussions?  Would you 
> have (from memory, taking more of your time may be exagerated) some dates 
> (year + trimester) or keywords (to search that would been used in topics).  
> Were there many such discussions in the past? 1? 2? 3-4? more?

i18n, l10n on the dev list.


-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs i18n

[Eli Zaretskii]

> From: Alexandre Garreau <galex-713@galex-713.eu>
> Date: Sat, 17 Jul 2021 22:06:13 +0200
> 
> For new people and people like me who haven’t always seriously followed 
> everything everytimes… when and what were these discussions?

On emacs-devel.

> Would you have (from memory, taking more of your time may be
> exagerated) some dates (year + trimester) or keywords (to search
> that would been used in topics).

I don't usually remember search keywords; life is too short.  Try the
obvious ones: i18n, translation, gettext, message catalogs, ...

> Were there many such discussions in the past? 1? 2? 3-4? more?

Maybe two or three.

Re: Emacs i18n

[Bruno Haible]

Richard Stallman wrote in
<https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00328.html>:

> I can envision something like this:
>
>       "russian-nom:%d байт%| скопирован%|, %s, %s"
>
> where the 'russian-nom' operator would replace the two %| sequences
> with the appropriate declensional suffixes for the nominative case.

It is, of course, tempting to try to do morphological analysis in an
algorithmic way, based on our background as algorithm hackers. François
Pinard and others considered this, back in 1995 when they started i18n in GNU.

The reason this approach was not chosen is still valid today:

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.

And it has to cope with the assumed skills of these personas:

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

  - The translator, you can assume, can translate sentences and knows
    about the different meanings of words in different context. But they
    cannot write nor understand algorithms. Many translators, in fact,
    don't see the grammar as a set of rules.

You may find some people on the intersection, such as a Russian hacker,
but it is hard to find people with both skills for languages such as
Vietnamese, Slovenian, or Basque. So, you better design the system in
such a way that no person is assumed to have both skills.

The challenge is to define these formats 1) and 2) in a way that

  * Programmers can do their job with their skills (i.e. don't need to
    understand Russian).

  * Translators can do their job with their skills (i.e. don't need to
    understand algorithms).

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.

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.
Either the translator tool should somehow highlight these characters
and present on-line help, or it should present it as a sequence of
strings to translate:

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

It is important to realize that each such case of morphological variation
requires translator tooling support. And unfortunately different such tools
exist, and every translator has their preferred one. For the plural form
handling alone, it took several years until the main tools had support for
it in their UI.

Bruno

Re: Emacs i18n

[Paul Eggert]

On 3/20/19 4:59 AM, Bruno Haible wrote:
> 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.

Thanks for making the point better than I was able to.

There's another reason pluralization is a good place to stop. GNU
gettext attacks the problem of how to translate formats containing
printf conversion specifications like %d, in phrases like "%d items".
That is, gettext deals with the grammatical problem of number, because
printf formats numbers. However, there are no printf conversion
specifications for other grammatical aspects such as case, gender,
tense, voice, or mood, which means there is no significant need for
gettext to deal with these other aspects.

In hindsight it might have been better if gettext had not attacked the
problem of plurals. As you wrtite, even plurals are nearly a bridge too
far. But it's done now, so we might as well use it.

Re: Emacs i18n

[Juri Linkov]

> Richard Stallman wrote in
> <https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00328.html>:
>
>> I can envision something like this:
>>
>>       "russian-nom:%d байт%| скопирован%|, %s, %s"
>>
>> where the 'russian-nom' operator would replace the two %| sequences
>> with the appropriate declensional suffixes for the nominative case.
>
> It is, of course, tempting to try to do morphological analysis in an
> algorithmic way, based on our background as algorithm hackers. François
> Pinard and others considered this, back in 1995 when they started i18n in GNU.
>
> The reason this approach was not chosen is still valid today:
>
> 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.
>
> And it has to cope with the assumed skills of these personas:
>
>   - The programmer, you can assume, can write and understand algorithms,
>     but does not master the grammar of more than one language (usually).
>
>   - The translator, you can assume, can translate sentences and knows
>     about the different meanings of words in different context. But they
>     cannot write nor understand algorithms. Many translators, in fact,
>     don't see the grammar as a set of rules.
>
> You may find some people on the intersection, such as a Russian hacker,
> but it is hard to find people with both skills for languages such as
> Vietnamese, Slovenian, or Basque. So, you better design the system in
> such a way that no person is assumed to have both skills.
>
> The challenge is to define these formats 1) and 2) in a way that
>
>   * Programmers can do their job with their skills (i.e. don't need to
>     understand Russian).
>
>   * Translators can do their job with their skills (i.e. don't need to
>     understand algorithms).
>
> 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.
>
> 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.
> Either the translator tool should somehow highlight these characters
> and present on-line help, or it should present it as a sequence of
> strings to translate:
>
>   Rule: russian-nom
>   "%d байт"
>   " скопирован"
>   ", %s, %s"
>
> It is important to realize that each such case of morphological variation
> requires translator tooling support. And unfortunately different such tools
> exist, and every translator has their preferred one. For the plural form
> handling alone, it took several years until the main tools had support for
> it in their UI.

Indeed, a complete implementation of all Russian morphological rules
takes ~1600 lines of dense Perl code:

http://www.linkov.net/files/nlp/Lingua-RU-Inflect.pm

I can't imagine how to include all these rules to gettext.

But there is no need because gettext already strikes a decent balance
between complexity of natural languages and practical needs of
program internationalization where translators themselves decide
how words in messages should be inflected for different plural forms.

Currently we have more urgent tasks after the first step of adding
‘ngettext’ like in CLISP, the development stalled on the problem of
splitting messages into domains.

But maybe CLISP already provides a good way to map packages to gettext
domains?  Does it require every package to have a separate domain or
it collects translations from all packages into one domain?

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. ]]]

  > Indeed, a complete implementation of all Russian morphological rules
  > takes ~1600 lines of dense Perl code:

  > http://www.linkov.net/files/nlp/Lingua-RU-Inflect.pm

  > I can't imagine how to include all these rules to gettext.

I agree with you about that.  What I propose is something else.

1. I do not propose implementing them all.  Only some -- whichever ones
we think are worth while.

2. I do not propose putting any of this in gettext.
What I propose would be Emacs code that operates on the strings that
come from gettext.

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

Re: Emacs i18n

[Juri Linkov]

>   > Indeed, a complete implementation of all Russian morphological rules
>   > takes ~1600 lines of dense Perl code:
>
>   > http://www.linkov.net/files/nlp/Lingua-RU-Inflect.pm
>
>   > I can't imagine how to include all these rules to gettext.
>
> I agree with you about that.  What I propose is something else.
>
> 1. I do not propose implementing them all.  Only some -- whichever ones
> we think are worth while.
>
> 2. I do not propose putting any of this in gettext.
> What I propose would be Emacs code that operates on the strings that
> come from gettext.

The misconception of your proposal is assuming a pure algorithmic
inflection whereas actually inflection in Russian is dictionary-based
(in addition to algorithms that process words from the dictionary),
i.e. to be able to inflect a word you need a large dictionary of all
words where each word in the dictionary has at least the following
lexical properties:
- part of speech
- noun grammatical gender: masculine, feminine, neuter
- noun animacy: animate, inanimate
- inflection type

And the main parameters that influence the declension are:
- grammatical case (one of 6 basic: nominative, genitive, dative,
  accusative, instrumental, prepositional plus some additional)
- number: singular and plural.  Dual is not a grammatical number,
  it only influences the choice of cases for words after numerals:
  for 1    - nominative case, singular
  for 2..4 - genitive case, singular
  for 5..  - genitive case, plural

An additional problem is that there are many exceptions:
some words have an additional form called "count form"
https://en.wikipedia.org/wiki/Russian_declension#Count_form

For instance, an exception is to use "5 байт" (5 byte) instead of
what should be according to the grammatical rule that requires
genitive plural for most other words, but not for bytes,
i.e. this is incorrect: "5 байтов" (5 bytes).

Such exceptions are marked in the dictionary with a special
property that has different values:

- mandatory: only the count form is allowed for such units
  of measure as amperes, watts, volts, bits, bytes, etc.
- optional: both forms are accepted for such units as angstroms,
  gauss, (kilo)grams, decibels, carats, microns, ohms, röntgen, etc.

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. ]]]

  > The misconception of your proposal is assuming a pure algorithmic
  > inflection whereas actually inflection in Russian is dictionary-based
  > (in addition to algorithms that process words from the dictionary),

Maybe I did.  I see various meanings for "pure algorithmic", so I am
not sure whether I did, or did not, assume the point you have in mind.

  > i.e. to be able to inflect a word you need a large dictionary of all
  > words where each word in the dictionary has at least the following
  > lexical properties:
  > - part of speech
  > - noun grammatical gender: masculine, feminine, neuter
  > - noun animacy: animate, inanimate
  > - inflection type

It sounds like Russian has various declensions, like Latin.
Do I understand right?

If so, it is true that 'russian-nom' would require specification of
declensions.  Maybe `russian-masc' as well.

Are there standard names or codes for the declensions?  In Latin, each
declension has a number.  I think those numbers are standard in
teaching of Latin, so everyone who can read Latin knows those numbers,
and translators would find it natural to use a construct that
specifies the proper declension by number.

We would not have to implement all of them -- only those that
are useful enough to be worth implementing and documenting.
We would tell translators to handle the other declensions, and
the special exceptions, and the irregular plurals, using
lower-level constructs comparable to what gettext does now.

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

Re: Emacs i18n

[Yuri Khan]

> It sounds like Russian has various declensions, like Latin.
> Do I understand right?

Yes, Russian has several declension types for nouns, and several
conjugation types for verbs, and knowing the declension type helps one
deduce the ending for each grammatical case and number, most of the
time.

> Are there standard names or codes for the declensions?

At school, they teach us there are three declensions. First declension
for feminine nouns and a few masculine nouns ending in -а and -я;
second declension for masculine nouns ending in a consonant and neuter
nouns ending in -о or -е; and third declension for feminine nouns
ending in -ь.

This is not the complete picture. There are also non-declined nouns,
nouns that decline as if they were adjectives or pronouns, and
exceptions.

> In Latin, each
> declension has a number.  I think those numbers are standard in
> teaching of Latin, so everyone who can read Latin knows those numbers,
> and translators would find it natural to use a construct that
> specifies the proper declension by number.

The difference is that any translation to Latin would be done by a
linguist, while translation to Russian would be done by ordinary
Russian-speaking people. Most of whom do not keep the scientific
details of declensions in their heads any longer than necessary for
their current study and work.

> We would not have to implement all of them -- only those that
> are useful enough to be worth implementing and documenting.

Right, and pretty much the only part of grammar that is useful for
software UI localization is the grammatical number, because that is
the only thing that changes by circumstances outside the control of
the code. It just does not happen that the same message would put a
noun in different cases, or a verb in different tenses, depending on
the value of some expression.

Re: Emacs i18n

[Ineiev]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

On Sat, Mar 23, 2019 at 02:55:48PM +0700, Yuri Khan wrote:
> Right, and pretty much the only part of grammar that is useful for
> software UI localization is the grammatical number, because that is
> the only thing that changes by circumstances outside the control of
> the code. It just does not happen that the same message would put a
> noun in different cases, or a verb in different tenses, depending on
> the value of some expression.

I encountered constructs like "We use %s %s", where the first arg is
a color ("red", "green", "cool"), and the second arg is a fruit
("apple", "lemon", "horse radish") in singular, dual or plural.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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. ]]]

  > Right, and pretty much the only part of grammar that is useful for
  > software UI localization is the grammatical number, because that is
  > the only thing that changes by circumstances outside the control of
  > the code. It just does not happen that the same message would put a
  > noun in different cases, or a verb in different tenses, depending on
  > the value of some expression.

That's how I thought it would be.  That's why I proposed a construct
russian-nom that would decline a noun that's meant to be in the
nominative case.  There could be other such constructs for other cases,
those that are used often enough in messages to be worth the trouble,
and maybe different ones for adjectives, if that is worth the trouble.

If translators don't find these more convenient, they won't have to
use these.  I don't see any sense in ruling them out without giving
them a try.

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

Re: Emacs i18n

[Juri Linkov]

> Maybe I did.  I see various meanings for "pure algorithmic", so I am
> not sure whether I did, or did not, assume the point you have in mind.

Sorry, if I incorrectly interpreted your proposal, it was unclear to me
at what stage you planned to expand the special markup such as %|

Doing this at runtime means adding large dictionaries to the distribution 
(together with complex algorithms) to perform a dictionary lookup.
Or alternatively to use an external online API that inflects the words.

But what we could do better than that is to improve po-mode to help
translators to fill all plural forms in the existing format, but to do
this automatically using either a downloaded or online dictionary.

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. ]]]

  > Sorry, if I incorrectly interpreted your proposal, it was unclear to me
  > at what stage you planned to expand the special markup such as %|

At the stage of translating a message -- when the value of the number
is known.

  > Doing this at runtime means adding large dictionaries to the distribution 
  > (together with complex algorithms) to perform a dictionary lookup.

No dictionary is needed.  It would handle only regular plurals
(following known rules)..

  > Or alternatively to use an external online API that inflects the words.

No, it will be done directly in Lisp code.

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

Re: Emacs i18n

[Chusslove Illich]

[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]

>> [: Juri Linkov :]
>> Indeed, a complete implementation of all Russian morphological rules
>> takes ~1600 lines of dense Perl code:
>>
>> http://www.linkov.net/files/nlp/Lingua-RU-Inflect.pm
>>
>> I can't imagine how to include all these rules to gettext.
>
> [: Richard Stallman :]
> I agree with you about that. What I propose is something else.
>
> 1. I do not propose implementing them all. Only some -- whichever ones
> we think are worth while.
>
> 2. I do not propose putting any of this in gettext. What I propose
> would be Emacs code that operates on the strings that come from
> gettext.

I'd like to mention that a system of this kind, the Ki18n, is in
operation within the KDE ecosystem for more than a decade now. The
system is in fact invisible to programmers (for the most part), and it
is also invisible for translators, unless they know about it and want to
use it. At the last count, 10 language teams do make use of it.
Translators have at their disposal a generic scripting system, so that
any kind of algorithmic adaptation of translation is possible; and some
interesting uses have come up.

Programmer's perspective is given here:
http://api.kde.org/frameworks/ki18n/html/prg_guide.html . There is in
fact almost no mention of the system, which is as intended; only the
subsections "Dynamic Contexts" and "Placing and Installing Scripting
Modules" provide a clue that it exists.

Translator's perspective is given here:
http://techbase.kde.org/Localization/Concepts/Transcript . It includes
some real-life example at the end. The variety of basic functions
defined by translators can be seen in the system's source tarball
http://download.kde.org/stable/frameworks/5.56/ki18n-5.56.0.tar.xz in
po/*/scripts directories.

Regarding specifically plural handling, this is in normal use left to
Gettext standard functionality, since it was already there for a long
time. However, there are two cases where the system does get used for
plurals. One is the typical failure case where a programmer knows that
the substituted number will always be greater than and therefore thinks
a ngettext call is not needed; when this error is seen during a pre-
release message freeze, a scripted translation can be used to work
around until fix for next release. The other case is when a language
needs also plural handling for float-type arguments (e.g. gd in the
tarball above).

Each programming environment (programming language plus foundation
libraries) can implement its own version of a similar system, as
proposed here for Emacs. However, I think a unified Gettext solution
would be preferable. Based on the experience with Ki18n, some years ago
I made such a clean design for Gettext, but never got time to work on
it. It is described at http://nedohodnik.net/gettextbis/ . Section 6
describes the scripting system itself, with sections 2 and 3 detailing
the necessary support for it.

-- 
Chusslove Illich (Часлав Илић)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Emacs i18n

[Bruno Haible]

Hi Juri,

> Currently we have more urgent tasks after the first step of adding
> ‘ngettext’ like in CLISP, the development stalled on the problem of
> splitting messages into domains.

You are very welcome to ask for advice on bug-gettext. It's there that
you can find the experts. (I don't read emacs-devel usually.)

> But maybe CLISP already provides a good way to map packages to gettext
> domains?  Does it require every package to have a separate domain or
> it collects translations from all packages into one domain?

What matters for the domains is what code gets distributed together.

  * When you have two Lisp packages that are released by separate
    groups of developers, of course they must use separate translation
    domains. Otherwise you would have to co-ordinate the merging of their
    POT files, which makes no sense since they make releases at different
    times.

  * On the other hand, when you have two Lisp packages that are always
    released together, in the same tarball, it is more efficient for the
    translators if they receive one notification about a new POT file
    than two notifications about two POT files on the same day.

For Common Lisp code, the Common Lisp package name _may_ be used to
derive the domain name. But this is up to the developers.

For reference, i18n in CLISP is described here:
https://clisp.sourceforge.io/impnotes/i18n-mod.html
https://www.gnu.org/software/gettext/manual/html_node/Common-Lisp.html
and there is a sample and a test case in GNU gettext:
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/examples/hello-clisp/hello.lisp.in
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/tests/lang-clisp

Bruno

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)

Re: Emacs i18n

[Bruno Haible]

Richard Stallman wrote:
>     > - 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.

Still, it's essential to consider what the programmers send to the
translators, and what the translators send back in return.

> I don't speak Russian.

Since you speak French perfectly, and we have a French translator on this
list (Jean-Christophe Helary), let me make an example in French.

As far as I understand, for plural handling instead of asking the
translator to translate

  msgid "He bought one nice horse."
  msgid_plural "He bought %d nice horses."

you would send them just the string

  "He bought %d nice horses."

and expect that the translator sends back the string

  "Il acheta %d beau%| cheval%|."

and then have, in the program, code that transforms this to

   "Il acheta un beau cheval."
or "Il acheta %d beaux chevaux."

I claim that

  1) It is not a win for the translator. It is just as easy for the translator
     to produce two strings, than a string with several markers. Speech is
     natural to translators, not markup and grammar.

     Additionally, how will the translator know whether they have done it
     correctly or made a mistake? If you don't want translators to return
     untested translations, there will be the need to integrate the algorithmic
     code into the translation tools (KBabel, Lokalize, Gtranslator, Poedit, etc.).
     How do you want to do that?
     
  2) It is hard to implement:

     - For the singular case, you need to know that "cheval" is masculine.
       Would you like the translator to provide this information, through
       markup such as
         "Il acheta %d<m> beau%| cheval%|."
       or would you like the code to look it up through a dictionary?

     - For the plural case, you need to know that the plural of "*eau" is
       "*eaux" in French (a rule that can be coded), but also that the
       plural of "cheval" is "chevaux" (or vice versa, that the singular
       of "chevaux" is "cheval") - which requires a dictionary lookup.

Bruno

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. ]]]

  > and expect that the translator sends back the string

  >   "Il acheta %d beau%| cheval%|."

You are right that modification of the stem creates a complication.
However, in French it would not be difficult to handle.
The processing could recognize when the stem before %| calls for modification
and modify the plural according to the rules.

I think it would not be hard to implement operators french-masc and
french-fem that would handle all regular plurals.

       > - For the plural case, you need to know that the plural of "*eau" is
       >   "*eaux" in French (a rule that can be coded), but also that the
       >   plural of "cheval" is "chevaux" (or vice versa, that the singular
       >   of "chevaux" is "cheval") - which requires a dictionary lookup.

Each of these words has a regular plural.  french-masc would convert
al%| into aux when plural is called for.

For irregular plurals, the translator would give both forms by hand,
working at the gettext level.

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

bug#34520: delete-matching-lines should report how many lines it deleted

[積丹尼 Dan Jacobson]

delete-matching-lines is an alias for ‘flush-lines’ in ‘replace.el’.

It works great... or does it? Can't often tell. That's because well,
if there are matching lines off the screen, you won't really know, so
you have to go down there to have a look... and well, need eagle eyes
often too depending on the pattern and how many similar lines there
still are.

Got an idea!: Simply keep a count of how many lines were deleted, and
report that in the minibuffer, if using interactively.

What if there were no matching lines?
Then say
Deleted 0 matching lines.
Or beep "No matching lines!"

Try this with matching lines all below the visible part of the buffer:
C-x h [mark-whole-buffer]
M-x delete-matching-lines zzzzz

See the feeling (felt nothing, did it work in the first place one wonders?)

bug#34520: delete-matching-lines should report how many lines it deleted

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

> Got an idea!: Simply keep a count of how many lines were deleted, and
> report that in the minibuffer, if using interactively.

Good idea, this will bring deleting the lines under control:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: flush-lines-count.patch --]
[-- Type: text/x-diff, Size: 1426 bytes --]

diff --git a/lisp/replace.el b/lisp/replace.el
index b482d76afc..c3d8278936 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -953,7 +953,10 @@ flush-lines
 
 If a match is split across lines, all the lines it lies in are deleted.
 They are deleted _before_ looking for the next match.  Hence, a match
-starting on the same line at which another match ended is ignored."
+starting on the same line at which another match ended is ignored.
+
+Return the number of deleted lines.  When called interactively,
+also print the number."
   (interactive
    (progn
      (barf-if-buffer-read-only)
@@ -968,7 +971,8 @@ flush-lines
       (setq rstart (point)
 	    rend (point-max-marker)))
     (goto-char rstart))
-  (let ((case-fold-search
+  (let ((count 0)
+        (case-fold-search
 	 (if (and case-fold-search search-upper-case)
 	     (isearch-no-upper-case-p regexp t)
 	   case-fold-search)))
@@ -978,9 +982,13 @@ flush-lines
 	(delete-region (save-excursion (goto-char (match-beginning 0))
 				       (forward-line 0)
 				       (point))
-		       (progn (forward-line 1) (point))))))
-  (set-marker rend nil)
-  nil)
+		       (progn (forward-line 1) (point)))
+        (setq count (1+ count))))
+    (set-marker rend nil)
+    (when interactive (message "Deleted %d matching line%s"
+			       count
+			       (if (= count 1) "" "s")))
+    count))
 
 
 (defun how-many (regexp &optional rstart rend interactive)

bug#34520: delete-matching-lines should report how many lines it deleted

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 27 Feb 2019 23:36:53 +0200
> Cc: 34520@debbugs.gnu.org
> 
> +    (when interactive (message "Deleted %d matching line%s"
> +			       count
> +			       (if (= count 1) "" "s")))
> +    count))

The concatenation of "s" trick works only in English, so please avoid
that.

This needs NEWS and manual updates.

Thanks.

bug#34520: delete-matching-lines should report how many lines it deleted

[Juri Linkov]

>> +    (when interactive (message "Deleted %d matching line%s"
>> +			       count
>> +			       (if (= count 1) "" "s")))
>> +    count))
>
> The concatenation of "s" trick works only in English, so please avoid
> that.

Ok, waiting for the times when ‘gettext’ will arrive to Emacs.

> This needs NEWS and manual updates.

Done.

bug#34520: delete-matching-lines should report how many lines it deleted

[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. ]]]

  > Ok, waiting for the times when ‘gettext’ will arrive to Emacs.

It would be very desirable to make Emacs support gettext-style
translations.  I have a feeling that it can't use the same
code as gettext -- but with all of Emacs's other facilities,
I think that transposing the useful part of gettext into
Emacs won't be a big job.

Would someone like to do this?


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

bug#34520: delete-matching-lines should report how many lines it deleted

[Juri Linkov]

>   > Ok, waiting for the times when ‘gettext’ will arrive to Emacs.
>
> It would be very desirable to make Emacs support gettext-style
> translations.  I have a feeling that it can't use the same
> code as gettext -- but with all of Emacs's other facilities,
> I think that transposing the useful part of gettext into
> Emacs won't be a big job.
>
> Would someone like to do this?

Emacs can do much better job of text translation than gettext.

It's easy to translate text transparently to the caller,
i.e. without changing the caller code at all, by adding
a new intermediate layer to some text output functions
that will translate their string arguments to the
language of the default language environment.

Here is an experimental but extensible implementation
that handles the case of formatting the recently added message
taking into account grammatical number of its argument:

  (defvar i18n-translations-hash (make-hash-table :test 'equal))

  (defun i18n-add-translation (_language-environment from to)
    (puthash from to i18n-translations-hash))

  (i18n-add-translation
   "English"
   "Deleted %d matching lines"
   (lambda (format-string count)
     (if (= count 1)
         "Deleted %d matching line"
         "Deleted %d matching lines")))

  (defun i18n-get-translation (format-string &rest args)
    (pcase (gethash format-string i18n-translations-hash)
      ((and (pred functionp) f) (apply f format-string args))
      ((and (pred stringp) s) s)
      (_ format-string)))

  (advice-add 'message :around
              (lambda (orig-fun format-string &rest args)
                (apply orig-fun (apply 'i18n-get-translation format-string args) args))
              '((name . message-i18n)))

In addition to translating format strings of the function 'message',
doing the same for more text output functions like 'describe-function',
'describe-variable' and 'menu-item' in 'define-key' would cover most
of the internationalization needs.

Re: bug#34520: delete-matching-lines should report how many lines it deleted

[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. ]]]

You wrote:

======================================================================
Here is an experimental but extensible implementation
that handles the case of formatting the recently added message
taking into account grammatical number of its argument:

  (defvar i18n-translations-hash (make-hash-table :test 'equal))

  (defun i18n-add-translation (_language-environment from to)
    (puthash from to i18n-translations-hash))

  (i18n-add-translation
   "English"
   "Deleted %d matching lines"
   (lambda (format-string count)
     (if (= count 1)
         "Deleted %d matching line"
         "Deleted %d matching lines")))

  (defun i18n-get-translation (format-string &rest args)
    (pcase (gethash format-string i18n-translations-hash)
      ((and (pred functionp) f) (apply f format-string args))
      ((and (pred stringp) s) s)
      (_ format-string)))

  (advice-add 'message :around
              (lambda (orig-fun format-string &rest args)
                (apply orig-fun (apply 'i18n-get-translation format-string args) args))
              '((name . message-i18n)))
======================================================================

It seems pretty good.  When installing it, it should not use
`advice-add'.  Rather, `message' should call a list of functions.

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

Re: Emacs i18n (was: bug#34520: delete-matching-lines should report how many lines it deleted)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 02 Mar 2019 22:04:06 -0500
> Cc: emacs-devel@gnu.org
> 
>   (advice-add 'message :around
>               (lambda (orig-fun format-string &rest args)
>                 (apply orig-fun (apply 'i18n-get-translation format-string args) args))
>               '((name . message-i18n)))
> ======================================================================
> 
> It seems pretty good.  When installing it, it should not use
> `advice-add'.  Rather, `message' should call a list of functions.

This has come up several times in the past.  The main problem with
i18n in Emacs is that, unlike in many text-mode programs, 'message'
covers a tiny portion of the Emacs UI.  We have help commands that pop
up buffers; we have commands that prompt in the minibuffer; we have
menu items and labels on tool-bar buttons; we have help-echo on menus,
tool bar, the mode line, and mouse-sensitive text; we have tooltips;
etc. etc.  What's worse, most of the text shown by these features is
computed dynamically by the commands that display the text.

Any reasonably relevant i18n infrastructure for Emacs should address
at least some of the above.  For example, a significant progress could
be made if we had infrastructure for translating doc strings, which
would allow translators to provide message catalogs for individual
Lisp packages.  Past discussions revealed that even this limited
progress is not really trivial.

Unfortunately, past discussions didn't lead to any significant
progress wrt this.  While doing some progress would be welcome, I
suggest that we don't pretend the solution is as easy as advice around
'message', but instead try to attack the more significant parts of the
problem.

Volunteers are welcome.

Re: Emacs i18n

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

>> It seems pretty good.  When installing it, it should not use
>> `advice-add'.  Rather, `message' should call a list of functions.
>
> Unfortunately, past discussions didn't lead to any significant
> progress wrt this.

My intention was to fix the bug which manifests itself in
grammatically incorrect sentences displayed by ‘message’ like

  Deleted 1 matching lines
  1 matches found
  ...

After searching for available packages I found only this page
https://savannah.nongnu.org/projects/emacs-i18n
that shows no progress for many years.

So here is a patch that fixes the bug by translating currently
invalid messages into grammatically correct English.  It also
opens the gate towards translation of messages in many languages.
Currently this feature is activated by (require 'i18n-message):

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: i18n-message.patch --]
[-- Type: text/x-diff, Size: 10283 bytes --]

diff --git a/lisp/replace.el b/lisp/replace.el
index 59ad1a375b..b05bb51353 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -986,6 +986,12 @@ flush-lines
     (when interactive (message "Deleted %d matching lines" count))
     count))
 
+(eval-after-load "i18n-message"
+  '(i18n-add-translation "English"
+                         "Deleted %d matching lines"
+                         '("Deleted %d matching line"
+                           "Deleted %d matching lines")))
+
 (defun how-many (regexp &optional rstart rend interactive)
   "Print and return number of matches for REGEXP following point.
 When called from Lisp and INTERACTIVE is omitted or nil, just return
@@ -1032,11 +1038,15 @@ how-many
 	(if (= opoint (point))
 	    (forward-char 1)
 	  (setq count (1+ count))))
-      (when interactive (message "%d occurrence%s"
-				 count
-				 (if (= count 1) "" "s")))
+      (when interactive (message "%d occurrences" count))
       count)))
 
+(eval-after-load "i18n-message"
+  '(i18n-add-translation "English"
+                         "%d occurrences"
+                         '("%d occurrence"
+                           "%d occurrences")))
+
 \f
 (defvar occur-menu-map
   (let ((map (make-sparse-keymap)))
@@ -2730,10 +2740,7 @@ perform-replace
                                            (1+ num-replacements))))))
                              (when (and (eq def 'undo-all)
                                         (null (zerop num-replacements)))
-                               (message "Undid %d %s" num-replacements
-                                        (if (= num-replacements 1)
-                                            "replacement"
-                                          "replacements"))
+                               (message "Undid %d replacements" num-replacements)
                                (ding 'no-terminate)
                                (sit-for 1)))
 			   (setq replaced nil last-was-undo t last-was-act-and-show nil)))
@@ -2859,9 +2866,8 @@ perform-replace
                       last-was-act-and-show     nil))))))
       (replace-dehighlight))
     (or unread-command-events
-	(message "Replaced %d occurrence%s%s"
+	(message "Replaced %d occurrences%s"
 		 replace-count
-		 (if (= replace-count 1) "" "s")
 		 (if (> (+ skip-read-only-count
 			   skip-filtered-count
 			   skip-invisible-count)
@@ -2883,6 +2889,16 @@ perform-replace
 		   "")))
     (or (and keep-going stack) multi-buffer)))
 
+(eval-after-load "i18n-message"
+  '(i18n-add-translations
+    "English"
+    '(("Undid %d replacements"
+       ("Undid %d replacement"
+        "Undid %d replacements"))
+      ("Replaced %d occurrences%s"
+       ("Replaced %d occurrence%s"
+        "Replaced %d occurrences%s")))))
+
 (provide 'replace)
 
 ;;; replace.el ends here
diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el
index 3fd2a7e701..d2d748fca3 100644
--- a/lisp/progmodes/grep.el
+++ b/lisp/progmodes/grep.el
@@ -459,7 +459,7 @@ grep-mode-font-lock-keywords
      ;; remove match from grep-regexp-alist before fontifying
      ("^Grep[/a-zA-z]* started.*"
       (0 '(face nil compilation-message nil help-echo nil mouse-face nil) t))
-     ("^Grep[/a-zA-z]* finished with \\(?:\\(\\(?:[0-9]+ \\)?matches found\\)\\|\\(no matches found\\)\\).*"
+     ("^Grep[/a-zA-z]* finished with \\(?:\\(\\(?:[0-9]+ \\)?match\\(?:es\\)? found\\)\\|\\(no matches found\\)\\).*"
       (0 '(face nil compilation-message nil help-echo nil mouse-face nil) t)
       (1 compilation-info-face nil t)
       (2 compilation-warning-face nil t))
@@ -561,6 +561,12 @@ grep-exit-message
 	     (cons msg code)))
     (cons msg code)))
 
+(eval-after-load "i18n-message"
+  '(i18n-add-translation "English"
+                         "finished with %d matches found\n"
+                         '("finished with %d match found\n"
+                           "finished with %d matches found\n")))
+
 (defun grep-filter ()
   "Handle match highlighting escape sequences inserted by the grep process.
 This function is called from `compilation-filter-hook'."
diff --git a/lisp/international/i18n-message.el b/lisp/international/i18n-message.el
new file mode 100644
index 0000000000..14755966e0
--- /dev/null
+++ b/lisp/international/i18n-message.el
@@ -0,0 +1,118 @@
+;;; i18n-message.el --- internationalization of messages  -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2019 Free Software Foundation, Inc.
+
+;; Author: Juri Linkov <juri@linkov.net>
+;; Maintainer: emacs-devel@gnu.org
+;; Keywords: i18n, multilingual
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;;
+
+;;; Code:
+
+(defcustom i18n-fallbacks
+  '(("en" "English"))
+  "An alist mapping the current language to possible fallbacks.
+Each element should look like (\"LANG\" . FALLBACK-LIST), where
+FALLBACK-LIST is a list of languages to try to find a translation."
+  :type '(alist :key-type (string :tag "Current language")
+                :value-type (repeat :tag "A list of fallbacks" string))
+  :group 'i18n
+  :version "27.1")
+
+(defvar i18n-dictionaries (make-hash-table :test 'equal))
+
+(defun i18n-add-dictionary (lang)
+  (unless (gethash lang i18n-dictionaries)
+    (puthash lang (make-hash-table :test 'equal) i18n-dictionaries)))
+
+;;;###autoload
+(defun i18n-add-translation (lang from to)
+  (let ((dict (gethash lang i18n-dictionaries)))
+    (unless dict
+      (setq dict (i18n-add-dictionary lang)))
+    (puthash from to dict)))
+
+;;;###autoload
+(defun i18n-add-translations (lang translations)
+  (dolist (translation translations)
+    (i18n-add-translation lang (nth 0 translation) (nth 1 translation))))
+
+(defun i18n-get-plural (lang n)
+  ;; Source: (info "(gettext) Plural forms")
+  (pcase lang
+    ((or "Japanese" "Vietnamese" "Korean" "Thai")
+     0)
+    ((or "English" "German" "Dutch" "Swedish" "Danish" "Norwegian"
+         "Faroese" "Spanish" "Portuguese" "Italian" "Bulgarian" "Greek"
+         "Finnish" "Estonian" "Hebrew" "Bahasa Indonesian" "Esperanto"
+         "Hungarian" "Turkish")
+     (if (/= n 1) 1 0))
+    ((or "Brazilian Portuguese" "French")
+     (if (> n 1) 1 0))
+    ((or "Latvian")
+     (if (and (= (% n 10) 1) (/= (% n 100) 11)) 0 (if (/= n 0) 1 2)))
+    ((or "Gaeilge" "Irish")
+     (if (= n 1) 0 (if (= n 2) 1 2)))
+    ((or "Romanian")
+     (if (= n 1) 0 (if (or (= n 0) (and (> (% n 100) 0) (< (% n 100) 20))) 1 2)))
+    ((or "Lithuanian")
+     (if (and (= (% n 10) 1) (/= (% n 100) 11)) 0
+       (if (and (>= (% n 10) 2) (or (< (% n 100) 10) (>= (% n 100) 20))) 1 2)))
+    ((or "Russian" "Ukrainian" "Belarusian" "Serbian" "Croatian")
+     (if (and (= (% n 10) 1) (/= (% n 100) 11)) 0
+       (if (and (>= (% n 10) 2) (<= (% n 10) 4) (or (< (% n 100) 10) (>= (% n 100) 20))) 1 2)))
+    ((or "Czech" "Slovak")
+     (if (= n 1) 0 (if (and (>= n 2) (<= n 4)) 1 2)))
+    ((or "Polish")
+     (if (= n 1) 0
+       (if (and (>= (% n 10) 2) (<= (% n 10) 4) (or (< (% n 100) 10) (>= (% n 100) 20))) 1 2)))
+    ((or "Slovenian")
+     (if (= (% n 100) 1) 0 (if (= (% n 100) 2) 1 (if (or (= (% n 100) 3) (= (% n 100) 4)) 2 3))))
+    ((or "Arabic")
+     (if (= n 0) 0 (if (= n 1) 1 (if (= n 2) 2 (if (and (>= (% n 100) 3) (<= (% n 100) 10)) 3
+                                                 (if (>= (% n 100) 11) 4 5))))))))
+
+(defun i18n-get-translation (format-string &rest args)
+  (let* ((lang current-language-environment)
+	 (fallbacks (cdr (assoc lang i18n-fallbacks)))
+	 dict found)
+    (while (and (not found) lang)
+      (when (setq dict (gethash lang i18n-dictionaries))
+	(setq found
+              (pcase (gethash format-string dict)
+		((and (pred functionp) f) (apply f format-string args))
+		((and (pred stringp) s) s)
+		((and (pred consp) l)
+		 (let ((n (i18n-get-plural lang (car args))))
+		   (when n (nth n l)))))))
+      (unless found
+	(setq lang (pop fallbacks))))
+    (or found format-string)))
+
+(defun i18n-message-translate (&rest args)
+  (apply 'i18n-get-translation args))
+
+(defvar message-translate-function)
+
+(setq message-translate-function 'i18n-message-translate)
+
+(provide 'i18n-message)
+;;; i18n-message.el ends here
diff --git a/src/editfns.c b/src/editfns.c
index bffb5db43e..f517679576 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -3050,6 +3050,14 @@ produced text.
 usage: (format STRING &rest OBJECTS)  */)
   (ptrdiff_t nargs, Lisp_Object *args)
 {
+  if (!NILP (Vmessage_translate_function) && nargs > 0)
+    {
+      Lisp_Object format = apply1 (Vmessage_translate_function,
+				   Flist (nargs, args));
+      if (STRINGP (format))
+	args[0] = format;
+    }
+
   return styled_format (nargs, args, false);
 }
 
@@ -3066,6 +3074,14 @@ and right quote replacement characters are specified by
 usage: (format-message STRING &rest OBJECTS)  */)
   (ptrdiff_t nargs, Lisp_Object *args)
 {
+  if (!NILP (Vmessage_translate_function) && nargs > 0)
+    {
+      Lisp_Object format = apply1 (Vmessage_translate_function,
+				   Flist (nargs, args));
+      if (STRINGP (format))
+	args[0] = format;
+    }
+
   return styled_format (nargs, args, true);
 }
 
@@ -4462,6 +4478,11 @@ of the buffer being accessed.  */);
 functions if all the text being accessed has this property.  */);
   Vbuffer_access_fontified_property = Qnil;
 
+  DEFVAR_LISP ("message-translate-function",
+	       Vmessage_translate_function,
+	       doc: /* Function that translates messages.  */);
+  Vmessage_translate_function = Qnil;
+
   DEFVAR_LISP ("system-name", Vsystem_name,
 	       doc: /* The host name of the machine Emacs is running on.  */);
   Vsystem_name = cached_system_name = Qnil;

Re: Emacs i18n

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]



> On Mar 4, 2019, at 5:57, Juri Linkov <juri@linkov.net <mailto:juri@linkov.net>> wrote:
> 
> My intention was to fix the bug which manifests itself in
> grammatically incorrect sentences displayed by ‘message’ like
> 
>  Deleted 1 matching lines
>  1 matches found
>  ...

The best way to do that (I fixed the almost 100% of the package.el code with that) is to not use such syntax but rather things like:

Number of matches found: %d


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com <http://mac4translators.blogspot.com/> @brandelune



[-- Attachment #2: Type: text/html, Size: 3121 bytes --]

Re: Emacs i18n

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

On Mon, 4 Mar 2019 at 09:48, Jean-Christophe Helary <brandelune@gmail.com>
wrote:

>
> The best way to do that (I fixed the almost 100% of the package.el code
> with that) is to not use such syntax but rather things like:
>
> Number of matches found: %d
>

That works for English most of the time (although I would argue that it
isn't great). But it may be harder in other languages.

[-- Attachment #2: Type: text/html, Size: 979 bytes --]

Re: Emacs i18n

[Jean-Christophe Helary]

> On Mar 6, 2019, at 18:38, Elias Mårtenson 
> 
> The best way to do that (I fixed the almost 100% of the package.el code with that) is to not use such syntax but rather things like:
> 
> Number of matches found: %d
> 
> That works for English most of the time (although I would argue that it isn't great).

I'm not sure why that is not "great" here. But I know from what I saw in packages.el that what is even less great it to get lost in lisp that attempts to mimic natural language inflections.

> But it may be harder in other languages.

It is unlikely that this structure is harder in non English languages than the original. Removing the need to express the difference in number actually removes an order of complexity.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Clément Pit-Claudel]

On 2019-03-03 20:46, Jean-Christophe Helary wrote:
>> On Mar 4, 2019, at 5:57, Juri Linkov <juri@linkov.net <mailto:juri@linkov.net>> wrote:
>> My intention was to fix the bug which manifests itself in
>> grammatically incorrect sentences displayed by ‘message’ like
>>
>>  Deleted 1 matching lines
>>  1 matches found
>>  ...
> 
> The best way to do that (I fixed the almost 100% of the package.el code with that) is to not use such syntax but rather things like:
> 
> Number of matches found: %d

I'm a bit late to the party, but I hope it's still OK to respond :)  This is a valid way to work around the issue, but I'm not sure how much I like it (I just noticed the change after pulling the latest Emacs from git).

The current package.el doesn't say 'Number of packages that are not available: %d'; instead, it says 'Packages that are not available: %d' (it used to say "%s packages are not available").  Other examples are 'Packages to hide: %d' (originally 'Hiding %s packages') and 'Packages that can be upgraded: %d; type `%s' to mark for upgrading.' (originally '%d package%s can be upgraded; type `%s' to mark %s for upgrading.').

I find this suboptimal for three reasons: First, after 'packages that are not available', I expect to see a list of packages, not a number.  Second, the new way the message is phrased puts the important bit in a less obvious place (in the middle of the message, rather than at the beginning: "Packages that can be upgraded: 5; type `U' to mark for upgrading"). Third (but this is a bit more fuzzy), the way the message is now written makes errors sound like normal events ('Packages that are not available: 3' read like the response to the query 'how many packages are not available?').

I understand that there's hope to support plurals and internationalization in a more principled way soon, but is this workaround (61f73703c74756e6963cc622f03bcc6938ab71b2) needed in the meantime?

Clément.

Re: Emacs i18n

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, Richard Stallman <rms@gnu.org>,
>  emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 21 Mar 2019 16:33:21 -0400
> 
> I understand that there's hope to support plurals and internationalization in a more principled way soon, but is this workaround (61f73703c74756e6963cc622f03bcc6938ab71b2) needed in the meantime?

Whether we like it or not, it's one of the standard methods of solving
these situations.  It might sound somewhat more awkward in some
languages than the original wording, but it has other more important
advantages.

Re: Emacs i18n

[Clément Pit-Claudel]

On 2019-03-21 16:50, Eli Zaretskii wrote:
>> Cc: Eli Zaretskii <eliz@gnu.org>, Richard Stallman <rms@gnu.org>,
>>  emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 21 Mar 2019 16:33:21 -0400
>>
>> I understand that there's hope to support plurals and internationalization in a more principled way soon, but is this workaround (61f73703c74756e6963cc622f03bcc6938ab71b2) needed in the meantime?
> 
> Whether we like it or not, it's one of the standard methods of solving
> these situations.  It might sound somewhat more awkward in some
> languages than the original wording, but it has other more important
> advantages.

I don't understand: what does this change buy us currently, except the awkward wording?  Arguably the patch for the change was a simplification, but the original author had actually writen the code to get the English plurals right in most cases.

Re: Emacs i18n

[Jean-Christophe Helary]

> On Mar 22, 2019, at 6:03, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
> 
> but the original author had actually writen the code to get the English plurals right in most cases.

Yes, but the issue is not to have "most cases right" but rather to have readable strings in the code.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Clément Pit-Claudel]

On 2019-03-21 17:21, Jean-Christophe Helary wrote:
>> On Mar 22, 2019, at 6:03, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
>>
>> but the original author had actually writen the code to get the English plurals right in most cases.
> 
> Yes, but the issue is not to have "most cases right" but rather to have readable strings in the code.

But is that worth the loss in readability in the UI?

Re: Emacs i18n

[Jean-Christophe Helary]

> On Mar 22, 2019, at 6:34, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
> 
> On 2019-03-21 17:21, Jean-Christophe Helary wrote:
>>> On Mar 22, 2019, at 6:03, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
>>> 
>>> but the original author had actually writen the code to get the English plurals right in most cases.
>> 
>> Yes, but the issue is not to have "most cases right" but rather to have readable strings in the code.
> 
> But is that worth the loss in readability in the UI?

That's a subjective issue. I think the strings are more readable now and there are potentially less grammatical mistakes (I am not talking about the "Number of" part you mentioned). While before it was easy to not notice a bug in the code. I think that is a net gain.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Clément Pit-Claudel]

On 2019-03-21 17:56, Jean-Christophe Helary wrote:
> 
> 
>> On Mar 22, 2019, at 6:34, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
>>
>> On 2019-03-21 17:21, Jean-Christophe Helary wrote:
>>>> On Mar 22, 2019, at 6:03, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
>>>>
>>>> but the original author had actually writen the code to get the English plurals right in most cases.
>>>
>>> Yes, but the issue is not to have "most cases right" but rather to have readable strings in the code.
>>
>> But is that worth the loss in readability in the UI?
> 
> That's a subjective issue. I think the strings are more readable now and there are potentially less grammatical mistakes (I am not talking about the "Number of" part you mentioned). While before it was easy to not notice a bug in the code. I think that is a net gain.

Understood, thanks.  I would have preferred sticking with the previous phrasing, but a single opinion is not much to act upon.

Re: Emacs i18n

[Jean-Christophe Helary]

> On Mar 22, 2019, at 7:05, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
> 
>> That's a subjective issue. I think the strings are more readable now and there are potentially less grammatical mistakes (I am not talking about the "Number of" part you mentioned). While before it was easy to not notice a bug in the code. I think that is a net gain.
> 
> Understood, thanks.  I would have preferred sticking with the previous phrasing, but a single opinion is not much to act upon.

:) No, it's quite the opposite. everything starts from a single opinion. I would also prefer to stick to more natural sounding phrasing, but the tools available at the moment don't allow for that.

It is usually accepted in code internationalization that concatenation and other similar processes should not be used to generate natural language strings. So there are 2 ways to deal with that: either you simplify the strings to the point where there are as little variations possible (my choice for packages.el) or you use strings redundancy to cover all the possible variations with processes that support that (which we don't have at the moment).

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Eli Zaretskii]

> Cc: brandelune@gmail.com, juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 21 Mar 2019 17:03:31 -0400
> 
> > Whether we like it or not, it's one of the standard methods of solving
> > these situations.  It might sound somewhat more awkward in some
> > languages than the original wording, but it has other more important
> > advantages.
> 
> I don't understand: what does this change buy us currently, except the awkward wording?

It brings us a step closer to the i18n goal.  A very small step,
admittedly, but step in the right direction nonetheless.

Re: Emacs i18n

[Clément Pit-Claudel]

On 2019-03-22 04:22, Eli Zaretskii wrote:
>> Cc: brandelune@gmail.com, juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Thu, 21 Mar 2019 17:03:31 -0400
>>
>>> Whether we like it or not, it's one of the standard methods of solving
>>> these situations.  It might sound somewhat more awkward in some
>>> languages than the original wording, but it has other more important
>>> advantages.
>>
>> I don't understand: what does this change buy us currently, except the awkward wording?
> 
> It brings us a step closer to the i18n goal.  A very small step,
> admittedly, but step in the right direction nonetheless.

Thanks, that's what puzzles me.  IIUC, we will revert to the previous strings once we have proper translation support in place, right?

Re: Emacs i18n

[Eli Zaretskii]

> Cc: brandelune@gmail.com, juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 22 Mar 2019 12:10:42 -0400
> 
> > It brings us a step closer to the i18n goal.  A very small step,
> > admittedly, but step in the right direction nonetheless.
> 
> Thanks, that's what puzzles me.  IIUC, we will revert to the previous strings once we have proper translation support in place, right?

It isn't clear to me yet.  At least at the time this change was made,
we didn't expect to revert, we thought this form will remain when it
can be translated.

Re: Emacs i18n

[Clément Pit-Claudel]

On 2019-03-22 12:35, Eli Zaretskii wrote:
>> Cc: brandelune@gmail.com, juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 22 Mar 2019 12:10:42 -0400
>>
>>> It brings us a step closer to the i18n goal.  A very small step,
>>> admittedly, but step in the right direction nonetheless.
>>
>> Thanks, that's what puzzles me.  IIUC, we will revert to the previous strings once we have proper translation support in place, right?
> 
> It isn't clear to me yet.  At least at the time this change was made,
> we didn't expect to revert, we thought this form will remain when it
> can be translated.

Oh!  Then I misunderstood.  I thought the idea was that once we have a library that can handle this well, we'd write something like (ngettext "One package installed" "%d packages installed" n), with ngettext picking between both in English and picking the appropriate string in other languages.

Clément.

Re: Emacs i18n

[Eli Zaretskii]

> Cc: brandelune@gmail.com, juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 22 Mar 2019 13:16:17 -0400
> 
> > It isn't clear to me yet.  At least at the time this change was made,
> > we didn't expect to revert, we thought this form will remain when it
> > can be translated.
> 
> Oh!  Then I misunderstood.  I thought the idea was that once we have a library that can handle this well, we'd write something like (ngettext "One package installed" "%d packages installed" n), with ngettext picking between both in English and picking the appropriate string in other languages.

Maybe.  ngettext wasn't on the table when this change was made, and
even now I'm not yet sure what the end result will look like.

Re: Emacs i18n

[Clément Pit-Claudel]

On 2019-03-22 13:35, Eli Zaretskii wrote:
>> Cc: brandelune@gmail.com, juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 22 Mar 2019 13:16:17 -0400
>>
>>> It isn't clear to me yet.  At least at the time this change was made,
>>> we didn't expect to revert, we thought this form will remain when it
>>> can be translated.
>>
>> Oh!  Then I misunderstood.  I thought the idea was that once we have a library that can handle this well, we'd write something like (ngettext "One package installed" "%d packages installed" n), with ngettext picking between both in English and picking the appropriate string in other languages.
> 
> Maybe.  ngettext wasn't on the table when this change was made, and
> even now I'm not yet sure what the end result will look like.

Got it. Thanks for taking the time to explain!

Re: Emacs i18n

[Jean-Christophe Helary]

Thank you Clement for the remarks. I wrote all at first because there were issues with the original code that did not take into account some singular cases. When I checked the code, I found a terrible amount of strings mixed with code and so I went a bit further and "fixed" that too. I don't remember forgetting about that "Number" issue you mention though. Sorry for that.

Jean-Christophe 

> On Mar 22, 2019, at 5:33, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
> 
> On 2019-03-03 20:46, Jean-Christophe Helary wrote:
>>> On Mar 4, 2019, at 5:57, Juri Linkov <juri@linkov.net <mailto:juri@linkov.net>> wrote:
>>> My intention was to fix the bug which manifests itself in
>>> grammatically incorrect sentences displayed by ‘message’ like
>>> 
>>> Deleted 1 matching lines
>>> 1 matches found
>>> ...
>> 
>> The best way to do that (I fixed the almost 100% of the package.el code with that) is to not use such syntax but rather things like:
>> 
>> Number of matches found: %d
> 
> I'm a bit late to the party, but I hope it's still OK to respond :)  This is a valid way to work around the issue, but I'm not sure how much I like it (I just noticed the change after pulling the latest Emacs from git).
> 
> The current package.el doesn't say 'Number of packages that are not available: %d'; instead, it says 'Packages that are not available: %d' (it used to say "%s packages are not available").  Other examples are 'Packages to hide: %d' (originally 'Hiding %s packages') and 'Packages that can be upgraded: %d; type `%s' to mark for upgrading.' (originally '%d package%s can be upgraded; type `%s' to mark %s for upgrading.').
> 
> I find this suboptimal for three reasons: First, after 'packages that are not available', I expect to see a list of packages, not a number.  Second, the new way the message is phrased puts the important bit in a less obvious place (in the middle of the message, rather than at the beginning: "Packages that can be upgraded: 5; type `U' to mark for upgrading"). Third (but this is a bit more fuzzy), the way the message is now written makes errors sound like normal events ('Packages that are not available: 3' read like the response to the query 'how many packages are not available?').
> 
> I understand that there's hope to support plurals and internationalization in a more principled way soon, but is this workaround (61f73703c74756e6963cc622f03bcc6938ab71b2) needed in the meantime?
> 
> Clément.
> 

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Juri Linkov]

> The current package.el doesn't say 'Number of packages that are not
> available: %d'; instead, it says 'Packages that are not available: %d'
> (it used to say "%s packages are not available").

Both don't sound natural, it's too robotic.
Let's use ngettext plurals from now on.

Re: Emacs i18n

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Jean-Christophe Helary <brandelune@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,  Richard Stallman <rms@gnu.org>,  emacs-devel@gnu.org
> Date: Thu, 21 Mar 2019 23:59:23 +0200
> 
> Let's use ngettext plurals from now on.

I don't think I understand the practical implications of that.  Could
you please elaborate?

Re: Emacs i18n

[Juri Linkov]

>> Let's use ngettext plurals from now on.
>
> I don't think I understand the practical implications of that.  Could
> you please elaborate?

This means replacing

  (message "Packages to install: %d" n)

with

  (message (ngettext "One package will be installed"
                     "%d packages will be installed" n) n)

Re: Emacs i18n

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: cpitclaudel@gmail.com,  brandelune@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 23 Mar 2019 23:50:53 +0200
> 
> >> Let's use ngettext plurals from now on.
> >
> > I don't think I understand the practical implications of that.  Could
> > you please elaborate?
> 
> This means replacing
> 
>   (message "Packages to install: %d" n)
> 
> with
> 
>   (message (ngettext "One package will be installed"
>                      "%d packages will be installed" n) n)

But since we don't yet have ngettext, we cannot yet use this
paradigm.  I thought by "from now on" you literally meant from now;
did I misunderstand?

Re: Emacs i18n

[Juri Linkov]

>> >> Let's use ngettext plurals from now on.
>> >
>> > I don't think I understand the practical implications of that.  Could
>> > you please elaborate?
>> 
>> This means replacing
>> 
>>   (message "Packages to install: %d" n)
>> 
>> with
>> 
>>   (message (ngettext "One package will be installed"
>>                      "%d packages will be installed" n) n)
>
> But since we don't yet have ngettext, we cannot yet use this
> paradigm.  I thought by "from now on" you literally meant from now;
> did I misunderstand?

Yes, literally.  After the patch from
http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00586.html
is pushed to master, ngettext is available to use for pluralization.

Re: Emacs i18n

[Jean-Christophe Helary]

> On Mar 25, 2019, at 6:55, Juri Linkov <juri@linkov.net> wrote:
> 
>>>>> Let's use ngettext plurals from now on.
>>>> 
>>>> I don't think I understand the practical implications of that.  Could
>>>> you please elaborate?
>>> 
>>> This means replacing
>>> 
>>>  (message "Packages to install: %d" n)
>>> 
>>> with
>>> 
>>>  (message (ngettext "One package will be installed"
>>>                     "%d packages will be installed" n) n)
>> 
>> But since we don't yet have ngettext, we cannot yet use this
>> paradigm.  I thought by "from now on" you literally meant from now;
>> did I misunderstand?
> 
> Yes, literally.  After the patch from
> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00586.html
> is pushed to master, ngettext is available to use for pluralization.

Why put the patch in subr.el and not in its own i18n related new package ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Juri Linkov]

> Why put the patch in subr.el and not in its own i18n related new package ?

I don't know where to put i18n related code, so since ngettext should
have C calls anyway, I moved it to editfns.c near the function ‘message’
where it still just returns the correct plurals without doing any translation.

Re: Emacs i18n

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

On 3/25/19 2:32 PM, Juri Linkov wrote:
> I don't know where to put i18n related code, so since ngettext should
> have C calls anyway, I moved it to editfns.c near the function ‘message’
> where it still just returns the correct plurals without doing any translation.

That stub had some problems:

1. It lacked documentation in the Elisp manual. Important changes like
this should be documented -- to some extent the documentation is even
more important than the code. Can you write something?

2. While you're thinking about (1) here are some other questions. How
will ngettext determine the message catalog? Is the catalog visible to
users as a global variable, or as a hidden part of the global state, or
is it something explicit? How will catalogs from multiple packages be
used? How would a multi-lingual application work in Emacs if the message
catalog is part of global state? This seems to be a crucial issue, I'd
say. For example, should Emacs export dcngettext to Lisp code, instead
of just plain ngettext? (Emacs could then define ngettext in terms of
dcngettext.)

3. User C code is not supposed to inspect the _LIBC macro; that's for
glibc internal use. In Emacs _LIBC should be used only with code shared
with glibc, and we should assume _LIBC is never defined when files are
compiled for Emacs.

4. The stub doesn't work with bignums.

5. When calling the C-level ngettext, strings are not properly recoded.

I fixed (3) and (4), and temporarily worked around (5), by installing
the attached patch. To do a better job with (2) and (5) please see the
gettext manual's instructions for package maintainers, here:

https://www.gnu.org/software/gettext/manual/gettext.html#Maintainers

To my mind (1) and (2) are the most-pressing problems.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Port-recent-ngettext-stub-to-non-glibc.patch --]
[-- Type: text/x-patch; name="0001-Port-recent-ngettext-stub-to-non-glibc.patch", Size: 2850 bytes --]

From a361c54b8339ad79f65e924c4a1f7bbcdb1859e2 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 25 Mar 2019 15:20:20 -0700
Subject: [PATCH] Port recent ngettext stub to non-glibc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/editfns.c: Don’t try to call glibc ngettext;
we’re not ready for that yet.
(Fngettext): Do not restrict integer arguments to fixnums.
Improve doc string a bit.
---
 src/editfns.c | 34 +++++++++-------------------------
 1 file changed, 9 insertions(+), 25 deletions(-)

diff --git a/src/editfns.c b/src/editfns.c
index ab48cdb6fd..bfffadc733 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -53,12 +53,6 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 #include "window.h"
 #include "blockinput.h"
 
-#ifdef _LIBC
-# include <libintl.h>
-#else
-# include "gettext.h"
-#endif
-
 static void update_buffer_properties (ptrdiff_t, ptrdiff_t);
 static Lisp_Object styled_format (ptrdiff_t, Lisp_Object *, bool);
 
@@ -2845,30 +2839,20 @@ usage: (save-restriction &rest BODY)  */)
 /* i18n (internationalization).  */
 
 DEFUN ("ngettext", Fngettext, Sngettext, 3, 3, 0,
-       doc: /* Return the plural form of the translation of the string.
-This function is similar to the `gettext' function as it finds the message
-catalogs in the same way.  But it takes two extra arguments.  The MSGID
-parameter must contain the singular form of the string to be converted.
-It is also used as the key for the search in the catalog.
-The MSGID_PLURAL parameter is the plural form.  The parameter N is used
-to determine the plural form.  If no message catalog is found MSGID is
-returned if N is equal to 1, otherwise MSGID_PLURAL.  */)
+       doc: /* Return the translation of MSGID (plural MSGID_PLURAL) depending on N.
+MSGID is the singular form of the string to be converted;
+use it as the key for the search in the translation catalog.
+MSGID_PLURAL is the plural form.  Use N to select the proper translation.
+If no message catalog is found, MSGID is returned if N is equal to 1,
+otherwise MSGID_PLURAL.  */)
   (Lisp_Object msgid, Lisp_Object msgid_plural, Lisp_Object n)
 {
   CHECK_STRING (msgid);
   CHECK_STRING (msgid_plural);
-  CHECK_FIXNUM (n);
+  CHECK_INTEGER (n);
 
-#ifdef _LIBGETTEXT_H
-  return build_string (ngettext (SSDATA (msgid),
-                                 SSDATA (msgid_plural),
-                                 XFIXNUM (n)));
-#else
-  if (XFIXNUM (n) == 1)
-    return msgid;
-  else
-    return msgid_plural;
-#endif
+  /* Placeholder implementation until we get our act together.  */
+  return EQ (n, make_fixnum (1)) ? msgid : msgid_plural;
 }
 \f
 DEFUN ("message", Fmessage, Smessage, 1, MANY, 0,
-- 
2.20.1

Re: Emacs i18n

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 25 Mar 2019 15:31:14 -0700
> Cc: Jean-Christophe Helary <brandelune@gmail.com>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> 2. While you're thinking about (1) here are some other questions. How
> will ngettext determine the message catalog? Is the catalog visible to
> users as a global variable, or as a hidden part of the global state, or
> is it something explicit? How will catalogs from multiple packages be
> used? How would a multi-lingual application work in Emacs if the message
> catalog is part of global state? This seems to be a crucial issue, I'd
> say. For example, should Emacs export dcngettext to Lisp code, instead
> of just plain ngettext? (Emacs could then define ngettext in terms of
> dcngettext.)

Do we have any reasons not to follow the CLISP example of factoring
these issues?

> 5. When calling the C-level ngettext, strings are not properly recoded.

Did you mean decoding the translated string that ngettext returns?  If
so, we will need some way of getting at the encoding of the strings in
the catalog, I think.  Or will we mandate that Emacs catalogs need
always to be in UTF-8 encoding?

Re: Emacs i18n

[Stefan Monnier]

> Did you mean decoding the translated string that ngettext returns?  If
> so, we will need some way of getting at the encoding of the strings in
> the catalog, I think.  Or will we mandate that Emacs catalogs need
> always to be in UTF-8 encoding?

Mandating `utf-8-emacs` would make things simpler.


        Stefan

Re: Emacs i18n

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 26 Mar 2019 12:22:52 -0400
> 
> > Did you mean decoding the translated string that ngettext returns?  If
> > so, we will need some way of getting at the encoding of the strings in
> > the catalog, I think.  Or will we mandate that Emacs catalogs need
> > always to be in UTF-8 encoding?
> 
> Mandating `utf-8-emacs` would make things simpler.

If the translators won't mind, sure.

Or maybe we will recode into UTF-8 before importing those catalogs
that aren't.

Re: Emacs i18n

[Paul Eggert]

On 3/26/19 9:11 AM, Eli Zaretskii wrote:
>> 2. While you're thinking about (1) here are some other questions. How
>> will ngettext determine the message catalog? Is the catalog visible to
>> users as a global variable, or as a hidden part of the global state, or
>> is it something explicit? How will catalogs from multiple packages be
>> used? How would a multi-lingual application work in Emacs if the message
>> catalog is part of global state? This seems to be a crucial issue, I'd
>> say. For example, should Emacs export dcngettext to Lisp code, instead
>> of just plain ngettext? (Emacs could then define ngettext in terms of
>> dcngettext.)
> Do we have any reasons not to follow the CLISP example of factoring
> these issues?

That's the first I've heard that CLISP does gettext. I looked into it,
and it's a reasonably simple binding, which means that the language is
part of the global state (Emacs would not easily be multilingual) and
that each package can have its own catalog and can specify that catalog
as a trailing argument to gettext (presumably the default catalog would
be for Emacs core). This should be good enough, though it will be a bit
of a hassle for non-core code to keep track of the catalog.


> will we mandate that Emacs catalogs need
> always to be in UTF-8 encoding?

Yes, that makes sense.

Re: Emacs i18n

[Eli Zaretskii]

> Cc: juri@linkov.net, brandelune@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 26 Mar 2019 15:35:22 -0700
> 
> > Do we have any reasons not to follow the CLISP example of factoring
> > these issues?
> 
> That's the first I've heard that CLISP does gettext.

I learned that from post by Bruno here up-thread.

> I looked into it, and it's a reasonably simple binding, which means
> that the language is part of the global state (Emacs would not
> easily be multilingual)

We could offer the language as another optional argument.  I'm not
sure we need to allow control of the CATEGORY (for choosing the LC_*
category), so we could replace that with the language.  Or we could
keep CATEGORY for compatibility and just add LANGUAGE.

> and that each package can have its own catalog and can specify that
> catalog as a trailing argument to gettext (presumably the default
> catalog would be for Emacs core). This should be good enough, though
> it will be a bit of a hassle for non-core code to keep track of the
> catalog.

If we want some automatic way of changing the domain when a function
from a package is called, we need to develop the infrastructure for
that.  But that could wait for later, I think.

Re: Emacs i18n

[Clément Pit-Claudel]

On 2019-03-26 23:43, Eli Zaretskii wrote:
> If we want some automatic way of changing the domain when a function
> from a package is called, we need to develop the infrastructure for
> that.  But that could wait for later, I think.

I expect I'd define a foo-ngettext macro in each `foo' package expanding to ngettext with the appropriate group argument.  If there are multiple functions (gettext, ngettext, etc), maybe a single macro defining all foo-* variants at once would be nice.

Clément.

Re: Emacs i18n

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 28 Mar 2019 10:56:44 -0400
> 
> On 2019-03-26 23:43, Eli Zaretskii wrote:
> > If we want some automatic way of changing the domain when a function
> > from a package is called, we need to develop the infrastructure for
> > that.  But that could wait for later, I think.
> 
> I expect I'd define a foo-ngettext macro in each `foo' package expanding to ngettext with the appropriate group argument.  If there are multiple functions (gettext, ngettext, etc), maybe a single macro defining all foo-* variants at once would be nice.

I really hope we could come up with something more elegant.  And
besides, your suggestion doesn't handle calls from Lisp packages to
core APIs, including primitives and modules.

Re: Emacs i18n

[Jean-Christophe Helary]

> On Mar 27, 2019, at 1:11, Eli Zaretskii <eliz@gnu.org> wrote:

> Or will we mandate that Emacs catalogs need
> always to be in UTF-8 encoding?

Please.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Juri Linkov]

>> I don't know where to put i18n related code, so since ngettext should
>> have C calls anyway, I moved it to editfns.c near the function ‘message’
>> where it still just returns the correct plurals without doing any translation.
>
> That stub had some problems:
>
> 1. It lacked documentation in the Elisp manual. Important changes like
> this should be documented -- to some extent the documentation is even
> more important than the code. Can you write something?

I'll start writing documentation.  Is it allowed to make
references from the Elisp manual to the Gettext Info manual?
I see in (info "(gettext) elisp-format") a reference back to
the Elisp manual is a web link, not an Info reference.

> 2. While you're thinking about (1) here are some other questions. How
> will ngettext determine the message catalog? Is the catalog visible to
> users as a global variable, or as a hidden part of the global state, or
> is it something explicit? How will catalogs from multiple packages be
> used? How would a multi-lingual application work in Emacs if the message
> catalog is part of global state? This seems to be a crucial issue, I'd
> say. For example, should Emacs export dcngettext to Lisp code, instead
> of just plain ngettext? (Emacs could then define ngettext in terms of
> dcngettext.)

It seems most of these needs could be covered by adding two optional
arguments DOMAIN and CATEGORY to ngettext (where the default domain
"emacs" will be hard-coded).

As a convenience not to require a package to add its domain to every
ngettext call, maybe when something like 'defdomain' is declared at the
beginning of the package, its value should affect the domain within
the package scope.

Re: Emacs i18n

[Paul Eggert]

On 3/26/19 4:16 PM, Juri Linkov wrote:

> I'll start writing documentation. Is it allowed to make references
> from the Elisp manual to the Gettext Info manual? I see in (info
> "(gettext) elisp-format") a reference back to the Elisp manual is a
> web link, not an Info reference.
>
Thanks for taking this on. Yes, you can do cross-references; e.g.,
files.texi has this:

@xref{File permissions,,, coreutils, The @sc{gnu} @code{Coreutils}
Manual}


> It seems most of these needs could be covered by adding two optional
> arguments DOMAIN and CATEGORY to ngettext (where the default domain
> "emacs" will be hard-coded).
>
This appears to be what CLISP does; see:

https://sourceforge.net/p/clisp/clisp/ci/default/tree/modules/i18n/i18n.lisp

https://clisp.sourceforge.io/impnotes.html#i18n-mod

> As a convenience not to require a package to add its domain to every
> ngettext call, maybe when something like 'defdomain' is declared at
> the beginning of the package, its value should affect the domain
> within the package scope.
>
Would this be done statically or dynamically? Preferably the former but
I don't exactly see how it would work, and even dynamically the details
are not obvious to me.

For example, would you have to do something like the following?

(define mymodule--ngettext (n sing-msgid pl-msgid) (ngettext n
sing-msgid pl-msgid "mymodule"))

(defun report-items (n) (message (mymodule--ngettext n "%d item" "%d
items") n))
(defun report-keystrokes (n) (message (mymodule--ngetext n "%d keystroke
received." "%d keystrokes received.") n))

Something like this would work, but it looks pretty annoying....

Re: Emacs i18n

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

So, where do we go from here now ?

Juri, have you written documentation ? Do you want help ?

Jean-Christophe

> On Mar 27, 2019, at 8:16, Juri Linkov <juri@linkov.net <mailto:juri@linkov.net>> wrote:
> 
>>> I don't know where to put i18n related code, so since ngettext should
>>> have C calls anyway, I moved it to editfns.c near the function ‘message’
>>> where it still just returns the correct plurals without doing any translation.
>> 
>> That stub had some problems:
>> 
>> 1. It lacked documentation in the Elisp manual. Important changes like
>> this should be documented -- to some extent the documentation is even
>> more important than the code. Can you write something?
> 
> I'll start writing documentation.  Is it allowed to make
> references from the Elisp manual to the Gettext Info manual?
> I see in (info "(gettext) elisp-format") a reference back to
> the Elisp manual is a web link, not an Info reference.
> 
>> 2. While you're thinking about (1) here are some other questions. How
>> will ngettext determine the message catalog? Is the catalog visible to
>> users as a global variable, or as a hidden part of the global state, or
>> is it something explicit? How will catalogs from multiple packages be
>> used? How would a multi-lingual application work in Emacs if the message
>> catalog is part of global state? This seems to be a crucial issue, I'd
>> say. For example, should Emacs export dcngettext to Lisp code, instead
>> of just plain ngettext? (Emacs could then define ngettext in terms of
>> dcngettext.)
> 
> It seems most of these needs could be covered by adding two optional
> arguments DOMAIN and CATEGORY to ngettext (where the default domain
> "emacs" will be hard-coded).
> 
> As a convenience not to require a package to add its domain to every
> ngettext call, maybe when something like 'defdomain' is declared at the
> beginning of the package, its value should affect the domain within
> the package scope.

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com <http://mac4translators.blogspot.com/> @brandelune



[-- Attachment #2: Type: text/html, Size: 4267 bytes --]

Re: Emacs i18n

[Juri Linkov]

> So, where do we go from here now ?
>
> Juri, have you written documentation ?

It's still WIP.  First I looked how i18n is implemented in XEmacs,
and discovered that whereas the interface is documented, it's
not fully functional.  What is worse, it's quite ugly.
So I turned onto a nicer interface in CLISP that could be
used as a basis of gettext interface in Emacs Lisp.

> Do you want help ?

Help is needed to install the standard gettext infrastructure
using gettextize.  Help is expected from someone who has more
experience in applying gettext to other projects.

Once the default gettext infrastructure is installed,
I could help in adapting gettext to Emacs.

Meanwhile, currently I'm replacing dired-plural-s with ngettext
in bug#35287.  It's not without problems: one problematic place
is in dired-do-kill-lines:

  (defun dired-do-kill-lines (&optional arg fmt)
    ...
    (let ((count 0))
      (setq count (1+ count))
      (or (equal "" fmt)
          (message (or fmt "Killed %d line%s.") count (dired-plural-s count)))
      count)

  (defun dired-omit-expunge (&optional regexp)
    ...
    (setq count (dired-do-kill-lines
                 nil
                 (if dired-omit-verbose "Omitted %d line%s." "")))

The format string can't be just replaced in dired-do-kill-lines with
something like

  (ngettext "Killed %d line." "Killed %d lines." count)

because it can be called with a format string from dired-omit-expunge,
but also dired-omit-expunge has no access to the variable 'count'.

There are more such marginal cases, but eventually they all
have to resolved somehow.

Re: Emacs i18n

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: cpitclaudel@gmail.com,  brandelune@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 24 Mar 2019 23:55:57 +0200
> 
> > But since we don't yet have ngettext, we cannot yet use this
> > paradigm.  I thought by "from now on" you literally meant from now;
> > did I misunderstand?
> 
> Yes, literally.  After the patch from
> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00586.html
> is pushed to master, ngettext is available to use for pluralization.

That's changing history.

Re: Emacs i18n

[Jean-Christophe Helary]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]



> On Mar 25, 2019, at 12:35, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Juri Linkov <juri@linkov.net>
>> Cc: cpitclaudel@gmail.com,  brandelune@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org
>> Date: Sun, 24 Mar 2019 23:55:57 +0200
>> 
>>> But since we don't yet have ngettext, we cannot yet use this
>>> paradigm.  I thought by "from now on" you literally meant from now;
>>> did I misunderstand?
>> 
>> Yes, literally.  After the patch from
>> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00586.html
>> is pushed to master, ngettext is available to use for pluralization.
> 
> That's changing history.

How do we practically use that ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune



[-- Attachment #2: Type: text/html, Size: 2835 bytes --]

Re: Emacs i18n

[Juri Linkov]

>> > But since we don't yet have ngettext, we cannot yet use this
>> > paradigm.  I thought by "from now on" you literally meant from now;
>> > did I misunderstand?
>>
>> Yes, literally.  After the patch from
>> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00586.html
>> is pushed to master, ngettext is available to use for pluralization.
>
> That's changing history.

When you asked to read past discussions, I did it, and among all opinions
the most encouraging were the wise words of François Pinard:

  "Yet, when it is affordable to do so, and to spare the overall effort,
   it is often a good thing to aim in directions which have less chance to
   lead into dead ends, from which we might later have to backtrack from.
   Yet, dead ends are not always technical, so sometimes, not always, dead
   ends might be more fruitful than no road at all.  It is surely a fine art,
   being able to choose the best roads, considering all issues.

   My opinion is, when we are lacking of volunteer time, that the best road is
   the one having the least steps in it, and this often means that backtracking
   should be avoided.  Best is trying to do things the right way, even if not
   everything gets done at once.  So steps accumulate constructively over time."

I hope that starting with a small step of adding ngettext to provide
the correct plurals for English words would lead in the right direction
while avoiding the danger of backtracking from dead ends.

Re: Emacs i18n

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: cpitclaudel@gmail.com,  brandelune@gmail.com,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 25 Mar 2019 23:02:59 +0200
> 
> I hope that starting with a small step of adding ngettext to provide
> the correct plurals for English words would lead in the right direction
> while avoiding the danger of backtracking from dead ends.

That's not what I meant.  I asked a question, and you replied as if
the commit done yesterday already existed before I asked the question.

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. ]]]

  > > I hope that starting with a small step of adding ngettext to provide
  > > the correct plurals for English words would lead in the right direction
  > > while avoiding the danger of backtracking from dead ends.

  > That's not what I meant.  I asked a question, and you replied as if
  > the commit done yesterday already existed before I asked the question.

It sounds like a minor miscommunication.  A short private conversation
might enable you to set it straight.

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

Re: Emacs i18n

[Mattias Engdegård]

24 mars 2019 kl. 22.55 skrev Juri Linkov <juri@linkov.net>:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00586.html
> is pushed to master, ngettext is available to use for pluralization.

That patch exposes some Emacs-specific translation problems:

-                 (cons (format "finished with %d matches found\n" 
grep-num-matches-found)
+                 (cons (format (ngettext "finished with %d match found\n"
+                                         "finished with %d matches found\n"
+                                         grep-num-matches-found)
+                               grep-num-matches-found)

This is fine -- typical i18n code (except that the subject of the sentence is missing, which should go into a comment to translators).

      ;; remove match from grep-regexp-alist before fontifying
      ("^Grep[/a-zA-Z]* started.*"
       (0 '(face nil compilation-message nil help-echo nil mouse-face nil) t))
-     ("^Grep[/a-zA-Z]* finished with \\(?:\\(\\(?:[0-9]+ \\)?matches 
found\\)\\|\\(no matches found\\)\\).*"
+     ("^Grep[/a-zA-Z]* finished with \\(?:\\(\\(?:[0-9]+ \\)?match\\(?:es\\)? 
found\\)\\|\\(no matches found\\)\\).*"

Since it is not uncommon in Emacs to pattern-match on generated text, either the translator needs to understand regexps well or the code must be restructured to avoid that kind of matching, perhaps by using text properties. Besides, translating regexp strings precludes the use of modern regexp notations like rx, since gettext is string-oriented.

Of course the patch was just a proof-of-concept and not intended as actual code. Please forgive me for using it to make a point.

This is also not an argument against using gettext. Quite the contrary; it's the obvious way to go if i18n is to be undertaken at all.

Re: Emacs i18n

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Mon, 25 Mar 2019 11:52:45 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, cpitclaudel@gmail.com, emacs-devel@gnu.org,
>         brandelune@gmail.com, rms@gnu.org
> 
> Of course the patch was just a proof-of-concept and not intended as actual code.

It's not proof-of-concept, it's an actual patch that was committed
yesterday night.

Re: Emacs i18n

[Juri Linkov]

> +                 (cons (format (ngettext "finished with %d match found\n"
> +                                         "finished with %d matches found\n"
> +                                         grep-num-matches-found)
> +                               grep-num-matches-found)
>
>       ("^Grep[/a-zA-Z]* started.*"
>        (0 '(face nil compilation-message nil help-echo nil mouse-face nil) t))
> -     ("^Grep[/a-zA-Z]* finished with \\(?:\\(\\(?:[0-9]+ \\)?matches 
> found\\)\\|\\(no matches found\\)\\).*"
> +     ("^Grep[/a-zA-Z]* finished with \\(?:\\(\\(?:[0-9]+ \\)?match\\(?:es\\)? 
> found\\)\\|\\(no matches found\\)\\).*"
>
> Since it is not uncommon in Emacs to pattern-match on generated text,
> either the translator needs to understand regexps well or the code
> must be restructured to avoid that kind of matching, perhaps by using
> text properties. Besides, translating regexp strings precludes the use
> of modern regexp notations like rx, since gettext is string-oriented.

Is it possible to generate a regexp from ngettext arguments?
For example, given the same arguments and calling a hypothetical
function ‘rx-ngettext’:

  (rx-ngettext "finished with %d match found\n"
               "finished with %d matches found\n")

to generate a regexp like:

  "finished with \\(?:\\(\\(?:[0-9]+ \\)?match\\(?:es\\)? found\\)"

Re: Emacs i18n

[Mattias Engdegård]

25 mars 2019 kl. 22.11 skrev Juri Linkov <juri@linkov.net>:
> 
> Is it possible to generate a regexp from ngettext arguments?
> For example, given the same arguments and calling a hypothetical
> function ‘rx-ngettext’:
> 
>  (rx-ngettext "finished with %d match found\n"
>               "finished with %d matches found\n")
> 
> to generate a regexp like:
> 
>  "finished with \\(?:\\(\\(?:[0-9]+ \\)?match\\(?:es\\)? found\\)"

Trivially so by generating an or-pattern: "singular text\\|plural text". Anything better is a matter of optimisation, basically a diff algorithm (or just prefix and suffix merging).

Is it practical, though? For %s, we would need to generate a match-anything subexpression, even though the argument is much more constrained in practice.

Re: Emacs i18n

[Juri Linkov]

>> Is it possible to generate a regexp from ngettext arguments?
>> For example, given the same arguments and calling a hypothetical
>> function ‘rx-ngettext’:
>>
>>  (rx-ngettext "finished with %d match found\n"
>>               "finished with %d matches found\n")
>>
>> to generate a regexp like:
>>
>>  "finished with \\(?:\\(\\(?:[0-9]+ \\)?match\\(?:es\\)? found\\)"
>
> Trivially so by generating an or-pattern: "singular text\\|plural text".
> Anything better is a matter of optimisation, basically a diff algorithm
> (or just prefix and suffix merging).
>
> Is it practical, though? For %s, we would need to generate a match-anything
> subexpression, even though the argument is much more constrained in practice.

I tried ‘regexp-opt’ and it generates a ready-to-use regexp:

  (replace-regexp-in-string
   "%d" "\\\\([0-9]+\\\\)"
   (regexp-opt '("finished with %d match found"
                 "finished with %d matches found"
                 "finished with no matches found")))

  ⇒ "\\(?:finished with \\(?:\\(?:\\([0-9]+\\) match\\(?:es\\)?\\|no matches\\) found\\)\\)"

Re: Emacs i18n

[Mattias Engdegård]

27 mars 2019 kl. 22.22 skrev Juri Linkov <juri@linkov.net>:
> 
> I tried ‘regexp-opt’ and it generates a ready-to-use regexp:
> 
>  (replace-regexp-in-string
>   "%d" "\\\\([0-9]+\\\\)"
>   (regexp-opt '("finished with %d match found"
>                 "finished with %d matches found"
>                 "finished with no matches found")))
> 
>  ⇒ "\\(?:finished with \\(?:\\(?:\\([0-9]+\\) match\\(?:es\\)?\\|no matches\\) found\\)\\)"

Well now. There is no guarantee that regexp-opt won't split the %d. Format strings must be parsed left-to-right for correctness¹. I'm still skeptical, but if you really want to give this a try, then first segment the format string:

"Today %d little piggies built %03o houses and said '%s'."
"Today %d little piggy built %o house and said '%s'."
=>
("Today " ?d " little piggies built " ?o " houses and said '" ?s "'.")
("Today " ?d " little piggy built " ?o " house and said '" ?s "'.")

leaving the format placeholders as atomic entities (here shown as characters, but you may need more information there).
Then run your fav diff algo on the result. Most important to performance is prefix merging; anything else is just to make the regexp smaller.

Here, prefix and suffix merging would leave you with (still in abstract form)

("Today " ?d " little pigg"
 (("ies built " ?o " houses")
  ("y built " ?o " house"))
 " and said '" ?s "'.")

From there you can either recursively try to find more common subsequences, or call it a day and render it into a regexp:

"Today -?[0-9]+ little pigg\\(?:ies built -?[0-7]+ houses\\|y built -?[0-7]+ house\\) and said '\\(?:.\\|\n\\)*'."

All this will need to be done at run-time, since it is run on translated strings.

¹ To match format parameters, try something like
  (rx "%"
      (opt (1+ digit) "$")
      (0+ digit)
      (opt "." (0+ digit))
      (any "%sdioxXefgcS"))

Re: Emacs i18n (was: bug#34520: delete-matching-lines should report how many lines it deleted)

[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. ]]]

  > This has come up several times in the past.  The main problem with
  > i18n in Emacs is that, unlike in many text-mode programs, 'message'
  > covers a tiny portion of the Emacs UI.  We have help commands that pop
  > up buffers; we have commands that prompt in the minibuffer; we have
  > menu items and labels on tool-bar buttons; we have help-echo on menus,

That is quite true.  However, I recommend a different approach to
doing the job.  An incremental one.

Let's install the lookup code and make `message' call it -- not using
advice.  Perhaps we should rewrite it into C, since it is short
and we will want to call it from C code.

Let's develop something to load translations from po files.  Let's
develop software to generate and write lists of messages that need
translating.

Then people can start developing useful sets of translations.

Meanwhile, we can also hook it into other interfaces where it
appropriate.

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

Re: Emacs i18n (was: bug#34520: delete-matching-lines should report how many lines it deleted)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> Date: Sun, 03 Mar 2019 22:27:36 -0500
> 
> That is quite true.  However, I recommend a different approach to
> doing the job.  An incremental one.
> 
> Let's install the lookup code and make `message' call it -- not using
> advice.  Perhaps we should rewrite it into C, since it is short
> and we will want to call it from C code.
> 
> Let's develop something to load translations from po files.  Let's
> develop software to generate and write lists of messages that need
> translating.
> 
> Then people can start developing useful sets of translations.
> 
> Meanwhile, we can also hook it into other interfaces where it
> appropriate.

The incremental approach is a great approach, but it does have its
limitations.  Especially when several non-trivial features will
eventually need to be compatible with each other to be true parts of a
greater whole, which is i18n for Emacs.

For example, it is IMO pointless to be able to display translated
strings from 'message' without also having a convenient automated way
of collecting translatable messages and creating a message catalog
that such a 'message' could use, or without being able to install
such message catalogs for different ELisp packages.

IOW, this feature, like many other large features, cannot be
implemented in increments that are too small.  Each increment should
be large enough to make sense.  And then there's a more complex issue
of how the increments will work together; some thought must be
invested in that up front.

Re: Emacs i18n (was: bug#34520: delete-matching-lines should report how many lines it deleted)

[Paul Eggert]

On 3/4/19 8:36 AM, Eli Zaretskii wrote:
> For example, it is IMO pointless to be able to display translated
> strings from 'message' without also having a convenient automated way
> of collecting translatable messages and creating a message catalog
> that such a 'message' could use

There is longstanding technology to do that for C code. We could apply
that to Emacs, and then at least the builtin C-level messages will be
translated. Later, we could extend this to Elisp.

Re: Emacs i18n (was: bug#34520: delete-matching-lines should report how many lines it deleted)

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, juri@linkov.net
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 4 Mar 2019 10:37:31 -0800
> 
> On 3/4/19 8:36 AM, Eli Zaretskii wrote:
> > For example, it is IMO pointless to be able to display translated
> > strings from 'message' without also having a convenient automated way
> > of collecting translatable messages and creating a message catalog
> > that such a 'message' could use
> 
> There is longstanding technology to do that for C code. We could apply
> that to Emacs, and then at least the builtin C-level messages will be
> translated. Later, we could extend this to Elisp.

I'm saying that IMO it makes no sense at all to do this only for C.
The infrastructure used for that will most probably not work for Lisp,
let alone allow separate translations for separate packages to be
brought together and used in the same Emacs session.

Re: Emacs i18n (was: bug#34520: delete-matching-lines should report how many lines it deleted)

[Paul Eggert]

On 3/4/19 11:07 AM, Eli Zaretskii wrote:
> I'm saying that IMO it makes no sense at all to do this only for C.

Yes, of course it should also work for Elisp. I mentioned C only as a
way to get it started, since the C infrastructure already exists and we
need to do it for the C messages anyway.

> The infrastructure used for that will most probably not work for Lisp,
> let alone allow separate translations for separate packages to be
> brought together and used in the same Emacs session.

I don't see why it wouldn't work for Elisp. The gettext infrastructure
allows multiple message catalogs in the same session. Obviously some
hacking would be involved, since Elisp currently doesn't do any of this;
but it could be built atop the existing infrastructure used by other GNU
applications rather than being rewritten from scratch.

Re: Emacs i18n

[Juri Linkov]

>> The infrastructure used for that will most probably not work for Lisp,
>> let alone allow separate translations for separate packages to be
>> brought together and used in the same Emacs session.
>
> I don't see why it wouldn't work for Elisp. The gettext infrastructure
> allows multiple message catalogs in the same session. Obviously some
> hacking would be involved, since Elisp currently doesn't do any of this;
> but it could be built atop the existing infrastructure used by other GNU
> applications rather than being rewritten from scratch.

One of the main decisions that has to be made is whether to wrap all
user-facing translatable strings in all Lisp files using a macro/function
'gettext' (alias '_') explicitly like is implemented in XEmacs' I18N3
that would help to extract translations from the source code, or to use
a low-level implicit translation without changing the existing code like
is implemented for handling text-quoting-style in format strings.
The latter will even allow translation of strings that a package author
forgot to mark with '_'.

Depending on this decision a translation file format has to be selected,
be it flat Gettext PO format files or even some YAML-like hierarchical
Lisp structures with scopes.

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. ]]]

  > One of the main decisions that has to be made is whether to wrap all
  > user-facing translatable strings in all Lisp files using a macro/function
  > 'gettext' (alias '_') explicitly like is implemented in XEmacs' I18N3
  > that would help to extract translations from the source code, or to use
  > a low-level implicit translation without changing the existing code like
  > is implemented for handling text-quoting-style in format strings.
  > The latter will even allow translation of strings that a package author
  > forgot to mark with '_'.

We could recognize all strings passed as certain arguments to certain
functions as translatable automatically, and have an explicit
way to mark other strings as translatable.  That could reduce
the amount of work for developers to mark them.

The translatability could be recorded as a text property in the
string.  Then, if a function such as 'message' gets a format string
that is not translatable, it could warn, or save up a record that
developers could optionally look at later.  This would help remind
developers to mark the strings that need it.



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

Re: Emacs i18n

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eggert@cs.ucla.edu, eliz@gnu.org, emacs-devel@gnu.org
> Date: Tue, 05 Mar 2019 21:16:07 -0500
> 
> We could recognize all strings passed as certain arguments to certain
> functions as translatable automatically, and have an explicit
> way to mark other strings as translatable.  That could reduce
> the amount of work for developers to mark them.

You mean, the function, such as 'message', that receives the string
will translate it?  As opposed to the alternative of translating the
string _before_ it gets passed to the function?

If we do that, how do we deal with strings that are computed by
concatenation or formatting?  They get in one piece to functions like
'message', but the catalog will not hold that concatenated string, it
will have the parts separately.  How will the function be able to look
up the translation in such cases?

Re: Emacs i18n

[Paul Eggert]

On 3/6/19 10:15 AM, Eli Zaretskii wrote:

> how do we deal with strings that are computed by concatenation or
> formatting?
>
The same way that other GNU packages deal with them: we redo calls, to
make the strings easier to translate. For example, instead of this code
(adapted from todo-mode.el):

  (message (concat "The highlighted item" (if (= count 1) " is " "s
precedes ")
                   "the timestamp %s.")
           timestamp)

we do something like this:

  (nmessage count
            "The highlighted item is not up to date."
            "The highlighted items are not up to date."
            timestamp)

where (nmessage N FMT1 FMT2 ...) is a new function that mimics GNU
ngettext by returning a translation of FMT1 (using N) if a translation
is available, and if no translation is available it falls back on using
FMT1 if N is 1 and FMT2 otherwise.

It's inevitable that we'd need to redo Lisp code this way, as
translators cannot be expected to be programming experts that understand
arbitrary Lisp code involving 'concat' and whatnot. This is what other
GNU packages have done, and Emacs can do something similar.

Of course it will be a big task to fully internationalize in this way,
and it's not something that can be done all at once. But it doesn't have
to be done all at once: we can create the machinery, do some proper i18n
of a few key Lisp modules, and let the other modules be fixed up later
when people find time.

Re: Emacs i18n

[Eli Zaretskii]

> Cc: juri@linkov.net, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 6 Mar 2019 11:47:23 -0800
> 
> On 3/6/19 10:15 AM, Eli Zaretskii wrote:
> 
> > how do we deal with strings that are computed by concatenation or
> > formatting?
> >
> The same way that other GNU packages deal with them: we redo calls, to
> make the strings easier to translate. For example, instead of this code
> (adapted from todo-mode.el):
> 
>   (message (concat "The highlighted item" (if (= count 1) " is " "s
> precedes ")
>                    "the timestamp %s.")
>            timestamp)
> 
> we do something like this:
> 
>   (nmessage count
>             "The highlighted item is not up to date."
>             "The highlighted items are not up to date."
>             timestamp)

That's the easy case.  This one is a bit tougher:

  (message "The program says: " (shell-command-to-string "foo"))

> It's inevitable that we'd need to redo Lisp code this way, as
> translators cannot be expected to be programming experts that understand
> arbitrary Lisp code involving 'concat' and whatnot. This is what other
> GNU packages have done, and Emacs can do something similar.

Except that Emacs is so much larger that doing this "like other
packages" might make the job infeasible.

Which is one reason why I think we should start from doc strings: they
are both easier and much more important.

Re: Emacs i18n

[Paul Eggert]

On 3/6/19 12:19 PM, Eli Zaretskii wrote:

>
> That's the easy case. This one is a bit tougher: (message "The program
> says: " (shell-command-to-string "foo"))
>
Assuming you meant this:

  (message (concat "The program says: " (shell-command-to-string "foo")))

then it shouldn't be tough at all. The Elisp code should be rewritten
like this:

   (message "The program says: %s" (shell-command-to-string "foo"))

xgettext will automatically put "The program says: %s" into the pool of
translatable strings. The output of the "foo" command won't be
translated, nor should it be.

Anyway, the Elisp code with "concat" needs to be rewritten regardless of
whether we do i18n, as it can throw an exception if the shell command's
output contains "%".

All this is routine for program internationalization. Emacs is not
special here; we've often had to do this sort of thing for other GNU
packages.

Re: Emacs i18n

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 6 Mar 2019 17:52:05 -0800
> Cc: emacs-devel@gnu.org, rms@gnu.org, juri@linkov.net
> 
> then it shouldn't be tough at all. The Elisp code should be rewritten
> like this:
> 
>    (message "The program says: %s" (shell-command-to-string "foo"))
> 
> xgettext will automatically put "The program says: %s" into the pool of
> translatable strings. The output of the "foo" command won't be
> translated, nor should it be.
> 
> Anyway, the Elisp code with "concat" needs to be rewritten regardless of
> whether we do i18n, as it can throw an exception if the shell command's
> output contains "%".
> 
> All this is routine for program internationalization. Emacs is not
> special here; we've often had to do this sort of thing for other GNU
> packages.

Sure, except that Emacs is so much larger, and gives the programmer a
lot more freedom with treating code and data alike, than a typical C
program.  I just want people to realize how this job is more
complicated in Emacs than in any other program.  E.g., IIUC what you
say, we will need to rewrite also the likes of this:

  (let* ((field (get-char-property pos 'field))
	 (button (get-char-property pos 'button))
	 (doc (get-char-property pos 'widget-doc))
	 (text (cond (field "This is an editable text area.")
		     (button "This is an active area.")
		     (doc "This is documentation text.")
		     (t "This is unidentified text.")))
	 (widget (or field button doc)))
    (when widget
      (widget-browse widget))
    (message text)))

And this is just a random, and not the most complicated, example.

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. ]]]

    > (let* ((field (get-char-property pos 'field))
    > 	 (button (get-char-property pos 'button))
    > 	 (doc (get-char-property pos 'widget-doc))
    > 	 (text (cond (field "This is an editable text area.")
    > 		     (button "This is an active area.")
    > 		     (doc "This is documentation text.")
    > 		     (t "This is unidentified text.")))
    > 	 (widget (or field button doc)))
    >   (when widget
    >     (widget-browse widget))
    >   (message text)))

We would need to make SOME sort of change in it, but change could be
very simple.  It could consist of writing a call to 'translate' around
each of those string constants.

Or we might adopt a reader syntax for translatable strings.
That might be convenient, since we want these to be found
by tools processing the code, not solely handled by
executing the code.

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

Re: Emacs i18n

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org, juri@linkov.net
> Date: Thu, 07 Mar 2019 23:07:20 -0500
> 
> Or we might adopt a reader syntax for translatable strings.
> That might be convenient, since we want these to be found
> by tools processing the code, not solely handled by
> executing the code.

I think we will need to come up with such a syntax anyway, because we
will want to leave the Lisp programmers the freedom of writing code
that computes displayable text out of thin air.

It doesn't have to be reader syntax, btw: it could be a special
function.

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. ]]]

  > we do something like this:

  >   (nmessage count
  >             "The highlighted item is not up to date."
  >             "The highlighted items are not up to date."
  >             timestamp)

It might be better to define a function like this

(defun numeric-select (count &rest messages)
  (or (nth count messages)
      (car (last messages))))

and then write

 (message (numeric-select count
 	       "The highlighted item is not up to date."
	        "The highlighted items are not up to date."))

Translation infrastructure might be able to recognize this construct
and mark the two strings as translatable if they are constants.

Even better, translation could allow replacing that list of messages
with a different list of messages, perhaps longer.   That would
make possible perfect support for a language where you need a different
text for 2 and for numbers larger than 2.

We could decide that the first element is for COUNT = 0,
and if that element is a number instead of a string, it means
to use the element for that number.

  (message (numeric-select count
  	         2
   	         "The highlighted item is not up to date."
	         "The highlighted items are not up to date."))

This, together with the feature of translating the list
as a different list, could be totally general.


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

Re: Emacs i18n

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

On Fri, 8 Mar 2019 at 12:08, Richard Stallman <rms@gnu.org> wrote:

Even better, translation could allow replacing that list of messages
> with a different list of messages, perhaps longer.   That would
> make possible perfect support for a language where you need a different
> text for 2 and for numbers larger than 2.


Russian, for example, uses three different grammatical cases, which are
dependent on the last digit of the number, the system needs to be more
complicated.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 837 bytes --]

Re: Emacs i18n

[Eli Zaretskii]

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Fri, 8 Mar 2019 12:33:24 +0800
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Eli Zaretskii <eliz@gnu.org>, Juri Linkov <juri@linkov.net>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> Russian, for example, uses three different grammatical cases, which are dependent on the last digit of the
> number, the system needs to be more complicated.

It's more complicated than that (e.g., 21 and 11 produce different
forms in Russian), but gettext already has infrastructure for all
that, AFAIR.

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. ]]]

  > Russian, for example, uses three different grammatical cases, which are
  > dependent on the last digit of the number, the system needs to be more
  > complicated.

Here's an idea for a scheme general enough to handle Russian as well.
I propose something like a case or select construct.
First, the elegant Lispy way to represent it:

  (numeric-case NUMBER
      (1 "Just one frob")
      (2 "Two frobs")
      (russian-masc "%d-m frobs")
      (russian-fem "%d-f frobs")
      (russian-neut "%d-n frobs")
      (t "%d frobs"))

Translation would have to the entire numeric-case construct
with another (translated) numeric-case construct.  Thus, the source
code would contain one suitable for English:

  (numeric-case NUMBER
      (1 "one frob")
      (t "%d frobs"))

and for Russian we would translate it into this one

  (numeric-case NUMBER
      (russian-masc "%d-m frobs")
      (russian-fem "%d-f frobs")
      (russian-neut "%d-n frobs"))

I think this framework could be extended to handle
whatever other weird grammatical rules we might encounter in other languages
in the future.

While doing it with Lisp syntax is elegant, it would require
generalization of the infrastructure for recording translations to
handle more than strings.   That would be a pain.

Here's a way to represent the conditional construct as a kind of
string.  That way, translation would only need to translate strings
into strings.

We could use | in the string to separate alternatives, and : to end
a condition.  It would look like this:

  (numeric-case NUMBER
    "1:one frob|\
     t:%d frobs")

For Russian, we would translate the source string

  1:one frob|t:%d frobs

into

  russian-masc:%d-m frobs|russian-fem:%d-f frobs|russian-neut:%d-n frobs

The subsequences : and | would be handled by the function numeric-case.
They would not affect the meaning of the string data type as such.
numeric-case would ignore whitespace after |.

With this string convention, we only need to translate strings.

To include a | in an alternative, you could write a double |.
We do not need a way to quote a colon.

Perhaps one could develop a smarter 'russian' alternative
that knows how to change the last letter automatically and handles
all three alternatives.


Maybe we need to define a format-spec for devouring and ignoring one argument.

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

Re: Emacs i18n

[Paul Eggert]

Richard Stallman wrote:
> Here's an idea for a scheme general enough to handle Russian as well.

That idea's use of "-masc", "-fem", and "-neut" suggests that you misunderstood 
the problem with translating format strings like "%d items" into Russian.

Russian has three plural forms useful for translating a string that formats an 
integer N. One form is for when (N%10 == 1 && N%100/10 != 1), one is for when (2 
<= N%10 && N%10 <= 4 && N%100/10 == 1), and one is for everything else. So the 
form depends on N, not on whether the translation of the word "items" is 
masculine or feminine or whatever. Other languages have other rules, with 
varying levels of complexity; for example, Arabic has six different plural forms.

GNU gettext deals with this at the translation level, so that ordinary programs 
can just use a function like ngettext to translate an English-language format 
with two plural forms. Emacs Lisp should do something similar: we shouldn't try 
to reinvent this wheel.

Here's an example, taken from GNU dd. The C source code contains the two English 
forms and looks something like this:

          fprintf (stderr,
                   ngettext ("%"PRIuMAX" byte copied, %s, %s",
                             "%"PRIuMAX" bytes copied, %s, %s",
                             w_bytes),
                   w_bytes, delta_s_buf, bytes_per_second);

And the ru.po file (which Russian translators edit) looks like this:

"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 
&& (n%100<10 || n%100>=20) ? 1 : 2);\n"
...
#: src/dd.c:822
#, c-format
msgid "%<PRIuMAX> byte copied, %s, %s"
msgid_plural "%<PRIuMAX> bytes copied, %s, %s"
msgstr[0] "%<PRIuMAX> байт скопирован, %s, %s"
msgstr[1] "%<PRIuMAX> байта скопировано, %s, %s"
msgstr[2] "%<PRIuMAX> байт скопировано, %s, %s"

Each of the three Russian plural forms is supported, and the right one is chosen 
by the translation system without the programmer having to know how Russian 
plural forms work. For more about this, please see the GNU gettext manual, such 
as this web page:

https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html


PS. Although the email from Elias said "From: =?UTF-8?Q?Elias_M=C3=A5rtenson?=" 
which displays correctly as "Elias Mårtenson", your reply said "To: Elias 
=?iso-8859-1?Q?M=C3=A5rtenson?=" which displays incorrectly as "Elias 
MÃ¥rtenson". It looks like there's a bug in your email client, or in your 
configuration of it, a bug that munges names of your email correspondents.

Re: Emacs i18n

[Eli Zaretskii]

> Cc: Elias Mårtenson <lokedhs@gmail.com>, eliz@gnu.org,
>  juri@linkov.net, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 8 Mar 2019 23:54:28 -0800
> 
> So the form depends on N, not on whether the translation of the word
> "items" is masculine or feminine or whatever.

It actually depends on both.

> GNU gettext deals with this at the translation level, so that ordinary programs 
> can just use a function like ngettext to translate an English-language format 
> with two plural forms. Emacs Lisp should do something similar: we shouldn't try 
> to reinvent this wheel.

Right.

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. ]]]

  > Russian has three plural forms useful for translating a string that formats an 
  > integer N. One form is for when (N%10 == 1 && N%100/10 != 1), one is for when (2 
  > <= N%10 && N%10 <= 4 && N%100/10 == 1), and one is for everything else. So the 
  > form depends on N, not on whether the translation of the word "items" is 
  > masculine or feminine or whatever.

That's how I understood it, and that is exactly what my proposal does.

I will try to explain it again.

Each clause inside numeric-select handles certain numbers.
The car of the clause (in Lispy structure) selects numbers
to handle.

'russian-masc' selects numbers that require a masculine ending, in
Russian.  You use it with a string that contains the masculine ending.

'russian-fem' selects numbers that require a feminine ending, in
Russian.  You use it with a string that contains the feminine ending.

'russian-neut' selects numbers that require a neuter ending, in
Russian.  You use it with a string that contains the neuter ending.

If this does not work, why not?

In the example that was sent, I see code that tests for certain kinds
of numbers.  But since I don't know the language that that is written
in, the mathematical conditions are the only part I understand.  I
don't see what it will _do_ in each of those conditions.  I presume it
selects the appropriate suffix for the number, but I don't follow how
it does so.

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

Re: Emacs i18n

[Paul Eggert]

Richard Stallman wrote:

> If this does not work, why not?

Thanks for explaining the -masc, -fem, -neut part. I'm afraid, though, that I 
still don't fully understand the proposal. It sounds like it is a redesign of 
what GNU gettext does, but I don't see any advantage over GNU gettext.

> In the example that was sent, I see code that tests for certain kinds
> of numbers.  But since I don't know the language that that is written
> in, the mathematical conditions are the only part I understand.  I
> don't see what it will _do_ in each of those conditions.  I presume it
> selects the appropriate suffix for the number, but I don't follow how
> it does so.

The GNU gettext translation code doesn't know anything about suffixes. All it 
knows is that if n%10==1 && n%100!=11 then it should use msgstr[0], else if 
n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) then it should use msgstr[1], else 
it should use msgstr[2]. The translations themselves are string formats that 
already have the proper suffixes, and GNU gettext simply copies those suffixes.

This is a simple scheme that does not attempt to solve the problem of generating 
idiomatic phrases for numbers (e.g., "twenty-four bytes" in English, "двадцать 
четыре байта" in Russian). All it solves is the problem of generating phrases 
containing numerals (e.g., "24 bytes" in English, "23 байта" in Russian), as 
these are the sorts of phrases that printf formats can generate. In practice, 
this is good enough.

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. ]]]

  > Thanks for explaining the -masc, -fem, -neut part. I'm afraid, though, that I 
  > still don't fully understand the proposal. It sounds like it is a redesign of 
  > what GNU gettext does, but I don't see any advantage over GNU gettext.

The advantage -- which is a big one -- is that the way the translation
is represented is much cleaner.  Compare this

  (numeric-case NUMBER
      (russian-masc "%d байт скопирован, %s, %s")
      (russian-fem "%d байта скопировано, %s, %s")
      (russian-neut "%d байт скопировано, %s, %s"))

(I have filled in strings for the real example you sent.  Since I
don't speak Russian, I was unable to write one myself, and it would
have taken me hours to find one.)

or this:

      "russian-masc:%d байт скопирован, %s, %s|\
       russian-fem:%d байта скопировано, %s, %s|\
       russian-neut:%d байт скопировано, %s, %s"

with this:

    "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 
    && (n%100<10 || n%100>=20) ? 1 : 2);\n"
    ...
    #: src/dd.c:822
    #, c-format
    msgid "%<PRIuMAX> byte copied, %s, %s"
    msgid_plural "%<PRIuMAX> bytes copied, %s, %s"
    msgstr[0] "%<PRIuMAX> байт скопирован, %s, %s"
    msgstr[1] "%<PRIuMAX> байта скопировано, %s, %s"
    msgstr[2] "%<PRIuMAX> байт скопировано, %s, %s"


If the selector symbol can modify the string too,
I can envision something like this:

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

where the 'russian-nom' operator would replace the two %| sequences
with the appropriate declensional suffixes for the nominative case.

Building that sort of thing into gettext would be bad architecture.
Gettext is too low level, and used in too many places.

Making Emacs handle 'russian-nom' in a string it pulls out of gettext
would be no problem at all.

  > This is a simple scheme that does not attempt to solve the problem of generating 
  > idiomatic phrases for numbers (e.g., "twenty-four bytes" in English,

I agree we don't need to do this.  But, with the mechanism I've just
proposed, it would be easy to do, so I suppose we would implement it.

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

Re: Emacs i18n

[Paul Eggert]

Richard Stallman wrote:
> Compare this
> 
>    (numeric-case NUMBER
>        (russian-masc "%d байт скопирован, %s, %s")
>        (russian-fem "%d байта скопировано, %s, %s")
>        (russian-neut "%d байт скопировано, %s, %s"))
> 
> with this:
> 
>      "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4
>      && (n%100<10 || n%100>=20) ? 1 : 2);\n"
>      ...
>      #: src/dd.c:822
>      #, c-format
>      msgid "%<PRIuMAX> byte copied, %s, %s"
>      msgid_plural "%<PRIuMAX> bytes copied, %s, %s"
>      msgstr[0] "%<PRIuMAX> байт скопирован, %s, %s"
>      msgstr[1] "%<PRIuMAX> байта скопировано, %s, %s"
>      msgstr[2] "%<PRIuMAX> байт скопировано, %s, %s"

I'm afraid that's not a apples-to-apples comparison. The first form contains 
only the Russian translations, whereas the second form contains much more 
information: the source-code location of the untranslated strings, a copy of the 
untranslated English-language strings, and the general rules for Russian (the 
last is shared among all the Russian translations, not just the translations 
listed here). This extra information is useful for translators, and it has a 
reasonably extensive software suite that already supports it, not to mention 
translators who are already used to it.

> I can envision something like this:
> 
>        "russian-nom:%d байт%| скопирован%|, %s, %s"
> 
> where the 'russian-nom' operator would replace the two %| sequences
> with the appropriate declensional suffixes for the nominative case.

But Russian declension is not that simple. The Russian word for "byte" is 
"байт", but its plural form depends not only on the number (as in the above 
examples) but also in its case: the "байт" and "байта" in the above examples are 
not exhaustive. And some words have irregular declensions: for example, ребёнок 
(singular) versus де́ти (plural) for the same noun. And it's not just nouns and 
pronouns that are affected: adjectives also have singular and plural forms. And 
I have by no means exhausted the issues involved here; to get a better feeling 
for the complexity in this area, please see:

https://en.wikipedia.org/wiki/Russian_declension

Although it wouldn't be impossible for Emacs Lisp code to handle all the special 
cases for Russian declension, it would be tricky to implement, or to document it 
in a way that translators would easily understand. And we'd also have to 
implement and document similarly tricky rules for other languages. And we'd have 
to deal with the fact that not every Russian-speaker agrees with how to decline 
words like "байт" that are imported from English. These sorts of issues should 
be delegated to translators, not to likely-fragile code in Emacs Lisp (a 
technology that translators typically do not grok).

In contrast, the gettext way is relatively simple and easily understood, and is 
already common practice.

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. ]]]

  > > I can envision something like this:
  > > 
  > >        "russian-nom:%d байт%| скопирован%|, %s, %s"
  > > 
  > > where the 'russian-nom' operator would replace the two %| sequences
  > > with the appropriate declensional suffixes for the nominative case.

  > But Russian declension is not that simple. The Russian word for "byte" is 
  > "байт", but its plural form depends not only on the number (as in the above 
  > examples) but also in its case:

Yes, of course.  I anticipated that.  That is why I called the
construct 'russian-nom', and specified that it provides "the
appropriate declensional suffixes for the nominative case."

We could define similar constructs for some of the other cases in
Russian, whichever ones translators would want to use.

    the "байт" and "байта" in the above examples are 
    not exhaustive.

No problem.  Nobody supposed that they were.  

		    And some words have irregular declensions:

I anticipated that, too.  The low-level forms 'russian-masc' and
friends can handle all such situations.  In them you can specify the
precise conjugated forms for the irregular words in the message.

  > nd it's not just nouns and 
  > pronouns that are affected: adjectives also have singular and plural forms.

'russian-masc' and friends allow explicit conjugation of any parts of
speech.

  >  And we'd have 
  > to deal with the fact that not every Russian-speaker agrees with how to decline 
  > words like "байт" that are imported from English.

The translator is always welcome to use the low-level constructs
'russian-masc' and friends, to exercise explicit control over that.

  > I have by no means exhausted the issues involved here; to get a better feeling 
  > for the complexity in this area, please see:

  > https://en.wikipedia.org/wiki/Russian_declension

I don't need to understand all the details of Russian numbers.  I've
designed a method so flexible that it can handle any such
complexities.

  > And we'd also have to 
  > implement and document similarly tricky rules for other languages.

No, we don't.  With my approach, we don't _have to_ implement any of
these specific solutions.  We can implement whichever ones we like.

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

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. ]]]

  > I'm afraid that's not a apples-to-apples comparison.

It doesn't need to be.

							 The first form contains 
  > only the Russian translations, whereas the second form contains much more 
  > information: the source-code location of the untranslated strings, a copy of the 
  > untranslated English-language strings, and the general rules for Russian (the 
  > last is shared among all the Russian translations, not just the translations 
  > listed here).

I can't draw any conclusions about the translation data you sent.  It
is in a format I have never seen and you have not explained it.
So I don't try to understand it.

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

Re: Emacs i18n

[Yuri Khan]

On Sun, Mar 10, 2019 at 10:06 AM Richard Stallman <rms@gnu.org> wrote:

> 'russian-neut' selects numbers that require a neuter ending, in
> Russian.  You use it with a string that contains the neuter ending.
>
> If this does not work, why not?

You are conflating three grammatical categories: the number, the
gender, and the declension type.

Gender and declension type are attributes of the noun, and are fixed
with respect to the noun. So if your message is about bytes, your
translator knows to use noun endings according to declension type 1a
and verb endings for masculine gender; there is nothing left for the
machine to guess. (Gender of the noun also affects the form of the
numeral if it is spelled out, but for computer-generated messages we
usually do not do that and just use digits.)

Number depends on the numeral’s value and affects the forms of the
noun, and any adjectives and verbs attached to it. Singular number
applies to values than end in 1, except for values that end in 11.
Dual number applies to values that end in 2..4, again, except for
values that end in 12..14. Plural number applies to everything else.
Any grammatical number can apply to any noun, so the translator will
provide all three wordings and let the machine select one using the
above logic.

Your example would work if you changed -masc, -fem and -neut to -sing,
-dual and -pl. But that is, as Paul mentioned, reinventing
ngettext(3).

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. ]]]

  > Russian has three plural forms useful for translating a string that formats an 
  > integer N. One form is for when (N%10 == 1 && N%100/10 != 1), one is for when (2 
  > <= N%10 && N%10 <= 4 && N%100/10 == 1), and one is for everything else. So the 
  > form depends on N, not on whether the translation of the word "items" is 
  > masculine or feminine or whatever.

I know that.  That is the problem I addressed.

Each clause inside numeric-select tests for and handles certain numbers.
The first thing in the clause is a condition that tests the number.
If the condition is a number, it matches only that number.

'russian-masc' tests for numbers that require a masculine noun ending;
you use it with a string that contains the masculine ending.

'russian-fem' tests for numbers that require a feminine noun ending.
you use it with a string that contains the feminine ending.

'russian-neut' tests for numbers that require a neuter noun ending.
you use it with a string that contains the neuter ending.

Since I do not speak Russian, I wrote dummies for those endings:
-m, -f and -n.

Thus,

  (numeric-case NUMBER
      (russian-masc "%d-m frobs")
      (russian-fem "%d-f frobs")
      (russian-neut "%d-n frobs"))

Do you follow, now?

  > "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 
  > && (n%100<10 || n%100>=20) ? 1 : 2);\n"
  > ...
  > #: src/dd.c:822
  > #, c-format
  > msgid "%<PRIuMAX> byte copied, %s, %s"
  > msgid_plural "%<PRIuMAX> bytes copied, %s, %s"

It would be better if we can define these criteria just once, rather
than restate them in many places.  My idea is to incorporate it
into the definition of the conditionals, russian-masc etc.

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

Re: Emacs i18n

[Paul Eggert]

Richard Stallman wrote:
>    > "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4
>    > && (n%100<10 || n%100>=20) ? 1 : 2);\n"
> 
> It would be better if we can define these criteria just once, rather
> than restate them in many places.

The criteria are stated just once per translation catalog. For example, the 
"Plural-forms:" line appears just once in the Russian translation catalog for 
coreutils. The criteria need not be repeated for each translated message.

If Emacs ends up having dozens or hundreds of message catalogs, it may be worth 
looking into maintaining just one copy of the Russian criteria, rather than once 
per Russian translation catalog. I hope we don't go that route, though.

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. ]]]

  > which displays correctly as "Elias Mårtenson", your reply said "To: Elias 
  > =?iso-8859-1?Q?M=C3=A5rtenson?=" which displays incorrectly as "Elias 
  > MÃ¥rtenson". It looks like there's a bug in your email client, or in your 
  > configuration of it, a bug that munges names of your email correspondents.

Indeed, it is a bug.  Maybe someday I can fix it.

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

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. ]]]

  > You mean, the function, such as 'message', that receives the string
  > will translate it?  As opposed to the alternative of translating the
  > string _before_ it gets passed to the function?

Yes, of course.

  > If we do that, how do we deal with strings that are computed by
  > concatenation or formatting?

Feed them in through %s or something like that.

I'm proposing the convention that the first argument to 'message' gets
by default translated, and other arguments don't.  With this
convention, whichever result you want, it is clear how to get it.

We already do things basically this way, because if you want to
compute a string to be the message, you don't want % to be treated
specially in it.  So you use "%s" as the first argument and pas that
string as the second.

So I think this will require only occasional changes
and they won't be urgent.

  >   They get in one piece to functions like
  > 'message', but the catalog will not hold that concatenated string, it
  > will have the parts separately.

That would happen if the catalog is made ONLY by scanning the source.
That's why I suggested a feature to record whatever nontrivial format
strings are passed to 'message' and are not in the catalog.

Then you can add them to the catalog, or fix things some other way.

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

Re: Emacs i18n

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org, juri@linkov.net
> Date: Wed, 06 Mar 2019 22:42:06 -0500
> 
>   > If we do that, how do we deal with strings that are computed by
>   > concatenation or formatting?
> 
> Feed them in through %s or something like that.

But then the strings that are formatted via %s will not be translated,
they will remain in English.

> I'm proposing the convention that the first argument to 'message' gets
> by default translated, and other arguments don't.  With this
> convention, whichever result you want, it is clear how to get it.
> 
> We already do things basically this way, because if you want to
> compute a string to be the message, you don't want % to be treated
> specially in it.  So you use "%s" as the first argument and pas that
> string as the second.

For the point I'm trying to make, it is immaterial whether the first
argument is "%s" and the second argument is computed from several
sources, or the first argument is that computed string.  The problems
that follow are the same.

>   >   They get in one piece to functions like
>   > 'message', but the catalog will not hold that concatenated string, it
>   > will have the parts separately.
> 
> That would happen if the catalog is made ONLY by scanning the source.
> That's why I suggested a feature to record whatever nontrivial format
> strings are passed to 'message' and are not in the catalog.

Such a feature will only help when a given call to 'message' produce a
small number of fixed text strings.  If the text it produces includes
some non-deterministic ingredient, this method will not help.

Re: Emacs i18n

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 3615 bytes --]

On 3/7/19 6:46 AM, Eli Zaretskii wrote:

>> From: Richard Stallman <rms@gnu.org> Cc: eggert@cs.ucla.edu,
>> emacs-devel@gnu.org, juri@linkov.net Date: Wed, 06 Mar 2019 22:42:06
>> -0500 > If we do that, how do we deal with strings that are computed
>> by > concatenation or formatting? Feed them in through %s or
>> something like that.
>>
> But then the strings that are formatted via %s will not be translated,
> they will remain in English.
>
Yes, but the scenario you describe should not occur in a properly
internationalized GNU application. We obviously can't assume that
Emacs's translation subroutine acts like Google Translate and can
translate any English-language string to the user's language. All we can
assume is that the translation subroutine converts one of a fixed set of
English-language strings to a string appropriate for the user's language.

This limitation will cause problems with Elisp code that does extensive
parsing or processing of English syntax (doctor.el, say), and that sort
of Elisp code will remain English-only (unless someone takes the time to
i18nize them specially). However most Elisp code does not parse English
or generate idiomatic English on the fly: instead, it uses a fixed,
stilted style that can routinely be converted to calls like (message
FORMAT ARG1 ARG2 ...) where FORMAT is translated and the ARG values are not.

To get a quick feel for this issue, I did a simple grep for the string
'(message (concat' in the Emacs source code. I found 41 instances of
this string. Of these, 8 were erroneous because the result of the
concatenation could contain an unwanted "%" or '`' that could cause
'message' to go awry, and I fixed them by installing the attached patch
(by the way, it's routine for i18n efforts to find trivial bugs like
this). The other 33 instances could easily be reworded to do proper i18n
when 'message' translates just its first argument and only simple,
xgettext-style static analysis is used to find the message strings. For
example, this code in calc-do-embedded:

  (message (concat
            "Embedded Calc mode enabled; "
            (if calc-embedded-quiet
                "Type `C-x * x'"
              "Give this command again")
            " to return to normal"))

can easily be rewritten to this:

   (if calc-embedded-quiet
       "Embedded Calc mode enabled; Type `C-x * x' to return to normal"
     "Embedded Calc mode enabled; Give this command again to return to
normal"))

which is easier for translators to grok, and is arguably clearer even if
we don't want to translate at all.Obviously my '(message (concat'
exercises only a small part of the problem, but the results of this
little sample are encouraging.

So this problem is solvable. Sure, it'll require substantial work, but
the work is routine and this sort of thing has been done for other packages.

The main argument against doing all this is that it's too much work
overall and nobody will have the time to do it all, so let's not even
bother. I have some sympathy for this argument, as i18n is clearly too
much work for any single contributor and the work will distract us from
other things. On the other hand, there's no pressing need to do all the
work quickly, it's a low-level task that can be farmed out to non-expert
volunteers that could conceivably grow the volunteer population, and if
we never even start the work then it will never get done and Emacs will
remain unfriendly to users who don't grok English.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Be-safer-about-in-message-formats.patch --]
[-- Type: text/x-patch; name="0001-Be-safer-about-in-message-formats.patch", Size: 7751 bytes --]

From f15d0d0247ffe7bc3bbd5fbe10271c93b2e2fb1c Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 7 Mar 2019 09:02:15 -0800
Subject: [PATCH] Be safer about "%" in message formats
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/calc/calc-store.el (calc-copy-special-constant):
* lisp/net/rcirc.el (rcirc-handler-PART, rcirc-handler-KICK):
* lisp/org/org-agenda.el (org-agenda):
* lisp/org/org-clock.el (org-clock-out, org-clock-display):
* lisp/org/org.el (org-refile):
* lisp/progmodes/ada-xref.el (ada-goto-declaration):
* lisp/progmodes/idlwave.el (idlwave-scan-library-catalogs):
Don’t trust arbitrary strings to not contain "%" or "`" in
(message (concat STRING1 STRING2 ...)).
---
 lisp/calc/calc-store.el    |  4 ++--
 lisp/net/rcirc.el          |  4 ++--
 lisp/org/org-agenda.el     | 13 ++++++-------
 lisp/org/org-clock.el      | 22 ++++++++++++----------
 lisp/org/org.el            |  3 ++-
 lisp/progmodes/ada-xref.el |  3 +--
 lisp/progmodes/idlwave.el  |  7 +++----
 7 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/lisp/calc/calc-store.el b/lisp/calc/calc-store.el
index 589a776c41..3987c129c2 100644
--- a/lisp/calc/calc-store.el
+++ b/lisp/calc/calc-store.el
@@ -405,8 +405,8 @@ calc-copy-special-constant
                                     sconst))))
        (if var
            (let ((msg (calc-store-value var value "")))
-             (message (concat "Special constant \"%s\" copied to \"%s\"" msg)
-                      sconst (calc-var-name var)))))))))
+	     (message "Special constant \"%s\" copied to \"%s\"%s"
+		      sconst (calc-var-name var) msg))))))))
 
 (defun calc-copy-variable (&optional var1 var2)
   (interactive)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index b1a6c1ce8d..9d53cd4436 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -2685,7 +2685,7 @@ rcirc-handler-PART-or-KICK
 (defun rcirc-handler-PART (process sender args _text)
   (let* ((channel (car args))
 	 (reason (cadr args))
-	 (message (concat channel " " reason)))
+	 (message "%s %s" channel reason))
     (rcirc-print process sender "PART" channel message)
     ;; print in private chat buffer if it exists
     (when (rcirc-get-buffer (rcirc-buffer-process) sender)
@@ -2697,7 +2697,7 @@ rcirc-handler-KICK
   (let* ((channel (car args))
 	 (nick (cadr args))
 	 (reason (nth 2 args))
-	 (message (concat nick " " channel " " reason)))
+	 (message "%s %s %s" nick channel reason))
     (rcirc-print process sender "KICK" channel message t)
     ;; print in private chat buffer if it exists
     (when (rcirc-get-buffer (rcirc-buffer-process) nick)
diff --git a/lisp/org/org-agenda.el b/lisp/org/org-agenda.el
index e416f5f062..23ee8d71e6 100644
--- a/lisp/org/org-agenda.el
+++ b/lisp/org/org-agenda.el
@@ -2882,13 +2882,12 @@ org-agenda
 	     (let* ((m (org-agenda-get-any-marker))
 		    (note (and m (org-entry-get m "THEFLAGGINGNOTE"))))
 	       (when note
-		 (message (concat
-			   "FLAGGING-NOTE ([?] for more info): "
-			   (org-add-props
-			       (replace-regexp-in-string
-				"\\\\n" "//"
-				(copy-sequence note))
-			       nil 'face 'org-warning)))))))
+		 (message "FLAGGING-NOTE ([?] for more info): %s"
+			  (org-add-props
+			   (replace-regexp-in-string
+			    "\\\\n" "//"
+			    (copy-sequence note))
+			   nil 'face 'org-warning))))))
 	 t t))
        ((equal org-keys "#") (call-interactively 'org-agenda-list-stuck-projects))
        ((equal org-keys "/") (call-interactively 'org-occur-in-agenda-files))
diff --git a/lisp/org/org-clock.el b/lisp/org/org-clock.el
index 34b694d487..62c7cd92d1 100644
--- a/lisp/org/org-clock.el
+++ b/lisp/org/org-clock.el
@@ -1622,9 +1622,10 @@ org-clock-out
 						"\\>"))))
 		  (org-todo org-clock-out-switch-to-state))))))
 	  (force-mode-line-update)
-	  (message (concat "Clock stopped at %s after "
-			   (org-duration-from-minutes (+ (* 60 h) m)) "%s")
-		   te (if remove " => LINE REMOVED" ""))
+	  (message (if remove
+		       "Clock stopped at %s after %s => LINE REMOVED"
+		     "Clock stopped at %s after %s")
+		   te (org-duration-from-minutes (+ (* 60 h) m)))
 	  (run-hooks 'org-clock-out-hook)
 	  (unless (org-clocking-p)
 	    (setq org-clock-current-task nil)))))))
@@ -1925,13 +1926,14 @@ org-clock-display
 		    nil 'local))))
     (let* ((h (/ org-clock-file-total-minutes 60))
 	   (m (- org-clock-file-total-minutes (* 60 h))))
-      (message (concat (format "Total file time%s: "
-			       (cond (todayp " for today")
-				     (customp " (custom)")
-				     (t "")))
-		       (org-duration-from-minutes
-			org-clock-file-total-minutes)
-		       " (%d hours and %d minutes)")
+      (message (cond
+		(todayp
+		 "Total file time for today: %s (%d hours and %d minutes)")
+		(customp
+		 "Total file time (custom): %s (%d hours and %d minutes)")
+		(t
+		 "Total file time: %s (%d hours and %d minutes)"))
+	       (org-duration-from-minutes org-clock-file-total-minutes)
 	       h m))))
 
 (defvar-local org-clock-overlays nil)
diff --git a/lisp/org/org.el b/lisp/org/org.el
index 3a434d12df..e3c78ae90d 100644
--- a/lisp/org/org.el
+++ b/lisp/org/org.el
@@ -11878,7 +11878,8 @@ org-refile
 	    (when (featurep 'org-inlinetask)
 	      (org-inlinetask-remove-END-maybe))
 	    (setq org-markers-to-move nil)
-	    (message (concat actionmsg " to \"%s\" in file %s: done") (car it) file)))))))
+	    (message "%s to \"%s\" in file %s: done" actionmsg
+		     (car it) file)))))))
 
 (defun org-refile-goto-last-stored ()
   "Go to the location where the last refile was stored."
diff --git a/lisp/progmodes/ada-xref.el b/lisp/progmodes/ada-xref.el
index 28c52b0653..c9c923e1d6 100644
--- a/lisp/progmodes/ada-xref.el
+++ b/lisp/progmodes/ada-xref.el
@@ -1133,8 +1133,7 @@ ada-goto-declaration
 	(ada-find-in-ali identlist other-frame)
       ;; File not found: print explicit error message
       (ada-error-file-not-found
-       (message (concat (error-message-string err)
-			(nthcdr 1 err))))
+       (message "%s%s" (error-message-string err) (nthcdr 1 err)))
 
       (error
        (let ((ali-file (ada-get-ali-file-name (ada-file-of identlist))))
diff --git a/lisp/progmodes/idlwave.el b/lisp/progmodes/idlwave.el
index 476d935e8a..25bc788ffc 100644
--- a/lisp/progmodes/idlwave.el
+++ b/lisp/progmodes/idlwave.el
@@ -5588,7 +5588,7 @@ idlwave-scan-library-catalogs
 	     (mapcar 'car idlwave-path-alist)))
 	  (old-libname "")
 	  dir-entry dir catalog all-routines)
-      (if message-base (message message-base))
+      (if message-base (message "%s" message-base))
       (while (setq dir (pop dirs))
 	(catch 'continue
 	  (when (file-readable-p
@@ -5603,8 +5603,7 @@ idlwave-scan-library-catalogs
 		     message-base
 		     (not (string= idlwave-library-catalog-libname
 				   old-libname)))
-		(message "%s" (concat message-base
-				      idlwave-library-catalog-libname))
+		(message "%s%s" message-base idlwave-library-catalog-libname)
 		(setq old-libname idlwave-library-catalog-libname))
 	      (when idlwave-library-catalog-routines
 		(setq all-routines
@@ -5618,7 +5617,7 @@ idlwave-scan-library-catalogs
 		       (setq dir-entry (assoc dir idlwave-path-alist)))
 	      (idlwave-path-alist-add-flag dir-entry 'lib)))))
       (unless no-load (setq idlwave-library-catalog-routines all-routines))
-      (if message-base (message (concat message-base "done"))))))
+      (if message-base (message "%sdone" message-base)))))
 
 ;;----- Communicating with the Shell -------------------
 
-- 
2.20.1

Re: Emacs i18n

[martin rudalics]

These

-	 (message (concat channel " " reason)))
+	 (message "%s %s" channel reason))
      (rcirc-print process sender "PART" channel message)
      ;; print in private chat buffer if it exists
      (when (rcirc-get-buffer (rcirc-buffer-process) sender)
@@ -2697,7 +2697,7 @@ rcirc-handler-KICK
    (let* ((channel (car args))
  	 (nick (cadr args))
  	 (reason (nth 2 args))
-	 (message (concat nick " " channel " " reason)))
+	 (message "%s %s %s" nick channel reason))

get me here

In toplevel form:
../../lisp/net/rcirc.el:2685:1:Warning: Malformed `let*' binding: (message "%s
     %s" channel reason)
../../lisp/net/rcirc.el:2696:1:Warning: Malformed `let*' binding: (message "%s
     %s %s" nick channel reason)

martin

Re: Emacs i18n

[Paul Eggert]

On 3/7/19 10:24 AM, martin rudalics wrote:
> ../../lisp/net/rcirc.el:2685:1:Warning: Malformed `let*' binding:
> (message "%s
>     %s" channel reason) 

Oops. Thanks for reporting that. I fixed it in master.

Re: Emacs i18n

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, juri@linkov.net
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 7 Mar 2019 09:19:35 -0800
> 
> This limitation will cause problems with Elisp code that does extensive
> parsing or processing of English syntax (doctor.el, say), and that sort
> of Elisp code will remain English-only (unless someone takes the time to
> i18nize them specially). However most Elisp code does not parse English
> or generate idiomatic English on the fly: instead, it uses a fixed,
> stilted style that can routinely be converted to calls like (message
> FORMAT ARG1 ARG2 ...) where FORMAT is translated and the ARG values are not.
> 
> To get a quick feel for this issue, I did a simple grep for the string
> '(message (concat' in the Emacs source code. I found 41 instances of
> this string.

But 'message' is just a representative of a class of such functions.
There are others: 'signal', 'error', 'user-error', 'princ', 'format',
and probably some more I'm missing.  So the actual number of
occurrences is larger than the 40 you found.

I guess I'm saying that we should think some more whether we indeed
want to give up marking translatable strings and instead rely on some
functions always translating their argument strings.  Perhaps doing so
will impose restrictions on what a Lisp program can do, and we don't
want to live with such restrictions without some fire escape, in the
form of explicitly translated strings?

In general, I think we should not blindly accept any technique used
for localization, because Emacs is so much different from a typical
console program written in C.

Re: Emacs i18n

[Paul Eggert]

On 3/7/19 12:22 PM, Eli Zaretskii wrote:
>
> 'message' is just a representative of a class of such functions.
> There are others: 'signal', 'error', 'user-error', 'princ', 'format',
> and probably some more I'm missing.  So the actual number of
> occurrences is larger than the 40 you found.

Yes, of course. And even for 'message', all I searched for was the
string '(message (concat', which is just a fraction of the calls to
'message' that will need to be reworked. That search was not an attempt
to count all the problems we'd run into; it merely was a sample of the
problems. If the sample is representative then each individual problem
should be relatively easy to solve.


> whether we indeed
> want to give up marking translatable strings and instead rely on some
> functions always translating their argument strings.

We could mark each translatable string by hand. But this would make for
more churn to the source code and would be more work. It's hard to see
why that would be a win, compared to the reasonably-common practice of
marking some well-known functions as doing translations automatically.


> Perhaps doing so
> will impose restrictions on what a Lisp program can do, and we don't
> want to live with such restrictions without some fire escape, in the
> form of explicitly translated strings?

One can easily work around any such restrictions by having a variant of
'message' that does not translate its format argument. We're already
doing this for translation of '`', by having two functions 'format' and
'format-message': the former does not translate '`', the latter does. A
similar approach can work for natural-language translation and 'message'.


> we should not blindly accept any technique used
> for localization, because Emacs is so much different from a typical
> console program written in C.

Of course we should not accept techniques blindly. We should use
techniques with our eyes open, based on experience. That being said,
this discussion suggests that Emacs is not really that much of a special
case aside from its size. If so, there is little need to reinvent the
i18n wheel just for Emacs, and there is a real advantage to reusing
existing GNU technology in this area rather than trying to reinvent it.

Re: Emacs i18n

[Eli Zaretskii]

> Cc: rms@gnu.org, emacs-devel@gnu.org, juri@linkov.net
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 7 Mar 2019 14:25:30 -0800
> 
> > whether we indeed
> > want to give up marking translatable strings and instead rely on some
> > functions always translating their argument strings.
> 
> We could mark each translatable string by hand.

No, I didn't mean "each", I meant just some, hopefully a small
minority.  Because most of the use cases are probably easy enough to
change so that strings could be collected by a tool, and 'message' and
its ilk could then translate them automatically.  Having an explicit
translation function would then be that "fire escape" for when
converting code not to compute strings would be too painful.

> > Perhaps doing so
> > will impose restrictions on what a Lisp program can do, and we don't
> > want to live with such restrictions without some fire escape, in the
> > form of explicitly translated strings?
> 
> One can easily work around any such restrictions by having a variant of
> 'message' that does not translate its format argument.

We could, but I don't see how that would help.  If a string is not
found in the catalog(s), it will be output untranslated anyway, so why
do we need a separate function?

> this discussion suggests that Emacs is not really that much of a special
> case aside from its size.

I'm not sure I agree.  I think the fact that Emacs is written mostly
in Lisp and not in a procedural compiled language will make another
qualitative difference.

> there is a real advantage to reusing existing GNU technology in this
> area rather than trying to reinvent it.

Where it fits, sure.  Especially we should strive hard to use the PO
files for catalogs, because that affects the translation teams.

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. ]]]

  > But 'message' is just a representative of a class of such functions.
  > There are others: 'signal', 'error', 'user-error', 'princ', 'format',
  > and probably some more I'm missing.  So the actual number of
  > occurrences is larger than the 40 you found.

Some of them should be handled in the same way as 'message'.  But not
'format' -- it can be used for various things and some should not be
translated.

  > I guess I'm saying that we should think some more whether we indeed
  > want to give up marking translatable strings

Of course we need an explicit way to mark translatable strings -- but
we should also adopt short cuts (like recognizing first arg of
'message') so that a large fraction of these strings don't need to be
explicitly marked.

If we are going to handle translation, this is the obvious best way,
so let's not worry about the precise details.  It will get done.



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

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. ]]]

  > > That would happen if the catalog is made ONLY by scanning the source.
  > > That's why I suggested a feature to record whatever nontrivial format
  > > strings are passed to 'message' and are not in the catalog.

  > Such a feature will only help when a given call to 'message' produce a
  > small number of fixed text strings.  If the text it produces includes
  > some non-deterministic ingredient, this method will not help.

That is true.  But it is a comparatively small problem,
because those cases are a small minority.

The approach I have in mind is to make several mechanisms,
each designed to handle a large fraction of cases easily,
and leave the exceptions to be handled less easily.

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

Re: Emacs i18n

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 05 Mar 2019 23:58:25 +0200
> 
> One of the main decisions that has to be made is whether to wrap all
> user-facing translatable strings in all Lisp files using a macro/function
> 'gettext' (alias '_') explicitly like is implemented in XEmacs' I18N3
> that would help to extract translations from the source code, or to use
> a low-level implicit translation without changing the existing code like
> is implemented for handling text-quoting-style in format strings.
> The latter will even allow translation of strings that a package author
> forgot to mark with '_'.

I'd encourage people who want or consider working on this to read past
discussions about related topics.  Some very important conclusions and
ideas came out of those discussions, and it would be a pity if we'd
need to reiterate all of what was already said and argued time and
again, instead of starting from where those past discussions ended.

Significant discussions of this happened in Dec 2001, in July 2007,
and lately in Apr 2017.  Some of those are quite long, but please do
read them, even if you were part of those discussions.  This current
discussion will be much more fruitful if we first recollect what we
already talked over.

> Depending on this decision a translation file format has to be selected,
> be it flat Gettext PO format files or even some YAML-like hierarchical
> Lisp structures with scopes.

The first alternative we should consider is to use the PO format,
because that's what translation teams out there are used to work with.
If it turns out that we cannot use the PO format for some good reasons
(which will have to be very good), we can consider other formats, but
translation teams will be in general very unhappy about that.

And I think these technicalities are not the first, let alone main,
decisions we must make.  They are important, but there are more
important and complex problems we need to address first.  I will talk
about this separately.

Thanks.

Re: Emacs i18n

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 05 Mar 2019 23:58:25 +0200
> 
> One of the main decisions that has to be made is whether to wrap all
> user-facing translatable strings in all Lisp files using a macro/function
> 'gettext'

First, AFAIR the conclusion back when this was discussed was that we
might not need to mark the translatable strings, because almost all of
them should be translatable.  If anything, we might consider marking
strings that do NOT need to be translated, as they are a very small
minority.  Just look at the strings in a typical Emacs source file and
try to find strings that you wouldn't want translated.  Unlike some
other programs, Emacs almost never says something that is not meant to
be read and understood by the user.

Second, I don't understand why we are still talking about 'message'.
Most of the user interaction in Emacs that will benefit the most from
translation is not messages we show in the echo area: Emacs actually
doesn't chatter there too much.  Most of the stuff that IMO is much
more important to have translated are the doc strings.  It's no
coincidence that Emacs has around 5000 calls to 'message', but almost
50000 doc strings, 10 times more than echo-area messages.  So even if
we do decide to attack the 'message' part first, we should consider
the doc strings as well, so that whatever infrastructure we develop
for messages will work for doc strings as well.  And that adds more
issues that the basic design must solve or be capable of solving.

Then there are some seemingly minor technical issues, but I think
Emacs will force us to deal with them up front, because Emacs is so
much different from a typical localized text-mode program.  Some of
the issues that came up in the past:

 . Do we use a separate message catalog for each Lisp package, or a
   single catalog for all of Emacs?  Each alternative has its merits
   and demerits.  For example, if we go with separate catalogs, then
   how do we make the correct bindtextdomain call, given that packages
   call each other?  If we go for a single catalog, how do we support
   installing and loading a new package without exiting Emacs?

 . How to specify which target language to use?  The locale is not
   necessarily correct, e.g., when editing with Tramp.  Also, since
   translating all of Emacs is such a humongous job, it's quite
   possible that some languages will have little or no translations,
   and the respective users might want to use translations for a
   "fallback" language, which they prefer to English.

 . Many user-facing text messages include portions that we generate
   directly from symbol names, which are of course in English.  We
   should have some idea for how to deal with that.

Re: Emacs i18n

[Paul Eggert]

On 3/6/19 10:09 AM, Eli Zaretskii wrote:
> we might consider marking
> strings that do NOT need to be translated, as they are a very small
> minority.  Just look at the strings in a typical Emacs source file and
> try to find strings that you wouldn't want translated.  Unlike some
> other programs, Emacs almost never says something that is not meant to
> be read and understood by the user.

My impression is just the opposite. Of course it depends on the module,
but I just now took a census of todo-mode.el (which I happened to be
editing anyway) and looked at the first 300 lines of source code (at
which point I got tired of counting). I counted 24 strings that should
not be translated, and 5 strings that should be. (I did not count doc
strings, which obviously should all be translated and shouldn't need to
be marked.)

Here are the strings needing translation:

"==--== DONE "
"DONE "
"Invalid value: must be distinct from `todo-item-mark'"
%s category %d: %s"
"Invalid value: must be a positive integer"

and here are the strings that don't need translation:

"todo/"
"\\.toda\\'"
"\\.todo\\'"
"--==-- "
"="
"["
"]"
"*"
"\\(?4:\\(?5:"
"\\)\\|"
"\\(?6:%s\\)"
"\\(?7:[0-9]+\\|\\*\\)"
"\\(?8:[0-9]+\\|\\*\\)"
"-?\\(?9:[0-9]+\\|\\*\\)"
""
"\\)"
"^\\("
"\\|"
"\\)?"
"^\\["
"\\("
"\\|"
"\\)"
""

Re: Emacs i18n

[Eli Zaretskii]

> Cc: rms@gnu.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 6 Mar 2019 11:39:50 -0800
> 
> On 3/6/19 10:09 AM, Eli Zaretskii wrote:
> > we might consider marking
> > strings that do NOT need to be translated, as they are a very small
> > minority.  Just look at the strings in a typical Emacs source file and
> > try to find strings that you wouldn't want translated.  Unlike some
> > other programs, Emacs almost never says something that is not meant to
> > be read and understood by the user.
> 
> My impression is just the opposite. Of course it depends on the module,
> but I just now took a census of todo-mode.el (which I happened to be
> editing anyway) and looked at the first 300 lines of source code (at
> which point I got tired of counting). I counted 24 strings that should
> not be translated, and 5 strings that should be.

We are miscommunicating: I meant strings passed to 'message' and its
ilk, not just any kind of strings.  It goes without saying that most
strings in our sources don't need to be translated, but that's not
what we are discussing.

Re: Emacs i18n

[Paul Eggert]

On 3/6/19 11:49 AM, Eli Zaretskii wrote:
> We are miscommunicating: I meant strings passed to 'message' and its
> ilk, not just any kind of strings.

In that case, the solution that Richard proposed should suffice for most
cases. That is, in most cases we shouldn't need to change the Elisp
source code; all we need is for xgettext (or its equivalent) to consider
the first argument of 'message' to be a translatable string. This is a
standard feature of xgettext (see its --keyword argument).

Re: Emacs i18n

[Eli Zaretskii]

> Cc: juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 6 Mar 2019 17:33:26 -0800
> 
> On 3/6/19 11:49 AM, Eli Zaretskii wrote:
> > We are miscommunicating: I meant strings passed to 'message' and its
> > ilk, not just any kind of strings.
> 
> In that case, the solution that Richard proposed should suffice for most
> cases. That is, in most cases we shouldn't need to change the Elisp
> source code; all we need is for xgettext (or its equivalent) to consider
> the first argument of 'message' to be a translatable string. This is a
> standard feature of xgettext (see its --keyword argument).

This will solve the string extraction part.  But how will the actual
translation happen?  As I wrote elsewhere, I don't see how relying on
the function to perform the extraction will work with non-fixed
strings.

Re: Emacs i18n

[Paul Eggert]

On 3/6/19 7:30 PM, Eli Zaretskii wrote:
> I don't see how relying on
> the function to perform the extraction will work with non-fixed
> strings.

Yes, if a caller computes a string and then passes it to 'message',
xgettext's static analysis won't find the string. Although these calls
are in the minority, they do happen, and they'll need to be rewritten.
This is standard practice when any application is internationalized, and
I've already given an example of this.

Of course Emacs is a much bigger project than a small program like 'cat'
or 'uniq', and so Emacs will take much more work to internationalize.
But this is a problem of quantity, not of technology. That is,
translators will need to do more work than usual (as there are more
messages to translate) and developers will need to do some more work (as
there are more "tricky" uses of 'message' in Emacs than there were
"tricky" uses of fprintf in 'cat'.) However, the standard GNU
internationalization technology should work just fine with Emacs.

> E.g., what to do
> with Org, which is in the core, but also distributed separately.
A simple way to address that problem is to have Org use and ship the
same message catalog that Emacs does. Alternatively, Org could ship a
separate message catalog that contains only Org's messages and is
therefore a subset of the Emacs catalog. However, I doubt whether the
hassle of doing the latter would be worth the effort.

Re: Emacs i18n

[Jean-Christophe Helary]

> On Mar 7, 2019, at 10:33, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> On 3/6/19 11:49 AM, Eli Zaretskii wrote:
>> We are miscommunicating: I meant strings passed to 'message' and its ilk, not just any kind of strings.
> 
> In that case, the solution that Richard proposed should suffice for most cases. That is, in most cases we shouldn't need to change the Elisp source code; all we need is for xgettext (or its equivalent) to consider the first argument of 'message' to be a translatable string. This is a standard feature of xgettext (see its --keyword argument).

Yes but... The first argument of message is often a lisp expression that generates natural language strings programatically. That part will have to be modified (although far from perfect, please check what I did on packages.el if what I wrote above is not clear).

ps: what is the proper way to reply to this list ? Keep everybody in Cc or remove the Cc and only keep the list address ?

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Paul Eggert]

On 3/6/19 8:35 PM, Jean-Christophe Helary wrote:

> in most cases we shouldn't need to change the Elisp source code; all we need is for xgettext (or its equivalent) to consider the first argument of 'message' to be a translatable string. This is a standard feature of xgettext (see its --keyword argument).
> Yes but... The first argument of message is often a lisp expression

Of course; we are on the same page here. Most cases of 'message' should
be fine, but there will often be exceptions that we do need to rewrite.
These exceptions are not urgent: we can fix them as we find time.

> ps: what is the proper way to reply to this list ? Keep everybody in Cc or remove the Cc and only keep the list address ?

I typically just reply to whatever my email software defaults to.
Occasionally I'll remove a Cc if I think that particular person probably
won't care about my reply or I know the person is on a mailing list I'm
already replying to; but this is optional and takes time and I typically
don't bother.

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. ]]]

  > Yes but... The first argument of message is often a lisp
  > expression that generates natural language strings
  > programatically. That part will have to be modified (although far
  > from perfect, please check what I did on packages.el if what I
  > wrote above is not clear).

Those cases will need to be modified.
Such is life.  It may take time to get them all, but we will.

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

Re: Emacs i18n

[Juri Linkov]

>> In that case, the solution that Richard proposed should suffice for most
>> cases. That is, in most cases we shouldn't need to change the Elisp
>> source code; all we need is for xgettext (or its equivalent) to consider
>> the first argument of 'message' to be a translatable string. This is
>> a standard feature of xgettext (see its --keyword argument).
>
> Yes but... The first argument of message is often a lisp expression that
> generates natural language strings programatically. That part will have to
> be modified (although far from perfect, please check what I did on
> packages.el if what I wrote above is not clear).

Please note that you have to handle not only format-strings of ‘message’,
but also ‘error’ and even more low-level ‘format’, i.e. all these

  (error STRING &rest ARGS)
  (message FORMAT-STRING &rest ARGS)
  (format-message STRING &rest OBJECTS)
  (format STRING &rest OBJECTS)

because there are many places that construct the string arguments
of ‘message’ using ‘format’ like in ‘perform-replace’:

	(message "Replaced %d occurrences%s"
		 replace-count
		 (if (> (+ skip-read-only-count
			   skip-filtered-count
			   skip-invisible-count)
                        0)
		     (format " (skipped %s)"
			     (mapconcat
			      #'identity
			      (delq nil (list
					 (if (> skip-read-only-count 0)
					     (format "%s read-only"
						     skip-read-only-count))
					 (if (> skip-invisible-count 0)
					     (format "%s invisible"
						     skip-invisible-count))
					 (if (> skip-filtered-count 0)
					     (format "%s filtered out"
						     skip-filtered-count))))
			      ", "))
		   ""))

Re: Emacs i18n

[Paul Eggert]

On 3/11/19 2:48 PM, Juri Linkov wrote:

> Please note that you have to handle not only format-strings of
> ‘message’, but also ‘error’ and even more low-level ‘format’, i.e. all
> these (error STRING &rest ARGS) (message FORMAT-STRING &rest ARGS)
> (format-message STRING &rest OBJECTS) (format STRING &rest OBJECTS)
>
I expect that 'format' won't translate its first argument, whereas
'error', 'message', and 'format-message' will. This will be for the same
reason that 'format' does not translate quotes.

> there are many places that construct the string arguments of ‘message’
> using ‘format’ like in ‘perform-replace’:
>
Yes, quite right. These places will need to be redone so that the
translation will work properly. Here's a first cut at how to redo the
perform-replace code that you mentioned (this could get fancier if needed):

  (nmessage replace-count
            "Replaced %d occurrence%s"
            "Replaced %d occurrences%s"
            replace-count
            (if (> (+ skip-read-only-count
                      skip-filtered-count
                      skip-invisible-count)
                   0)
                (format-message
                 " (skipped %s)"
                 (mapconcat
                  #'identity
                  (delq nil (list
                             (if (> skip-read-only-count 0)
                                 (format-message "%s read-only"
                                                 skip-read-only-count))
                             (if (> skip-invisible-count 0)
                                 (format-message "%s invisible"
                                                 skip-invisible-count))
                             (if (> skip-filtered-count 0)
                                 (format-message "%s filtered out"
                                                 skip-filtered-count))))
                  (gettext ", ")))
              ""))

Re: Emacs i18n

[Juri Linkov]

>> Please note that you have to handle not only format-strings of
>> ‘message’, but also ‘error’ and even more low-level ‘format’, i.e. all
>> these (error STRING &rest ARGS) (message FORMAT-STRING &rest ARGS)
>> (format-message STRING &rest OBJECTS) (format STRING &rest OBJECTS)
>>
> I expect that 'format' won't translate its first argument, whereas
> 'error', 'message', and 'format-message' will. This will be for the same
> reason that 'format' does not translate quotes.

Then it should be sufficient to add a gettext call to 'format-message' only,
because all other related functions 'message', 'error', 'tramp-message',
'tramp-error', etc. all they use 'format-message' directly or indirectly.

If someone would create a new branch with all standard gettext prerequisites
like Makefiles, headers, textdomain bindings, locale settings,
i.e. everything that is required to translate other GNU applications,
then I could help with testing and finding more problematic places.
Only then we could see how well gettext (designed for static translation)
performs in more dynamic Emacs environment.

>> there are many places that construct the string arguments of ‘message’
>> using ‘format’ like in ‘perform-replace’:
>>
> Yes, quite right. These places will need to be redone so that the
> translation will work properly. Here's a first cut at how to redo the
> perform-replace code that you mentioned (this could get fancier if needed):
>
>   (nmessage replace-count
>             "Replaced %d occurrence%s"
>             "Replaced %d occurrences%s"
>             replace-count

IIUC, using standard gettext functions this would rather correspond to

  (message (ngettext "Replaced %1$d occurrence%s"
                     "Replaced %1$d occurrences%s"
                     replace-count)
           replace-count
           (if (> (+ skip-read-only-count
                     skip-filtered-count
                     skip-invisible-count)
                  0)
               (format-message
                " (skipped %s)"
                (mapconcat
                 #'identity
                 (delq nil (list
                            (if (> skip-read-only-count 0)
                                (format-message "%s read-only"
                                                skip-read-only-count))
                            (if (> skip-invisible-count 0)
                                (format-message "%s invisible"
                                                skip-invisible-count))
                            (if (> skip-filtered-count 0)
                                (format-message "%s filtered out"
                                                skip-filtered-count))))
                 (gettext ", ")))
             ""))

Re: Emacs i18n

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]

>>> Please note that you have to handle not only format-strings of
>>> ‘message’, but also ‘error’ and even more low-level ‘format’, i.e. all
>>> these (error STRING &rest ARGS) (message FORMAT-STRING &rest ARGS)
>>> (format-message STRING &rest OBJECTS) (format STRING &rest OBJECTS)
>>>
>> I expect that 'format' won't translate its first argument, whereas
>> 'error', 'message', and 'format-message' will. This will be for the same
>> reason that 'format' does not translate quotes.
>
> Then it should be sufficient to add a gettext call to 'format-message' only,
> because all other related functions 'message', 'error', 'tramp-message',
> 'tramp-error', etc. all they use 'format-message' directly or indirectly.

Maybe I'm too stupid to comprehend the complexity of this task in its entirety,
but I tried to install gettext infrastructure in Emacs with gettextize,
and then tried to run xgettext on source code, and see no technical problems.
What I tried is to run this command, and it extracts all messages:

  xgettext --from-code=UTF-8 -kformat-message -kmessage -kerror -ktramp-message -ktramp-error *.el

then this command extracts all Gnus messages into a separate file:

  xgettext --from-code=UTF-8 -kformat-message -kmessage -kerror gnus/*.el -o gnus_messages.po

this command extracts all menu items:

  xgettext --from-code=UTF-8 -kmenu-item *.el **/*.el -o menus.po

and this extracts all docstrings:

  xgettext --from-code=UTF-8 -kdefcustom:3 -kdefvar:3 -kdefun:3 *.el **/*.el -o docstrings.po

The size of docstrings.po is about 9MB, so perhaps it should reside in
a separate catalog defined by e.g.

  (defdomain emacs-docstrings

with semantics similar to defgroup, but I have no opinion about this.

I think this project urgently needs a coordinator: to negotiate with
package authors and translation teams about how to better split
translations to message catalogs.  So there are not so much technical
problems, but mostly organizational ones.

> IIUC, using standard gettext functions this would rather correspond to
>
>   (message (ngettext "Replaced %1$d occurrence%s"
>                      "Replaced %1$d occurrences%s"
>                      replace-count)

It seems better to start with this standard function
and add more optimizations like ‘nmessage’ later.

Other Lisp implementations use ‘ngettext’ as well, e.g.:
https://clisp.sourceforge.io/impnotes.html#ggettext

So I'm going to start with more obvious parts of the task
by fixing the current bugs of incorrect English syntax
in a forward-compatible way:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: i18n-ngettext.patch --]
[-- Type: text/x-diff, Size: 6767 bytes --]

diff --git a/lisp/subr.el b/lisp/subr.el
index 6c0ad00afa..1f000f77ad 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -342,6 +342,13 @@ define-error
          (delete-dups (copy-sequence (cons name conditions))))
     (when message (put name 'error-message message))))
 
+(defun ngettext (msgid msgid_plural n &optional _domain _category)
+  "Return the plural form of the translation for of MSGID and N.
+In the given DOMAIN, depending on the given CATEGORY.  MSGID and
+MSGID_PLURAL should be ASCII strings, and are normally the English singular
+and English plural variant of the message, respectively."
+  (if (/= n 1) msgid_plural msgid))
+
 ;; We put this here instead of in frame.el so that it's defined even on
 ;; systems where frame.el isn't loaded.
 (defun frame-configuration-p (object)
diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el
index a5427dd8b7..c0f47159c9 100644
--- a/lisp/progmodes/grep.el
+++ b/lisp/progmodes/grep.el
@@ -459,7 +459,7 @@ grep-mode-font-lock-keywords
      ;; remove match from grep-regexp-alist before fontifying
      ("^Grep[/a-zA-Z]* started.*"
       (0 '(face nil compilation-message nil help-echo nil mouse-face nil) t))
-     ("^Grep[/a-zA-Z]* finished with \\(?:\\(\\(?:[0-9]+ \\)?matches found\\)\\|\\(no matches found\\)\\).*"
+     ("^Grep[/a-zA-Z]* finished with \\(?:\\(\\(?:[0-9]+ \\)?match\\(?:es\\)? found\\)\\|\\(no matches found\\)\\).*"
       (0 '(face nil compilation-message nil help-echo nil mouse-face nil) t)
       (1 compilation-info-face nil t)
       (2 compilation-warning-face nil t))
@@ -552,7 +552,10 @@ grep-exit-message
       ;; so the buffer is still unmodified if there is no output.
       (cond ((and (zerop code) (buffer-modified-p))
 	     (if (> grep-num-matches-found 0)
-                 (cons (format "finished with %d matches found\n" grep-num-matches-found)
+                 (cons (format (ngettext "finished with %d match found\n"
+                                         "finished with %d matches found\n"
+                                         grep-num-matches-found)
+                               grep-num-matches-found)
                        "matched")
                '("finished with matches found\n" . "matched")))
 	    ((not (buffer-modified-p))
diff --git a/lisp/replace.el b/lisp/replace.el
index 59ad1a375b..318a9fb025 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -983,7 +983,10 @@ flush-lines
 		       (progn (forward-line 1) (point)))
         (setq count (1+ count))))
     (set-marker rend nil)
-    (when interactive (message "Deleted %d matching lines" count))
+    (when interactive (message (ngettext "Deleted %d matching line"
+					 "Deleted %d matching lines"
+					 count)
+			       count))
     count))
 
 (defun how-many (regexp &optional rstart rend interactive)
@@ -1032,9 +1035,10 @@ how-many
 	(if (= opoint (point))
 	    (forward-char 1)
 	  (setq count (1+ count))))
-      (when interactive (message "%d occurrence%s"
-				 count
-				 (if (= count 1) "" "s")))
+      (when interactive (message (ngettext "%d occurrence"
+					   "%d occurrences"
+					   count)
+				 count))
       count)))
 
 \f
@@ -1617,11 +1621,12 @@ occur-1
 		  (not (eq occur-excluded-properties t))))))
 	  (let* ((bufcount (length active-bufs))
 		 (diff (- (length bufs) bufcount)))
-	    (message "Searched %d buffer%s%s; %s match%s%s"
-		     bufcount (if (= bufcount 1) "" "s")
+	    (message "Searched %d %s%s; %s %s%s"
+		     bufcount
+		     (ngettext "buffer" "buffers" bufcount)
 		     (if (zerop diff) "" (format " (%d killed)" diff))
 		     (if (zerop count) "no" (format "%d" count))
-		     (if (= count 1) "" "es")
+		     (ngettext "match" "matches" count)
 		     ;; Don't display regexp if with remaining text
 		     ;; it is longer than window-width.
 		     (if (> (+ (length (or (get-text-property 0 'isearch-string regexp)
@@ -1856,14 +1861,15 @@ occur-engine
 		  (let ((beg (point))
 		        end)
 		    (insert (propertize
-			     (format "%d match%s%s%s in buffer: %s%s\n"
-				     matches (if (= matches 1) "" "es")
+			     (format "%d %s%s%s in buffer: %s%s\n"
+				     matches
+				     (ngettext "match" "matches" matches)
 				     ;; Don't display the same number of lines
 				     ;; and matches in case of 1 match per line.
 				     (if (= lines matches)
-				         "" (format " in %d line%s"
+				         "" (format " in %d %s"
 						    lines
-						    (if (= lines 1) "" "s")))
+						    (ngettext "line" "lines" lines)))
 				     ;; Don't display regexp for multi-buffer.
 				     (if (> (length buffers) 1)
 				         "" (occur-regexp-descr regexp))
@@ -1889,13 +1895,15 @@ occur-engine
 	(goto-char (point-min))
 	(let ((beg (point))
 	      end)
-	  (insert (format "%d match%s%s total%s:\n"
-			  global-matches (if (= global-matches 1) "" "es")
+	  (insert (format "%d %s%s total%s:\n"
+			  global-matches
+			  (ngettext "match" "matches" global-matches)
 			  ;; Don't display the same number of lines
 			  ;; and matches in case of 1 match per line.
 			  (if (= global-lines global-matches)
-			      "" (format " in %d line%s"
-					 global-lines (if (= global-lines 1) "" "s")))
+			      "" (format " in %d %s"
+					 global-lines
+					 (ngettext "line" "lines" global-lines)))
 			  (occur-regexp-descr regexp)))
 	  (setq end (point))
 	  (when title-face
@@ -2730,10 +2738,10 @@ perform-replace
                                            (1+ num-replacements))))))
                              (when (and (eq def 'undo-all)
                                         (null (zerop num-replacements)))
-                               (message "Undid %d %s" num-replacements
-                                        (if (= num-replacements 1)
-                                            "replacement"
-                                          "replacements"))
+                               (message (ngettext "Undid %d replacement"
+                                                  "Undid %d replacements"
+                                                  num-replacements)
+                                        num-replacements)
                                (ding 'no-terminate)
                                (sit-for 1)))
 			   (setq replaced nil last-was-undo t last-was-act-and-show nil)))
@@ -2859,9 +2867,10 @@ perform-replace
                       last-was-act-and-show     nil))))))
       (replace-dehighlight))
     (or unread-command-events
-	(message "Replaced %d occurrence%s%s"
+	(message (ngettext "Replaced %d occurrence%s"
+			   "Replaced %d occurrences%s"
+			   replace-count)
 		 replace-count
-		 (if (= replace-count 1) "" "s")
 		 (if (> (+ skip-read-only-count
 			   skip-filtered-count
 			   skip-invisible-count)

Re: Emacs i18n

[Juri Linkov]

> Other Lisp implementations use ‘ngettext’ as well, e.g.:
> https://clisp.sourceforge.io/impnotes.html#ggettext

And this command will extract ‘ngettext’ messages:

  xgettext --from-code=UTF-8 -kngettext:1,2 *.el **/*.el

Using only ‘ngettext’ has an additional advantage:
there will be no need to add more such functions as
nmessage, nerror, nuser-error, ntramp-error, etc.

But for cases when ‘message’ will receive a string
already translated by ‘ngettext’, e.g.:

  (message (ngettext "Replaced %d occurrence%s"
                     "Replaced %d occurrences%s"
                     replace-count)

we need to mark translated strings like Richard suggested:

  (defun ngettext (msgid msgid_plural n &optional _domain _category)
    "Return the plural form of the translation for of MSGID and N."
    (propertize (if (/= n 1) msgid_plural msgid) 'translated t))

so ‘format-message’ should check if its first argument is translated,
and not to call gettext again.

Re: Emacs i18n

[Paul Eggert]

On 3/18/19 2:20 PM, Juri Linkov wrote:
> Using only ‘ngettext’ has an additional advantage:
> there will be no need to add more such functions as
> nmessage, nerror, nuser-error, ntramp-error, etc.

That's not a real advantage, as there is no need to add those functions
anyway. They are merely conveniences that we can either add or not add,
depending on whether the convenience in use is worth the hassle of
supporting and documenting the functions.

For example, suppose 'message' always translates its format argument and
that there is no 'nmessage' function. Then you can use 'message' this
way to handle plurals:

  (message "%s" (format (ngettext n "%d item" "%d items") n))

If we find expressions like the above to be common, we can easily write
an nmessage function in Lisp, so that the code can look like this instead:

  (nmessage n "%d item" "%d items" n)

but this is merely a convenience.


> ‘format-message’ should check if its first argument is translated,
> and not to call gettext again.
>
I'd rather not involve dynamic checking like that, as it's fragile and
more complicated to explain and a bit slower. format-message should
either always translate, or never translate. In practice, it'll be more
convenient for format-message to always translate, so I expect we should
do it that way.

Re: Emacs i18n

[Juri Linkov]

>> ‘format-message’ should check if its first argument is translated,
>> and not to call gettext again.
>>
> I'd rather not involve dynamic checking like that, as it's fragile and
> more complicated to explain and a bit slower. format-message should
> either always translate, or never translate. In practice, it'll be more
> convenient for format-message to always translate, so I expect we should
> do it that way.

I see this as a kind of optimization.  But I don't know if it is necessary
until trying how fast gettext is on very large translation files
(if it hashes translations strings then should be fast enough).

Re: Emacs i18n

[Jean-Christophe Helary]

> On 2019/03/12, at 6:48, Juri Linkov <juri@linkov.net> wrote:
> 
>> Yes but... The first argument of message is often a lisp expression that
>> generates natural language strings programatically. That part will have to
>> be modified (although far from perfect, please check what I did on
>> packages.el if what I wrote above is not clear).
> 
> Please note that you have to handle not only format-strings of ‘message’,
> but also ‘error’ and even more low-level ‘format’, i.e. all these

I know. That's what I tried to do with packages.el There may be an expression or two that were too obscure for me but I think I managed to straighten all the strings there. Check the current version vs what was in the repository about 1 year ago (I don't remember when my fix was committed).

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Michael Albinus]

Juri Linkov <juri@linkov.net> writes:

> Please note that you have to handle not only format-strings of ‘message’,
> but also ‘error’ and even more low-level ‘format’, i.e. all these
>
>   (error STRING &rest ARGS)
>   (message FORMAT-STRING &rest ARGS)
>   (format-message STRING &rest OBJECTS)
>   (format STRING &rest OBJECTS)

There are even more functions to be considered. Tramp, for example, uses
consequently `tramp-message' instead of `message', and `tramp-error'
instead of `error'.

Likely, we shall provide a mean that a package like Tramp can add its
own entries to such a list of functions.

Best regards, Michael.

Re: Emacs i18n

[Paul Eggert]

On 3/6/19 10:09 AM, Eli Zaretskii wrote:
> even if
> we do decide to attack the 'message' part first, we should consider
> the doc strings as well

Absolutely. In some sense doc strings should be easier, since we
shouldn't need to make changes to existing code; all we need to do is
add some infrastructure that puts doc strings into a .po file and that
translates them when people ask for documentation.


>  . Do we use a separate message catalog for each Lisp package, or a
>    single catalog for all of Emacs?

We can start with a single catalog that handles core Emacs; we'll need
to do that anyway. We can deal with packages later.


>  . How to specify which target language to use?  The locale is not
>    necessarily correct, e.g., when editing with Tramp.  Also, since
>    translating all of Emacs is such a humongous job, it's quite
>    possible that some languages will have little or no translations,
>    and the respective users might want to use translations for a
>    "fallback" language, which they prefer to English.

It should be easy for Emacs users to specify a preferred locale for
messages, independently of what the system locale. Similarly, they can
specify a preferred fallback locale. All this is relatively easy to do
at the C level.

>  . Many user-facing text messages include portions that we generate
>    directly from symbol names, which are of course in English.  We
>    should have some idea for how to deal with that.

We start by leaving them as English, as that's easier. We can get
fancier later, if there's need.

The bottom line is that we don't need to have a complete solution in
order to start working on this.

Re: Emacs i18n

[Eli Zaretskii]

> Cc: rms@gnu.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 6 Mar 2019 11:47:18 -0800
> 
> >  . Do we use a separate message catalog for each Lisp package, or a
> >    single catalog for all of Emacs?
> 
> We can start with a single catalog that handles core Emacs; we'll need
> to do that anyway. We can deal with packages later.

"Core" here being the C sources?  That's about 4% of the doc strings,
a drop in the sea.

Re: Emacs i18n

[Paul Eggert]

On 3/6/19 12:21 PM, Eli Zaretskii wrote:
>> We can start with a single catalog that handles core Emacs; we'll need
>> to do that anyway. We can deal with packages later.
> "Core" here being the C sources?  That's about 4% of the doc strings,
> a drop in the sea.

Sure, but it should be relatively easy to also grab the doc strings from
the Emacs core elisp code. GNU gettext already supports getting strings
from Elisp code (this was for XEmacs) and it should be a relatively
minor change to adapt it to also get doc strings.

Re: Emacs i18n

[Eli Zaretskii]

> Cc: juri@linkov.net, rms@gnu.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 6 Mar 2019 17:43:43 -0800
> 
> On 3/6/19 12:21 PM, Eli Zaretskii wrote:
> >> We can start with a single catalog that handles core Emacs; we'll need
> >> to do that anyway. We can deal with packages later.
> > "Core" here being the C sources?  That's about 4% of the doc strings,
> > a drop in the sea.
> 
> Sure, but it should be relatively easy to also grab the doc strings from
> the Emacs core elisp code. GNU gettext already supports getting strings
> from Elisp code (this was for XEmacs) and it should be a relatively
> minor change to adapt it to also get doc strings.

That gets back again to the problems I mentioned.  E.g., what to do
with Org, which is in the core, but also distributed separately.

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. ]]]

  > Second, I don't understand why we are still talking about 'message'.
  > Most of the user interaction in Emacs that will benefit the most from
  > translation is not messages we show in the echo area: Emacs actually
  > doesn't chatter there too much.  Most of the stuff that IMO is much
  > more important to have translated are the doc strings.

I think it would be most natural to handle doc strings through
a special mechanism.  We have already had special mechanisms
for them -- I don't know whether we still do.  But it is easy
for the compiler to find them all and put them in a file
for translations.

   > . Do we use a separate message catalog for each Lisp package, or a
   >   single catalog for all of Emacs?  Each alternative has its merits
   >   and demerits.  For example, if we go with separate catalogs, then
   >   how do we make the correct bindtextdomain call, given that packages
   >   call each other?

I think they have to be separate, and we can use something like
lexical binding to specify the right one for each file.

This is worth a special mechamism for.

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

Re: Emacs i18n

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: juri@linkov.net, eggert@cs.ucla.edu, emacs-devel@gnu.org
> Date: Wed, 06 Mar 2019 22:44:10 -0500
> 
> I think it would be most natural to handle doc strings through
> a special mechanism.

Up to a point, perhaps.  We still should try to use .po files for
them, if at all possible, and perhaps also the gettext code that
supports looking up strings in .gmo catalogs generated from .po.

Re: Emacs i18n

[Juri Linkov]

>> I think it would be most natural to handle doc strings through
>> a special mechanism.
>
> Up to a point, perhaps.  We still should try to use .po files for
> them, if at all possible, and perhaps also the gettext code that
> supports looking up strings in .gmo catalogs generated from .po.

The PO format is best suited for translation of one-liners like
messages and menu items, but I doubt that the PO format would be
the most efficient implementation for multi-line doc strings since
gettext uses the whole text of the doc string as a key to translation.
Whereas more efficient would be to use a Lisp symbol (function or
variable name) as a translation key.

Re: Emacs i18n

[Jean-Christophe Helary]

> On Mar 8, 2019, at 7:29, Juri Linkov <juri@linkov.net> wrote:
> 
> The PO format is best suited for translation of one-liners like
> messages and menu items, but I doubt that the PO format would be the most efficient implementation for multi-line doc strings since gettext uses the whole text of the doc string as a key to translation.
> Whereas more efficient would be to use a Lisp symbol (function or variable name) as a translation key.

po4a is a commonly used perl utility that creates po files from a number of documentation formats including texinfo. The msgid is indeed the paragraph itself but nobody sees any "efficiency" issue in the process.

Since the emacs code is not a documentation format, there would be a need to find a different way to extract the doc strings, but using each doc string paragraph as a msgid is not a problem in itself.

Let's not forget that most if not all issues regarding formats and processes on the l10n side have mostly been solved decades ago.

I think what really needs to be discussed is:

• which strings do we extract
• how to rewrite the mix of code and strings
• how to extract the resulting strings
• how to process the translations for display in emacs


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Eli Zaretskii]

> From: Jean-Christophe Helary <brandelune@gmail.com>
> Date: Fri, 8 Mar 2019 10:48:46 +0900
> 
> I think what really needs to be discussed is:
> 
> • which strings do we extract
> • how to rewrite the mix of code and strings
> • how to extract the resulting strings
> • how to process the translations for display in emacs

Extraction is just a technicality, it can be done in either of several
possible ways.  We could use xgettext, or we could use a modification
of make-docfile (the latter is probably a must for collecting do
strings from C sources), or we could use po4a or something similar.
As long as the catalogs are PO files, we could even use a mix of
tools, if, for example, some of the tools is more convenient for Lisp,
but not for C.

And I don't understand what problems you see in the last item: what
should be done there other than display the translated string with
'message' or insert it into the *Help* buffer?

So I think you are bothered by stuff that is largely non-issues.  The
most important issues IMO are different: (a) what methodology of
extracting/marking translatable strings to choose so that this job
doesn't become infeasible; and (b) how to arrange the message catalogs
so that they will be easy to maintain and update, given the modular
nature of Emacs.  I think we should also take a better look at how the
built-in help facilities generate documentation and other displayable
strings from symbol names.  Macros such as define-minor-mode should
also be scrutinized to see if there are some special problems there.

Once this is done, the methodology decided, and the necessary tools
are available, the rest is just more or less mechanical work to
convert more and more parts of Emacs.

Re: Emacs i18n

[Jean-Christophe Helary]

> On Mar 8, 2019, at 17:08, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <brandelune@gmail.com>
>> Date: Fri, 8 Mar 2019 10:48:46 +0900
>> 
>> I think what really needs to be discussed is:
>> 
>> • which strings do we extract
>> • how to rewrite the mix of code and strings
>> • how to extract the resulting strings
>> • how to process the translations for display in emacs
> 
> Extraction is just a technicality, it can be done in either of several
> possible ways.

Sure. I just meant that l10n issues (is PO "efficiency", etc.) are already solved, but i18n in general has to be implemented from scratch.

> And I don't understand what problems you see in the last item: what
> should be done there other than display the translated string with
> 'message' or insert it into the *Help* buffer?

As I wrote above: we have to implement everything from scratch.

> So I think you are bothered by stuff that is largely non-issues.  The
> most important issues IMO are different: (a) what methodology of
> extracting/marking translatable strings to choose so that this job
> doesn't become infeasible;

That's my 3 first points elegantly combined into one :)

> and (b) how to arrange the message catalogs
> so that they will be easy to maintain and update, given the modular
> nature of Emacs.

I'm not sure what you mean in "how to arrange ..." Do you mean: how to provide the l10n packages to translator communities ?

>  I think we should also take a better look at how the
> built-in help facilities generate documentation and other displayable
> strings from symbol names.  Macros such as define-minor-mode should
> also be scrutinized to see if there are some special problems there.
> 
> Once this is done, the methodology decided, and the necessary tools
> are available, the rest is just more or less mechanical work to
> convert more and more parts of Emacs.

Can't we start with a survey of the strings we want extracted in a given number of emacs core packages ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Eli Zaretskii]

> From: Jean-Christophe Helary <brandelune@gmail.com>
> Date: Sat, 9 Mar 2019 00:11:24 +0900
> 
> > Extraction is just a technicality, it can be done in either of several
> > possible ways.
> 
> 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.

> > and (b) how to arrange the message catalogs
> > so that they will be easy to maintain and update, given the modular
> > nature of Emacs.
> 
> I'm not sure what you mean in "how to arrange ..." Do you mean: how to provide the l10n packages to translator communities ?

No, I mean how many catalogs should we have and what should be their
granularity.  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), and how to load catalogs on demand when the
corresponding code is loaded/executed.

> 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.

Re: Emacs i18n

[Jean-Christophe Helary]

> On Mar 9, 2019, at 5:11, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <brandelune@gmail.com>
>> Date: Sat, 9 Mar 2019 00:11:24 +0900
>> 
>>> Extraction is just a technicality, it can be done in either of several possible ways.
>> 
>> 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.

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.

>>> and (b) how to arrange the message catalogs so that they will be easy to maintain and update, given the modular nature of Emacs.
>> 
>> I'm not sure what you mean in "how to arrange ..." Do you mean: how to provide the l10n packages to translator communities ?
> 
> No, I mean how many catalogs should we have and what should be their granularity.

Isn't that related to the below item ?

> 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 ? 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.)

> 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" ?

>> 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.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Emacs i18n

[Eli Zaretskii]

> From: Jean-Christophe Helary <brandelune@gmail.com>
> 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.

Re: Emacs i18n

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> 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.

One catalog for the whole Emacs is not appropriate for packages with a
life outside Emacs core, like org or Tramp.

Best regards, Michael.

Re: Emacs i18n

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Jean-Christophe Helary <brandelune@gmail.com>,  emacs-devel@gnu.org
> Date: Sat, 09 Mar 2019 09:37:11 +0100
> 
> > 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.
> 
> One catalog for the whole Emacs is not appropriate for packages with a
> life outside Emacs core, like org or Tramp.

Yes, but the question still stands whether those packages which _are_
maintained only in the Emacs repository should have one catalog or
more than one, and if more than one, then at which granularity.

Re: Emacs i18n

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> Yes, but the question still stands whether those packages which _are_
> maintained only in the Emacs repository should have one catalog or
> more than one, and if more than one, then at which granularity.

Packages with an own subdirectory (f.e., gnus, vc) should have an own
catalog. Tramp + ange-ftp.el could get an own subdirectory + catalog as
well (these are 17 *.el files).

Best regards, Michael.

Re: Emacs i18n

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: brandelune@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 09 Mar 2019 12:27:04 +0100
> 
> > Yes, but the question still stands whether those packages which _are_
> > maintained only in the Emacs repository should have one catalog or
> > more than one, and if more than one, then at which granularity.
> 
> Packages with an own subdirectory (f.e., gnus, vc) should have an own
> catalog. Tramp + ange-ftp.el could get an own subdirectory + catalog as
> well (these are 17 *.el files).

So you are saying that we should have a single catalog for all the
other .el files, and load it unconditionally in every Emacs session?
That'd waste memory, no?  We have more than 1500 Lisp files in Emacs.

Re: Emacs i18n

[Paul Eggert]

Eli Zaretskii wrote:
> So you are saying that we should have a single catalog for all the
> other .el files, and load it unconditionally in every Emacs session?
> That'd waste memory, no?
Assuming we use GNU gettext, it'd consume virtual memory but not as much 
physical memory, as GNU gettext mmaps the message catalog (using PROT_READ so 
that it's read-only and the physical data can be shared). Only pages containing 
actual translations should need to be brought into physical memory (along with 
the indexes to these pages).

The total amount of virtual memory would depend on the catalog size. A 
reasonable upper bound for current Emacs master would be 61 MB (the sum of sizes 
of all of Emacs's .el files). Although 61 MB is nontrivial, there should be 
little trouble fitting it into virtual memory even on a 32-bit platform.

Re: Emacs i18n

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 9 Mar 2019 11:55:15 -0800
> 
> Eli Zaretskii wrote:
> > So you are saying that we should have a single catalog for all the
> > other .el files, and load it unconditionally in every Emacs session?
> > That'd waste memory, no?
> Assuming we use GNU gettext, it'd consume virtual memory but not as much 
> physical memory, as GNU gettext mmaps the message catalog (using PROT_READ so 
> that it's read-only and the physical data can be shared). Only pages containing 
> actual translations should need to be brought into physical memory (along with 
> the indexes to these pages).
> 
> The total amount of virtual memory would depend on the catalog size. A 
> reasonable upper bound for current Emacs master would be 61 MB (the sum of sizes 
> of all of Emacs's .el files). Although 61 MB is nontrivial, there should be 
> little trouble fitting it into virtual memory even on a 32-bit platform.

The same is true for the Lisp files themselves.  Yet we don't load
them all in advance, because that's simply not economical.

Re: Emacs i18n

[Paul Eggert]

Eli Zaretskii wrote:
>> The total amount of virtual memory would depend on the catalog size. A
>> reasonable upper bound for current Emacs master would be 61 MB (the sum of sizes
>> of all of Emacs's .el files). Although 61 MB is nontrivial, there should be
>> little trouble fitting it into virtual memory even on a 32-bit platform.

> The same is true for the Lisp files themselves.  Yet we don't load
> them all in advance, because that's simply not economical.

No, it would be quite economical if we put all the .elc files into one big file 
that was mmapped in and then used lazily (which is what GNU gettext does for 
message catalogs). Emacs doesn't do that because historically it developed 
another way to use .elc files, a way that is good enough in practice even if it 
might not be as efficient as the mmap approach.

The GNU gettext library was historically developed to use mmap, and is good 
enough in practice for Emacs as-is. None of the issues discussed in this thread 
mean that we should redesign the gettext library, or split up message catalogs 
only for performance reasons. On the contrary, splitting things up (or rewriting 
the gettext library in Elisp) is likely to make things slower.

Re: Emacs i18n

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> So you are saying that we should have a single catalog for all the
> other .el files, and load it unconditionally in every Emacs session?
> That'd waste memory, no?  We have more than 1500 Lisp files in Emacs.

I haven't said this. I have no strong opinion about the other lisp
files.

Best regards, Michael.

Re: Emacs i18n

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: brandelune@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 09 Mar 2019 21:04:43 +0100
> 
> > So you are saying that we should have a single catalog for all the
> > other .el files, and load it unconditionally in every Emacs session?
> > That'd waste memory, no?  We have more than 1500 Lisp files in Emacs.
> 
> I haven't said this. I have no strong opinion about the other lisp
> files.

Oh, I agree that Gnus should have only one catalog, as should Tramp,
Calc, Org, ERC, NXML, Rmail, etc.  IOW, if a package has several Lisp
files, it should still have no more than one catalog.

Re: Emacs i18n

[Paul Eggert]

Michael Albinus wrote:
> Packages with an own subdirectory (f.e., gnus, vc) should have an own
> catalog.

I'm not sure I agree.

Message catalogs are primarily of interest to translators and installers, not 
programmers. Assuming we're using the gettext machinery (a pretty safe 
assumption, as why reinvent the wheel?), the set of messages to be translated 
will be maintained automatically: programmers shouldn't care how many catalogs 
there are, or how they're updated.

Other GNU packages generally go with one large catalog, for several reasons. For 
example, translators can batch their work; similar translations can be shared 
more easily and reliably; and installation is simpler and a bit faster.

A few packages do have multiple catalogs. This is intended for convenience in 
installation, not for convenience to developers. For example, GNU gettext has 
two catalogs, one for the gettext runtime library (used by applications in 
production) and one for gettext tools (used by developers when extracting or 
doing translations). That way, operating systems packagers can install just the 
first message catalog on systems where users are not developers.

In practice, though, this multiple-catalog approach hasn't proved to be all that 
useful. Debian and Fedora both put the two gettext catalogs into one package. 
Debian has a package language-pack-fr-base that contains French translations for 
several core packages, including both gettext catalogs, and similarly for other 
languages. Fedora includes all translations of both gettext catalogs in its 
'gettext' package. So in hindsight, it seems to have been overkill for 'gettext' 
to have two translation catalogs.

With this in mind, I think it unlikely that OS packagers would find it useful 
for Emacs to maintain multiple message catalogs for each source subdirectory.

Re: Emacs i18n

[Eli Zaretskii]

> Cc: brandelune@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 9 Mar 2019 11:22:12 -0800
> 
> Other GNU packages generally go with one large catalog, for several reasons. For 
> example, translators can batch their work; similar translations can be shared 
> more easily and reliably; and installation is simpler and a bit faster.
> 
> A few packages do have multiple catalogs.

Any example of a package whose 90% gets loaded piecemeal on demand?
Out of ~500 packages that Emacs has, how many are loaded into our
"usual" session?  And if we don't load all of those 500, why should we
load their message catalogs?

This is one of those aspects that make Emacs so different from other
localized programs.  I think the difference really justifies
separating the catalogs by package.

Re: Emacs i18n

[Paul Eggert]

Eli Zaretskii wrote:
>> A few packages do have multiple catalogs.
> Any example of a package whose 90% gets loaded piecemeal on demand?

I'm not quite sure what you mean by "whose 90% gets loaded piecemail on demand". 
However, it's routine for a program to retrieve only a few translations from a 
much larger catalog, so that most of the catalog is not loaded into physical 
RAM. The GNU gettext library is tuned for this sort of thing, and I see no 
reason why Emacs would pose important performance challenges to it.

Re: Emacs i18n

[Michael Albinus]

Paul Eggert <eggert@cs.ucla.edu> writes:

Hi Paul,

> With this in mind, I think it unlikely that OS packagers would find it
> useful for Emacs to maintain multiple message catalogs for each source
> subdirectory.

There are packages which live outside Emacs. There are packages which
are also available as ELPA core packages. At least these packages need
their own catalog.

For all other packages I'm undecided.

Best regards, Michael.

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. ]]]

  > > Packages with an own subdirectory (f.e., gnus, vc) should have an own
  > > catalog.

  > I'm not sure I agree.

Let's start out without any particular rule about this, and let people
try various things.  That way we will work out what is useful.

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

Re: Emacs i18n

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 09 Mar 2019 22:09:09 -0500
> Cc: eliz@gnu.org, michael.albinus@gmx.de, brandelune@gmail.com,
> 	emacs-devel@gnu.org
> 
> Let's start out without any particular rule about this, and let people
> try various things.  That way we will work out what is useful.

Btw, translating messages also means that the likes of this:

  static bool
  set_message_1 (ptrdiff_t a1, Lisp_Object string)
  {
    [...]
    if (!NILP (BVAR (current_buffer, bidi_display_reordering)))
      bset_bidi_paragraph_direction (current_buffer, Qleft_to_right);

will need to depend on the current UI language, instead of being
hard-coded, so the value should be probably recorded in some file (the
message catalog?).  Likewise the direction of menu items and tool-bar
buttons, if/when we get to translating menus and the tool bar.

Re: Emacs i18n

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rms@gnu.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Fri, 08 Mar 2019 00:29:17 +0200
> 
> > We still should try to use .po files for them, if at all possible,
> > and perhaps also the gettext code that supports looking up strings
> > in .gmo catalogs generated from .po.
> 
> The PO format is best suited for translation of one-liners like
> messages and menu items, but I doubt that the PO format would be
> the most efficient implementation for multi-line doc strings since
> gettext uses the whole text of the doc string as a key to translation.

I'm not sure I understand why the length of the string is an important
factor here.  Can you explain?  If the problem is with the efficiency
of gettext implementation of indexing, then we could have our own
indexing method.

> Whereas more efficient would be to use a Lisp symbol (function or
> variable name) as a translation key.

A key other than the original string would mean abandoning the PO
format.  Any deviation from PO would mean major PITA for translation
teams, so we should make sure the reason for such a deviation is a
very good reason.  I'm not yet sure we have such a good reason.

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. ]]]

We can handle translating doc strings just like the other
translations.  Or we could have a special system for doc strings -- if
that proves more convenient.  Since doc strings are special in so many
ways, a special system might prove more convenient.  Or it might not.

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

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. ]]]

  > > I think it would be most natural to handle doc strings through
  > > a special mechanism.

  > Up to a point, perhaps.  We still should try to use .po files for
  > them, if at all possible, and perhaps also the gettext code that
  > supports looking up strings in .gmo catalogs generated from .po.

I agree completely.

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