i18n - Revisited

i18n - Revisited

[Fernando Botelho]

Hi everyone,

I have read many messages on the archive and talked extensively with a 
developer friend about this, so I think I understand that 
internationalization in the context of Emacs is extremely complex, as 
well as a very large job in terms of volume.

Having said that, I would like to know if beyond the compatibility with 
various character sets and the availability of the tutorial in other 
languages (and other i18n improvements which, not being a dev, I will 
probably not understand), has the i18n process stopped?

In other words, is there anyone currently working on additional i18n 
features for Emacs?

I ask because I might be able to help with translators, or in other 
ways, assuming I can connect the utility of the work with the project I 
am starting.

BTW, the project I am starting seeks to make Emacs and Emacspeak more 
accessible/understandable to non-technical users who are blind and speak 
either Portuguese, Spanish, French, or Arabic.

Thank you,

Fernando

Re: i18n - Revisited

[Paul Eggert]

On 04/26/2017 12:32 PM, Fernando Botelho wrote:
> has the i18n process stopped?

No, in the sense that Emacs development continues, and lots of the stuff 
being hacked on deals with i18n-related issues.

For your project I image that Emacs could be better i18nized, e.g., by 
translating at least the commonly-used diagnostics to Spanish. This 
would be a nontrivial bit if work but if someone wants to volunteer, 
it'd be a good thing to have.

Re: i18n - Revisited

[Jean-Christophe Helary]

More l10n than i18n, may I suggest that more languages group focus on creating processes that allow easier/faster translation of the Emacs manual and the Elisp reference? If such projects could be visible from the Emacs page we'd certainly have more participants... (I'm a member of traduc.org, in charge of the French translation).

Jean-Christophe Helary 

> On Apr 27, 2017, at 5:22, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> On 04/26/2017 12:32 PM, Fernando Botelho wrote:
>> has the i18n process stopped?
> 
> No, in the sense that Emacs development continues, and lots of the stuff being hacked on deals with i18n-related issues.
> 
> For your project I image that Emacs could be better i18nized, e.g., by translating at least the commonly-used diagnostics to Spanish. This would be a nontrivial bit if work but if someone wants to volunteer, it'd be a good thing to have.

Re: i18n - Revisited

[Fernando Botelho]

Thanks Jean-Christophe and Paul for your responses.

It is good to know that the i18n process is on-going. Is this "more 
languages group" operational via e-mail list? how can I join?

I want to ask questions like:

Are there plans for l10n of the interface strings and command names, or 
is this postponed for now because of complexity?

For areas where l10n is already happening, where can I join the effort, 
i.e. are there web interfaces where strings are shown and translations 
entered, or gettext/.POT files on a git repository somewhere?

Are there "how to" guides for non-technical translators who want to help?

I suspect many of my questions are too basic and may irritate people on 
this list.

Best,

Fernando

Re: i18n - Revisited

[Jean-Christophe Helary]

> On Apr 27, 2017, at 21:56, Fernando Botelho <Fernando.Botelho@F123.org> wrote:
> 
> Thanks Jean-Christophe and Paul for your responses.
> 
> It is good to know that the i18n process is on-going. Is this "more languages group" operational via e-mail list? how can I join?

If that's a question related to my answer, I have no idea :) I know about the French group that handles GNU programs, but I don't know if such groups exist in other languages.

> Are there plans for l10n of the interface strings and command names, or is this postponed for now because of complexity?

I participated to a discussion here about that a few years ago and the answer I got was "people who use emacs know English (or should) so there is no need for l10n in the UI"...

> For areas where l10n is already happening, where can I join the effort, i.e. are there web interfaces where strings are shown and translations entered, or gettext/.POT files on a git repository somewhere?

As far as I can tell, this is *not* happening. You should focus on translating documentation first, the Elisp reference, the Emacs manual, etc. Use po4a to get PO files from the texi sources and then use the process you prefer to translate that. I personally have created a collaborative translation project for the elisp reference, using OmegaT as the client. It is not progressing super fast because I'm the only one working on it. If you want to check it it's here:

https://github.com/suzume/emacslispref

If you don't know how to use OmegaT, it won't be of much help though. OmegaT is a free translation tool for professional translators.

> Are there "how to" guides for non-technical translators who want to help?

The problem with "non technical" translators is that then need to be minimally technical to at least understand emacs. I really don't suggest you get the stuff translated by people who don't at least have a minimal knowledge of emacs.

Jean-Christophe 

Re: i18n - Revisited

[Fernando Botelho]

Thanks Jean-Christophe, this is very helpful.

"If that's a question related to my answer, I have no idea :) I know 
about the French group that handles GNU programs, but I don't know if 
such groups exist in other languages."

Ok. it sounds like it is all fairly ad hoc, if that is the right 
expression. If anyone wants to do this, they have to figure out their 
own infrastructure and process.

"I participated to a discussion here about that a few years ago and the 
answer I got was "people who use emacs know English (or should) so there 
is no need for l10n in the UI"..."

Sad. There is maybe a billion persons around the world that deserve and 
could access the productivity of Emacs and lack the language skill to 
work in English.

I recognize the attitude and short-sightedness, I was just not expecting 
to find it here.

Could this be just fear of the technical complexity of messing with that 
side of the code? Probably a combination of bug-avoidance and a sincere 
feeling that this would be a waste of time.

"As far as I can tell, this is *not* happening. You should focus on 
translating documentation first, the Elisp reference, the Emacs manual, 
etc. Use po4a to get PO files from the texi sources and then use the 
process you prefer to translate that. I personally have created a 
collaborative translation project for the elisp reference, using OmegaT 
as the client. It is not progressing super fast because I'm the only one 
working on it."

I will look into this. Thank you, it is much better than starting from 
scratch.

"The problem with "non technical" translators is that then need to be 
minimally technical to at least understand emacs. I really don't suggest 
you get the stuff translated by people who don't at least have a minimal 
knowledge of emacs."

Thank you.

I now have some difficult decisions to make. GNU Emaccs is the best 
choice, given how seriously this group takes licensing, but the point of 
my project is to popularize powerful free tools among non-technical 
users for whom they could have a huge impact, such as the blind. But it 
is hard enough to convince people to adopt an entirely different working 
paradigm, i.e. interface, now I have to also convince them to adopt a 
new language? This essentially means keeping this tool reserved for a 
small fraction of the intellectual elites in each developing country. It 
is not exactly inspiring to work towards keeping the status quo.

Fernando


On 04/27/2017 12:07 PM, Jean-Christophe Helary wrote:
>> On Apr 27, 2017, at 21:56, Fernando Botelho <Fernando.Botelho@F123.org> wrote:
>>
>> Thanks Jean-Christophe and Paul for your responses.
>>
>> It is good to know that the i18n process is on-going. Is this "more languages group" operational via e-mail list? how can I join?
> If that's a question related to my answer, I have no idea :) I know about the French group that handles GNU programs, but I don't know if such groups exist in other languages.
>
>> Are there plans for l10n of the interface strings and command names, or is this postponed for now because of complexity?
> I participated to a discussion here about that a few years ago and the answer I got was "people who use emacs know English (or should) so there is no need for l10n in the UI"...
>
>> For areas where l10n is already happening, where can I join the effort, i.e. are there web interfaces where strings are shown and translations entered, or gettext/.POT files on a git repository somewhere?
> As far as I can tell, this is *not* happening. You should focus on translating documentation first, the Elisp reference, the Emacs manual, etc. Use po4a to get PO files from the texi sources and then use the process you prefer to translate that. I personally have created a collaborative translation project for the elisp reference, using OmegaT as the client. It is not progressing super fast because I'm the only one working on it. If you want to check it it's here:
>
> https://github.com/suzume/emacslispref
>
> If you don't know how to use OmegaT, it won't be of much help though. OmegaT is a free translation tool for professional translators.
>
>> Are there "how to" guides for non-technical translators who want to help?
> The problem with "non technical" translators is that then need to be minimally technical to at least understand emacs. I really don't suggest you get the stuff translated by people who don't at least have a minimal knowledge of emacs.
>
> Jean-Christophe

Re: i18n - Revisited

[Jean-Christophe Helary]

> On Apr 28, 2017, at 1:24, Fernando Botelho <Fernando.Botelho@F123.org> wrote:
> 
> I now have some difficult decisions to make. GNU Emaccs is the best choice, given how seriously this group takes licensing, but the point of my project is to popularize powerful free tools among non-technical users for whom they could have a huge impact, such as the blind.

Technical people (even blind) already have ccess to emacs. I'm not sure non technical people have a lot of uses for emacs, so maybe you could focus on other GNU software, like Nano etc.

> But it is hard enough to convince people to adopt an entirely different working paradigm, i.e. interface, now I have to also convince them to adopt a new language? This essentially means keeping this tool reserved for a small fraction of the intellectual elites in each developing country.

UI l10n requires a complex infrastructure that presently does not exist for emacs. The best you can do now is provide access to the emacs documentation, which would be a huge thing anyway. UI terms can be considered arbitrary and once you start using them (after reading about them in a translated doc set) they can be seen as some sort of "code". No need to worry about the intellectual "elite". Even partial l10n can do a lot to bridge linguistic gaps.

Jean-Christophe 

Re: i18n - Revisited

[Fernando Botelho]

I agree with you overall. Not the scenario I had in mind initially, but 
a worthy cause nonetheless.

I did not mean to imply that no blind person had access to Emacs, just 
that those that currently use it are unusually technically smart or 
unusually well-connected and informed, or both.

I do disagree that non-technical people would not have use for Emacs. 
Someone involved in translations, writing, project management, or any 
number of other tasks could really benefit from Emacs. Sadly for those 
of us who are not technical, the tipical Emacs user is not terribly good 
in sales and marketing. I could have saved myself countless wasted hours 
in the last two decades, had someone I met in college been more pushy 
about the superiority of his digital environment.

Not his fault, of course, but I will try to do some of that "selling", 
thus the concern with language.

Thanks again for your guidance,

Fernando


On 04/27/2017 01:33 PM, Jean-Christophe Helary wrote:
>> On Apr 28, 2017, at 1:24, Fernando Botelho <Fernando.Botelho@F123.org> wrote:
>>
>> I now have some difficult decisions to make. GNU Emaccs is the best choice, given how seriously this group takes licensing, but the point of my project is to popularize powerful free tools among non-technical users for whom they could have a huge impact, such as the blind.
> Technical people (even blind) already have ccess to emacs. I'm not sure non technical people have a lot of uses for emacs, so maybe you could focus on other GNU software, like Nano etc.
>
>> But it is hard enough to convince people to adopt an entirely different working paradigm, i.e. interface, now I have to also convince them to adopt a new language? This essentially means keeping this tool reserved for a small fraction of the intellectual elites in each developing country.
> UI l10n requires a complex infrastructure that presently does not exist for emacs. The best you can do now is provide access to the emacs documentation, which would be a huge thing anyway. UI terms can be considered arbitrary and once you start using them (after reading about them in a translated doc set) they can be seen as some sort of "code". No need to worry about the intellectual "elite". Even partial l10n can do a lot to bridge linguistic gaps.
>
> Jean-Christophe

Re: i18n - Revisited

[Eli Zaretskii]

> From: Fernando Botelho <Fernando.Botelho@F123.org>
> Date: Thu, 27 Apr 2017 13:24:20 -0300
> 
> "I participated to a discussion here about that a few years ago and the 
> answer I got was "people who use emacs know English (or should) so there 
> is no need for l10n in the UI"..."
> 
> Sad. There is maybe a billion persons around the world that deserve and 
> could access the productivity of Emacs and lack the language skill to 
> work in English.
> 
> I recognize the attitude and short-sightedness, I was just not expecting 
> to find it here.

Beware: you are making conclusions from a single citation out of what
was a very long discussion with different issues brought up.  I
suggest that you read that discussion yourself, before making up your
mind.

AFAIR, the main issue was not as expressed by the above citation, but
some fundamental problems with localizing Emacs.  Some of those
problems, off the top of my head:

 . command names are deliberately English, and probably always will be
 . built-in documentation is partially automatically produced from the
   command and variable names, and from the code which implements them
   (e.g., some UI elements visible on display come directly from
   symbol names, which are in English)
 . part of the doc strings are in C sources, part in Lisp
 . l10n of unbundled packages presents additional issues, out of
   control for the project
 . Emacs has an awful lot of doc strings, so translating them, even
   after the other problems are solved, is a humongously large job

The project's position is that work in these areas is very welcome,
but it's quite clear that a group of very motivated individuals will
have to materialize in order to make it happen.

Re: i18n - Revisited

[Fernando Botelho]

Thanks for the clarification. I am sorry for my unfair characterization 
based on incomplete information.

I will look for a way to contribute somehow.

Fernando


On 04/27/2017 05:20 PM, Eli Zaretskii wrote:
>> From: Fernando Botelho <Fernando.Botelho@F123.org>
>> Date: Thu, 27 Apr 2017 13:24:20 -0300
>>
>> "I participated to a discussion here about that a few years ago and the
>> answer I got was "people who use emacs know English (or should) so there
>> is no need for l10n in the UI"..."
>>
>> Sad. There is maybe a billion persons around the world that deserve and
>> could access the productivity of Emacs and lack the language skill to
>> work in English.
>>
>> I recognize the attitude and short-sightedness, I was just not expecting
>> to find it here.
> Beware: you are making conclusions from a single citation out of what
> was a very long discussion with different issues brought up.  I
> suggest that you read that discussion yourself, before making up your
> mind.
>
> AFAIR, the main issue was not as expressed by the above citation, but
> some fundamental problems with localizing Emacs.  Some of those
> problems, off the top of my head:
>
>   . command names are deliberately English, and probably always will be
>   . built-in documentation is partially automatically produced from the
>     command and variable names, and from the code which implements them
>     (e.g., some UI elements visible on display come directly from
>     symbol names, which are in English)
>   . part of the doc strings are in C sources, part in Lisp
>   . l10n of unbundled packages presents additional issues, out of
>     control for the project
>   . Emacs has an awful lot of doc strings, so translating them, even
>     after the other problems are solved, is a humongously large job
>
> The project's position is that work in these areas is very welcome,
> but it's quite clear that a group of very motivated individuals will
> have to materialize in order to make it happen.