Why emacs have not native language menu

Why emacs have not native language menu

[lu]

Today I tried vim 7.1,It have native language menu.
Why emacs only have English menu?
There is a "Please support the vim's develop!" in The vim welcome message.
I think emacs should take this message in the welcome message also.

Re: Why emacs have not native language menu

[Eli Zaretskii]

> Date: Mon, 23 Jul 2007 21:03:30 +0900
> From: "lu@luxdo.jp" <lu@luxdo.jp>
> 
> Today I tried vim 7.1,It have native language menu.
> Why emacs only have English menu?

Because Emacs is a much more complex program, and therefore adding
localization support to it is a much harder job.  And because no one
volunteered to do that job.

Re: Why emacs have not native language menu

[lu]

Eli Zaretskii さんは書きました:
>> Date: Mon, 23 Jul 2007 21:03:30 +0900
>> From: "lu@luxdo.jp" <lu@luxdo.jp>
>>
>> Today I tried vim 7.1,It have native language menu.
>> Why emacs only have English menu?
>>     
>
> Because Emacs is a much more complex program, and therefore adding
> localization support to it is a much harder job.  And because no one
> volunteered to do that job.
>
>
> _______________________________________________
> help-gnu-emacs mailing list
> help-gnu-emacs@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
>
>   
I think this is the real reason.

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 24 juil. 07, at 04:33, Eli Zaretskii wrote:

>> Date: Mon, 23 Jul 2007 21:03:30 +0900
>> From: "lu@luxdo.jp" <lu@luxdo.jp>
>>
>> Today I tried vim 7.1,It have native language menu.
>> Why emacs only have English menu?
>
> Because Emacs is a much more complex program, and therefore adding
> localization support to it is a much harder job.  And because no one
> volunteered to do that job.

There are plenty of applications that are more complex than emacs and  
they still had a correct localization.

What is the technical issue with emacs ?

FWIW, there were discussions in the past on the Aquamacs list to work  
on localizing the software but it was more the lack of specialists  
than the sheer complexity of the task that aborted the discussions.

Could anyone provide guidance here ?


Jean-Christophe Helary

Re: Why emacs have not native language menu

[Nick Roberts]

 > FWIW, there were discussions in the past on the Aquamacs list to work  
 > on localizing the software but it was more the lack of specialists  
 > than the sheer complexity of the task that aborted the discussions.

I don't see how it could be any easier to add localization support to 
Aquamacs since it is just an adaption of Emacs.  The lack of specialists
presumably also implies that no-one could gauge the actual complexity of
the task.

 > Could anyone provide guidance here ?

I'm not an expert but the strings used for menus are stored in many different
places.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Emacs localization (Re: Why emacs have not native language menu)

[Jean-Christophe Helary]

On 24 juil. 07, at 09:36, Nick Roberts wrote:

>> FWIW, there were discussions in the past on the Aquamacs list to work
>> on localizing the software but it was more the lack of specialists
>> than the sheer complexity of the task that aborted the discussions.
>
> I don't see how it could be any easier to add localization support to
> Aquamacs since it is just an adaption of Emacs.  The lack of  
> specialists
> presumably also implies that no-one could gauge the actual  
> complexity of
> the task.

I am not suggesting that it is easier with Aquamacs, only that we  
discussed similar issues there too.


>> Could anyone provide guidance here ?
>
> I'm not an expert but the strings used for menus are stored in many  
> different
> places.

Yes. I could see that myself. Indeed, all the strings are in the  
code. All the functions are documented in English in their code and  
to get a proper localization of that, or at least of a basic core  
features (like functions that available from the UI for a start)  
would require to remove all strings and put them in locale separated  
files that emacs would load based on the environment. Is that correct ?

Are there already existing systems that provide a way to do that  
relatively effortlessly (I am not talking about the translation  
effort, but about the string isolation effort of course) ?


Jean-Christophe Helary

Re: Why emacs have not native language menu

[Stefan Monnier]

>>> Today I tried vim 7.1,It have native language menu.
>>> Why emacs only have English menu?

Because nobody has gone through the trouble of adding localization yet.
As for why, I would guess it's a mix of difficulty (need someone who
understand enough of Emacs and of localization to deal with it both at the
C and the Lisp level), together with the fact that it's bound to stay
partial:
- many elements are sufficiently dynamic that it's going to be
  difficult to add support to translate them.
- an important side of Emacs is that it exposes a lot of its internals: many
  important commands are reached via M-x where the term you enter is the
  name of a function (i.e. not quite a string), and all the online help
  refers to those things as well.

Still, it's quite doable.  The only difficulty is to have the courage to
start with something small and convince other people that it's worthwhile to
go down that road.


        Stefan

Re: Why emacs have not native language menu

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

>> Why emacs only have English menu?
>
> Because Emacs is a much more complex program, and therefore adding
> localization support to it is a much harder job.  And because no one
> volunteered to do that job.

Another cause is that emacs has a precise terminology. To blur it would
be a source of confusion.

Also, emacs has a gazillion extension packages developed mostly by one
author each and those won't be localized anyway. IMHO a program that
uses one language and the same terminology everywhere is much better
than a mixture of (possibly bad) localizations and original content.

And finally I think there's no real demand for localizations. The
average emacs user is a techie, a programer or maybe an author -- at
least somebody who needs to edit huge amounts of text (no, not M$
Word). Gretchen Müller won't fetch her mail with Gnus anyway, even
though it was localized.

Just my 2 cents...

Bye,
Tassilo
-- 
A child of five could understand this! Fetch me a child of five!

Re: Emacs localization (Re: Why emacs have not native language menu)

[Jason Rumney]

On 24 Jul, 02:00, Jean-Christophe Helary <fus...@mx6.tiki.ne.jp>
wrote:
> On 24 juil. 07, at 09:36, Nick Roberts wrote:

> Yes. I could see that myself. Indeed, all the strings are in the
> code. All the functions are documented in English in their code and
> to get a proper localization of that, or at least of a basic core
> features (like functions that available from the UI for a start)
> would require to remove all strings and put them in locale separated
> files that emacs would load based on the environment. Is that correct ?

Locale specific files is the conventional way of dealing with
localization, but Emacs is extensible, which means that  we need to
come up with a design that is also extensible. Very few applications
have dynamic menus the way that Emacs does, mostly they are static and
defined in resource files where such conventional localization is
simple.

Re: Emacs localization (Re: Why emacs have not native language menu)

[Lennart Borgman (gmail)]

> All the functions are documented in English in their code and to get a 
> proper localization of that, or at least of a basic core features (like 
> functions that available from the UI for a start) would require to 
> remove all strings and put them in locale separated files that emacs 
> would load based on the environment. Is that correct ?

You do not have to remove the strings from the function. You can change 
them at when they are going to be used in the help system instead.

Re: Why emacs have not native language menu

[Peter Dyballa]

Am 24.07.2007 um 02:17 schrieb Jean-Christophe Helary:

> What is the technical issue with emacs ?

The texts are spread over hundred and more files. It's not only menu  
entries and menu titles, it's also necessary to translate the  
customisation buffers, the description of functions and variables.

I am translating calendar into German since decades and quite  
complete ...


And once the act of translation is achieved: how do you describe a  
problem with entry 5 of menu 3? By using the French names? By  
counting? What when the order is changed? What when someone decides,  
according to writing direction, to order the menus from right to left?

--
Greetings

   Pete

“Computers are good at following instructions, but not at reading  
your mind.”
    - D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 24 juil. 07, at 19:05, Peter Dyballa wrote:

>
> Am 24.07.2007 um 02:17 schrieb Jean-Christophe Helary:
>
>> What is the technical issue with emacs ?
>
> The texts are spread over hundred and more files. It's not only  
> menu entries and menu titles, it's also necessary to translate the  
> customisation buffers, the description of functions and variables.

This is not really a technical issue. Because there are ways to  
identify the strings to localize. I am more specifically asking about  
this.

> And once the act of translation is achieved: how do you describe a  
> problem with entry 5 of menu 3? By using the French names? By  
> counting? What when the order is changed? What when someone  
> decides, according to writing direction, to order the menus from  
> right to left?

I understand what you are saying but that is exactly the case for all  
the other localized software packages.

GNU has developped gettext but one of the flagship applications of  
the GNU project is not localized at all...


Jean-Christophe Helary

Re: Why emacs have not native language menu

[Peter Dyballa]

Am 24.07.2007 um 13:05 schrieb Jean-Christophe Helary:

> GNU has developped gettext but one of the flagship applications of  
> the GNU project is not localized at all...

These other already localised applications like GCC were designed for  
this ...

--
Greetings

   Pete

Bigamy is having one wife too many. Monogamy is the same.     — Oscar  
Wilde

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 24 juil. 07, at 16:41, Tassilo Horn wrote:
>>> Why emacs only have English menu?
>>
>> Because Emacs is a much more complex program, and therefore adding
>> localization support to it is a much harder job.  And because no one
>> volunteered to do that job.
>
> Another cause is that emacs has a precise terminology. To blur it  
> would
> be a source of confusion.
>
> Also, emacs has a gazillion extension packages developed mostly by one
> author each and those won't be localized anyway. IMHO a program that
> uses one language and the same terminology everywhere is much better
> than a mixture of (possibly bad) localizations and original content.

Do you actually use localized applications or do you just suppose  
that localizers are less good at doing their jobs then coders at  
doing theirs ?

> And finally I think there's no real demand for localizations. The
> average emacs user is a techie, a programer or maybe an author -- at
> least somebody who needs to edit huge amounts of text

And that means that technical writers who use OpenOffice can't be  
bothered with localizations ? Or that techies who use Debian don't  
give a damn about localization ? Who are you trying to convince here ?


Jean-Christophe Helary

Re: Emacs localization (Re: Why emacs have not native language menu)

[Jean-Christophe Helary]

On 24 juil. 07, at 16:48, Jason Rumney wrote:

> On 24 Jul, 02:00, Jean-Christophe Helary <fus...@mx6.tiki.ne.jp>
> wrote:
>> On 24 juil. 07, at 09:36, Nick Roberts wrote:
>
>> Yes. I could see that myself. Indeed, all the strings are in the
>> code. All the functions are documented in English in their code and
>> to get a proper localization of that, or at least of a basic core
>> features (like functions that available from the UI for a start)
>> would require to remove all strings and put them in locale separated
>> files that emacs would load based on the environment. Is that  
>> correct ?
>
> Locale specific files is the conventional way of dealing with
> localization, but Emacs is extensible, which means that  we need to
> come up with a design that is also extensible. Very few applications
> have dynamic menus the way that Emacs does, mostly they are static and
> defined in resource files where such conventional localization is
> simple.

What is the technical difference with the extensibility of emacs and  
version upgrades or plugins in other apps ?

I don't see any. And the common issue is that localizers have to keep  
up with the dynamic in both cases.

Jean-Christophe Helary

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 24 juil. 07, at 20:12, Peter Dyballa wrote:

>
> Am 24.07.2007 um 13:05 schrieb Jean-Christophe Helary:
>
>> GNU has developped gettext but one of the flagship applications of  
>> the GNU project is not localized at all...
>
> These other already localised applications like GCC were designed  
> for this ...

Ok, so can we come up with a design for emacs that does not have to  
take gettext into account ?


Jean-Christophe Helary

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Today I tried vim 7.1,It have native language menu.
>>>> Why emacs only have English menu?
>
> Because nobody has gone through the trouble of adding localization yet.
> As for why, I would guess it's a mix of difficulty (need someone who
> understand enough of Emacs and of localization to deal with it both at the
> C and the Lisp level), together with the fact that it's bound to stay
> partial:
> - many elements are sufficiently dynamic that it's going to be
>   difficult to add support to translate them.
> - an important side of Emacs is that it exposes a lot of its internals: many
>   important commands are reached via M-x where the term you enter is the
>   name of a function (i.e. not quite a string), and all the online help
>   refers to those things as well.
>
> Still, it's quite doable.  The only difficulty is to have the courage to
> start with something small and convince other people that it's worthwhile to
> go down that road.

That's the problem.  I don't think localization is a good thing at all.

Of course, as anybody I'd prefer to use software that speaks to me in
a language I understand, but if the language of the author of the
software is in the list of languages I understand, I prefer to use
that software in the author's language, because it will be clearer and
much less risky.  Also, when software is translated (you can take
MacOS and MacOSX as very bad examples. I mean the translation is
almost perfect, but the result is awful), you cannot help the users
anymore.  Pathnames change, program names changes, menu, buttons,
everything.  You can't understand the error message anymore (I have to
translate them back from my native tongue to English to understand
them! etc).

Of course, we all know that for a corporation market division is very
good (it allows them to put higher prices in the submarkets).  But for
users these translations  is costly in more than one way.



In any case we are in front of an important dilema. On one side, it
would be very nice if every body spoke the same language and used the
same emacs.  But on the other side, it would be too risky, as risky as
when every body uses the same MS-Word.


My advice would be that if you feel you have the energy to do such a
thing as translating emacs, you should rather work toward singularity,
because then you could let the AI do the translation for you.  It
should be more interesting to work ten years on AI than on
translating.  Look at Apple, they've been translating their OS for
almost 30 years, and their current computers is not significantly
better or even different than what they had in 1984.  (Some benchmarks
tend to show that a Mac+ with 6.0.8 is even better than current
systems).


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Emacs localization (Re: Why emacs have not native language menu)

[Harald Hanche-Olsen]

+ Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>:

| What is the technical difference with the extensibility of emacs and
| version upgrades or plugins in other apps ?

Emacs is very old and was never designed for localization.  Of course,
localization support can be added in principle, but it's probably not
a small job.  Neither is it medium sized, if you get my drift.

| I don't see any. And the common issue is that localizers have to keep
| up with the dynamic in both cases.

I expect the problem is an order of magnitude larger with emacs:  If
you include all the contributed elisp code, the number of strings that
would need localization and translation is absolutely huge.

I don't say it can't be done, but it is very unlikely to happen unless
a group of dedicated and well qualified individuals are willing and
able to donate a substantial amount of time to the project.

Did I hear you volunteer?  Good luck!

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
  when there is no ground whatsoever for supposing it is true.
  -- Bertrand Russell

Re: Emacs localization (Re: Why emacs have not native language menu)

[Jason Rumney]

On 24 Jul, 12:19, Jean-Christophe Helary <fus...@mx6.tiki.ne.jp>
wrote:

> What is the technical difference with the extensibility of emacs and
> version upgrades or plugins in other apps ?

Version upgrades aren't really the same thing at all, but looking at
how apps with plugins that add things to the menu do things might give
a good starting point for anyone interested in taking on this job.

Re: Why emacs have not native language menu

[David Hansen]

On Tue, 24 Jul 2007 20:12:39 +0900 Jean-Christophe Helary wrote:

> And that means that technical writers who use OpenOffice can't be
> bothered with localizations?

Technical writers use (La)TeX or troff.

David

Re: Emacs localization (Re: Why emacs have not native language menu)

[Jean-Christophe Helary]

On 24 juil. 07, at 20:35, Harald Hanche-Olsen wrote:

> Emacs is very old and was never designed for localization.  Of course,
> localization support can be added in principle, but it's probably not
> a small job.  Neither is it medium sized, if you get my drift.

Of course. But there is a tutorial, there are manuals there is a  
basic core GUI. That makes a set of a relatively limited scope, and  
as far as I know most of the "external" data already has translation.

So I think the actual scope of the work is actually much smaller than  
most people imagine. And _because_ emacs is extensible it is actually  
possible to consider each major part included in a release as one  
localization project of its own.

In the end, it is really a matter of finding a system and about  
asking developers to stick to that system, just like they do when  
they write documentation for their code.

> I expect the problem is an order of magnitude larger with emacs:  If
> you include all the contributed elisp code, the number of strings that
> would need localization and translation is absolutely huge.

I think you underestimate the will of localizers. If there is a  
system available for localizers who may not have the coding power to  
actually create that system, they'll flock in and organize  
localization/translation/proofreading/delivery themselves.

> I don't say it can't be done, but it is very unlikely to happen unless
> a group of dedicated and well qualified individuals are willing and
> able to donate a substantial amount of time to the project.
>
> Did I hear you volunteer?  Good luck!

I would if a reasonably simple system exist. I am a translator by  
trade, not a coder.


Jean-Christophe Helary

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 24 juil. 07, at 20:29, Pascal Bourguignon wrote:
> Of course, as anybody I'd prefer to use software that speaks to me in
> a language I understand, but if the language of the author of the
> software is in the list of languages I understand, I prefer to use
> that software in the author's language, because it will be clearer and
> much less risky.  Also, when software is translated (you can take
> MacOS and MacOSX as very bad examples. I mean the translation is
> almost perfect, but the result is awful), you cannot help the users
> anymore.  Pathnames change, program names changes, menu, buttons,
> everything.  You can't understand the error message anymore (I have to
> translate them back from my native tongue to English to understand
> them! etc).

You need to use more localized software maybe. You'll notice that  
there are plenty of locale based communities that provide support,  
tutorials, code etc.

> Of course, we all know that for a corporation market division is very
> good (it allows them to put higher prices in the submarkets).  But for
> users these translations  is costly in more than one way.

I fail to see the rationale behind this opinion.

> My advice would be that if you feel you have the energy to do such a
> thing as translating emacs, you should rather work toward singularity,
> because then you could let the AI do the translation for you.  It
> should be more interesting to work ten years on AI than on
> translating.

No because localization of free software is part of the computer  
literacy project that is included _within_ the free software project.

There will always be new people who need to start from the lowest  
step. It is useless to find an all-encompassing solution that will  
intellectually benefit a few members of the elite programming  
community will leaving the others spoon-fed and unable to climb that  
very first step.

>   Look at Apple, they've been translating their OS for
> almost 30 years, and their current computers is not significantly
> better or even different than what they had in 1984.  (Some benchmarks
> tend to show that a Mac+ with 6.0.8 is even better than current
> systems).

That is a possibility but obviously there are much more Japanese or  
French people who use their software now than then.

What good is a software package if it can't be used by linguistically  
challenged people ?

Jean-Christophe Helary

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 24 juil. 07, at 20:53, David Hansen wrote:

> On Tue, 24 Jul 2007 20:12:39 +0900 Jean-Christophe Helary wrote:
>
>> And that means that technical writers who use OpenOffice can't be
>> bothered with localizations?
>
> Technical writers use (La)TeX or troff.

I have never seen an engine maintenance manual written in Latex. Have  
you ?

I have never seen an ISO 9001 document written in Latex. Have you ?

I think you have a very partial view of what technical writing means.

Can we return to discussing localizations ?

Jean-Christophe Helary

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

> On 24 juil. 07, at 19:05, Peter Dyballa wrote:
>
>>
>> Am 24.07.2007 um 02:17 schrieb Jean-Christophe Helary:
>>
>>> What is the technical issue with emacs ?
>>
>> The texts are spread over hundred and more files. It's not only
>> menu entries and menu titles, it's also necessary to translate the
>> customisation buffers, the description of functions and variables.
>
> This is not really a technical issue. Because there are ways to
> identify the strings to localize. I am more specifically asking about
> this.
>
>> And once the act of translation is achieved: how do you describe a
>> problem with entry 5 of menu 3? By using the French names? By
>> counting? What when the order is changed? What when someone
>> decides, according to writing direction, to order the menus from
>> right to left?
>
> I understand what you are saying but that is exactly the case for all
> the other localized software packages.
>
> GNU has developped gettext but one of the flagship applications of
> the GNU project is not localized at all...

But emacs is not an application!

emacs is a programming language with a library for textual user interfaces.

Asking for a localization of emacs is the same as asking for a
localization of C++.  Where do you start, and where do you stop???



The only realistic thing you could do, is if you are developing an
application in emacs (let say a new mail user agent), to localize this
application.  


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best." -- Frank Zappa

Re: Why emacs have not native language menu

[Tassilo Horn]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

Hi Jean-Christophe,

>> Also, emacs has a gazillion extension packages developed mostly by
>> one author each and those won't be localized anyway. IMHO a program
>> that uses one language and the same terminology everywhere is much
>> better than a mixture of (possibly bad) localizations and original
>> content.
>
> Do you actually use localized applications

No, but my girlfriend does. And If I use her computer I'm literally lost
in translation. Not that I didn't understand German (that's my native
language), but because a lot of terms cannot be sensibly translated.

Let's take "Kill Buffer" as an example. That would be "Töte
Zwischenspeicher" in German or "tuer cet amortisseur" in French if you
translate it literally. Ok, literal translation won't be done by good
localizers, but it's really hard to translate a concept like "killing"
in emacs consistently.

> or do you just suppose that localizers are less good at doing their
> jobs then coders at doing theirs?

No, I'm just saying that authors of extension packages won't localize
their packages because they don't know all required languages. And it
won't be possible in the general case to find volunteers who do it for
them.

>> And finally I think there's no real demand for localizations. The
>> average emacs user is a techie, a programer or maybe an author -- at
>> least somebody who needs to edit huge amounts of text
>
> And that means that technical writers who use OpenOffice can't be
> bothered with localizations?

OO.org is not mainly for techies, but for anyone using a computer to
write a letter for example. So it simply has to be localized to be
useful for the average user.

> Who are you trying to convince here?

I'm just saying that it's not worth it. It may be possible somehow to
implement the technical infrastructure, but I don't think there are
enough translators who are willing to create translations.

Bye,
Tassilo

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:
> [...]
> That is a possibility but obviously there are much more Japanese or
> French people who use their software now than then.

Yes, applications.


> What good is a software package if it can't be used by linguistically
> challenged people ?

Linguistically challenged people just cannot program.

You cannot translate programming languages.  This has been tried
several times, BEFORE the Internet existed (eg BASICOIS, a Basic in
French, there was also a Pascal in French, and I bet a number of
variations in other languages).  All these experiment failed, because
programs must be readable to be useful, and French is readably only by
French people.  Pascal is readable by all programmers!

Nowadays, with the Internet and the worldwide job market, it's just
impossible to translate a programming language.  And this is what emacs is.



Now if you implement an application in emacs you may try to proposed
localized versions.  But there are very few applications in emacs,
most emacs software keeps the powerful link between the programming
environment and the functionalities provided.  Does anybody know an
emacs applications where you can do _everything_ only using menus and
buttons?  Or where you would _want_ to do everything that way? 


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.

Re: Why emacs have not native language menu

[Thien-Thi Nguyen]

() Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
() Tue, 24 Jul 2007 20:21:04 +0900

   Ok, so can we come up with a design for emacs that does not
   have to take gettext into account ?

i think it is unlikely we (the participants of this thread) can
come up w/ a design as you suggest.

why don't you propose something, after studying things a bit?
then when people say "there are technical issues" you will know
what they are talking about because you will have come to
understand the (in)applicable techniques.  you might even be the
one saying that, but this time, w/ a technical solution, too.

thi

Re: Why emacs have not native language menu

[Hadron]

Pascal Bourguignon <pjb@informatimago.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>>> Today I tried vim 7.1,It have native language menu.
>>>>> Why emacs only have English menu?
>>
>> Because nobody has gone through the trouble of adding localization yet.
>> As for why, I would guess it's a mix of difficulty (need someone who
>> understand enough of Emacs and of localization to deal with it both at the
>> C and the Lisp level), together with the fact that it's bound to stay
>> partial:
>> - many elements are sufficiently dynamic that it's going to be
>>   difficult to add support to translate them.
>> - an important side of Emacs is that it exposes a lot of its internals: many
>>   important commands are reached via M-x where the term you enter is the
>>   name of a function (i.e. not quite a string), and all the online help
>>   refers to those things as well.
>>
>> Still, it's quite doable.  The only difficulty is to have the courage to
>> start with something small and convince other people that it's worthwhile to
>> go down that road.
>
> That's the problem.  I don't think localization is a good thing at
> all.

I find that very difficult to agree with.

>
> Of course, as anybody I'd prefer to use software that speaks to me in
> a language I understand, but if the language of the author of the
> software is in the list of languages I understand, I prefer to use
> that software in the author's language, because it will be clearer and
> much less risky.  Also, when software is translated (you can take

Not if you don't speak that language .....

Re: Why emacs have not native language menu

[Hadron]

Pascal Bourguignon <pjb@informatimago.com> writes:

> Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:
>> [...]
>> That is a possibility but obviously there are much more Japanese or
>> French people who use their software now than then.
>
> Yes, applications.
>
>
>> What good is a software package if it can't be used by linguistically
>> challenged people ?
>
> Linguistically challenged people just cannot program.

What has "program" got to do with Emacs, even if you are totally
incorrect in your assumption. I know plenty of top notch programmers who
are unable to master french or german but are happy with their native
english.

>
> You cannot translate programming languages.  This has been tried
> several times, BEFORE the Internet existed (eg BASICOIS, a Basic in
> French, there was also a Pascal in French, and I bet a number of
> variations in other languages).  All these experiment failed, because
> programs must be readable to be useful, and French is readably only by
> French people.  Pascal is readable by all programmers!

Aha. OK. You are talking about localised lisp? Maybe I got lost here.
>
> Nowadays, with the Internet and the worldwide job market, it's just
> impossible to translate a programming language.  And this is what
> emacs is.

No. That is NOT what emacs is. eLisp is the programming language. Emacs
is an infrastructure which supports multiple applications programmed in
elisp. They can be localised.

>
> Now if you implement an application in emacs you may try to proposed
> localized versions.  But there are very few applications in emacs,
> most emacs software keeps the powerful link between the programming
> environment and the functionalities provided.  Does anybody know an
> emacs applications where you can do _everything_ only using menus and
> buttons?  Or where you would _want_ to do everything that way? 

I think people are possibly talking at cross purposes here. Or maybe
just me?

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 24 juil. 07, at 21:54, Thien-Thi Nguyen wrote:
> i think it is unlikely we (the participants of this thread) can
> come up w/ a design as you suggest.

I did not suggest much more than what already works in 99% of  
software packages around the world.

> why don't you propose something, after studying things a bit?
> then when people say "there are technical issues" you will know
> what they are talking about because you will have come to
> understand the (in)applicable techniques.

No because the people who pretend that there are technical issues or  
that "it is impossible" do not make sense in the first place.

It is not the technical issues that are (not) discussed here, but the  
mere idea of localizing emacs.

I think it is more a psychological issue than a technical issue right  
now.

It would be better if people who are not interested in localization  
stop replying to this thread and let others discuss possibilities.

Jean-Christophe Helary

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Hadron <hadronquark@googlemail.com> writes:

> Pascal Bourguignon <pjb@informatimago.com> writes:
>
>> Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:
>>> [...]
>>> That is a possibility but obviously there are much more Japanese or
>>> French people who use their software now than then.
>>
>> Yes, applications.
>>
>>
>>> What good is a software package if it can't be used by linguistically
>>> challenged people ?
>>
>> Linguistically challenged people just cannot program.
>
> What has "program" got to do with Emacs, even if you are totally
> incorrect in your assumption. 

emacs is a programming environment with a textual user interface
library (ie and "editor"). emacs = Editing MACroS.



> I know plenty of top notch programmers who
> are unable to master french or german but are happy with their native
> english.

On the other hand, all the other programmers need to learn English to
be able to program.


>> You cannot translate programming languages.  This has been tried
>> several times, BEFORE the Internet existed (eg BASICOIS, a Basic in
>> French, there was also a Pascal in French, and I bet a number of
>> variations in other languages).  All these experiment failed, because
>> programs must be readable to be useful, and French is readably only by
>> French people.  Pascal is readable by all programmers!
>
> Aha. OK. You are talking about localised lisp? Maybe I got lost here.

What else?  This is what emacs is.


>> Nowadays, with the Internet and the worldwide job market, it's just
>> impossible to translate a programming language.  And this is what
>> emacs is.
>
> No. That is NOT what emacs is. eLisp is the programming language. Emacs
> is an infrastructure which supports multiple applications programmed in
> elisp. They can be localised.

Look, if you asked to localize microemacs or nano, I'd say, no problem
go ahead.  But emacs is lisp.


>> Now if you implement an application in emacs you may try to proposed
>> localized versions.  But there are very few applications in emacs,
>> most emacs software keeps the powerful link between the programming
>> environment and the functionalities provided.  Does anybody know an
>> emacs applications where you can do _everything_ only using menus and
>> buttons?  Or where you would _want_ to do everything that way? 
>
> I think people are possibly talking at cross purposes here. Or maybe
> just me?


Well, by making the distinction between emacs and the applications (eg
doctor, gnus, vm, life, etc), I'm trying to establish a common
language here.  I'm saying that you may consider localizing
applications, but you cannot localize successfully emacs.

And for applications, you have to be careful to consider only those
emacs applications that behave very distinctly from the normal emacs
way.  A major-mode is not an emacs application, it's emacs.

As I wrote, you have to consider only the applications that can be
used only thru menu and buttons.  Any application where it's easier or
necessary to use M-x, you fail, since M-x gives you access to lisp
stuff that you cannot localize without making a mess.  



Also, the simple fact of localizing something, renders it
unprogrammable, because a programmer knows his mother tongue and
English, and cannot translate his little add-on functions and
commands.  Therefore users of localized applications cannot share
their code anymore, and you break the opensource philosophy.




-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Hadron <hadronquark@googlemail.com> writes:

> Pascal Bourguignon <pjb@informatimago.com> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>>>> Today I tried vim 7.1,It have native language menu.
>>>>>> Why emacs only have English menu?
>>>
>>> Because nobody has gone through the trouble of adding localization yet.
>>> As for why, I would guess it's a mix of difficulty (need someone who
>>> understand enough of Emacs and of localization to deal with it both at the
>>> C and the Lisp level), together with the fact that it's bound to stay
>>> partial:
>>> - many elements are sufficiently dynamic that it's going to be
>>>   difficult to add support to translate them.
>>> - an important side of Emacs is that it exposes a lot of its internals: many
>>>   important commands are reached via M-x where the term you enter is the
>>>   name of a function (i.e. not quite a string), and all the online help
>>>   refers to those things as well.
>>>
>>> Still, it's quite doable.  The only difficulty is to have the courage to
>>> start with something small and convince other people that it's worthwhile to
>>> go down that road.
>>
>> That's the problem.  I don't think localization is a good thing at
>> all.
>
> I find that very difficult to agree with.

But this is what I think.


To be more precise, I could say that localization won't be a good
thing until singularity.  Then of course it won't matter because it
will be automatic. (But let's hope it will be faster than human
translators who had to work 11 years with the author to translate
GEB...)



>> Of course, as anybody I'd prefer to use software that speaks to me in
>> a language I understand, but if the language of the author of the
>> software is in the list of languages I understand, I prefer to use
>> that software in the author's language, because it will be clearer and
>> much less risky.  Also, when software is translated (you can take
>
> Not if you don't speak that language .....

But we all speak English!!!


My point is that it's easier to teach everybody a worldwide language
(I'd vote for either Latin or Esperanto, but nobody asked me and they
all started to speak English for no good reason), than to mess with
localizations.

Our energies would be better spent on working on the Singularity than
that.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.

Re: Why emacs have not native language menu

[Hadron]

Pascal Bourguignon <pjb@informatimago.com> writes:

>>
>> Aha. OK. You are talking about localised lisp? Maybe I got lost here.
>
> What else?  This is what emacs is.

This is not the point. "Localised" can substitute all hard coded "texts"
with a call to a translation routine to provide the localised
translation.

>
>
>>> Nowadays, with the Internet and the worldwide job market, it's just
>>> impossible to translate a programming language.  And this is what
>>> emacs is.
>>
>> No. That is NOT what emacs is. eLisp is the programming language. Emacs
>> is an infrastructure which supports multiple applications programmed in
>> elisp. They can be localised.
>
> Look, if you asked to localize microemacs or nano, I'd say, no problem
> go ahead.  But emacs is lisp.

We are talking the command names interfaces and help texts - not the
function names. e.g you dont see "find-file-at-point" in the
menu. No. You find "Open File" or similar.

Re: Why emacs have not native language menu

[Thien-Thi Nguyen]

() Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
() Tue, 24 Jul 2007 23:00:28 +0900

   No because the people who pretend that there are technical
   issues or that "it is impossible" do not make sense in the
   first place.

perhaps you misunderstand them (more than they misunderstand you).

   It is not the technical issues that are (not) discussed here,
   but the mere idea of localizing emacs.

   I think it is more a psychological issue than a technical issue
   right now.

evidently.

   It would be better if people who are not interested in
   localization stop replying to this thread and let others
   discuss possibilities.

everything is possible in an ideal world.  but we are not there,
and silence from the knowledgeable does not help us get closer.

you say, why not redesign to fit more the ideal?  others say,
that's a big job, full of technical difficulties.  you call them
pretenders.  i suppose you distrust what you don't know; perhaps
that will subside when you age more.

i invite you to cross the schism between writer of text and writer
of programs.  there is lots of fun on both sides.  in this way, i
hope to "localize" you to reality.  :-D

thi

Re: Emacs localization (Re: Why emacs have not native language menu)

[Eli Zaretskii]

> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
> Date: Tue, 24 Jul 2007 21:10:13 +0900
> 
> 
> On 24 juil. 07, at 20:35, Harald Hanche-Olsen wrote:
> 
> > Emacs is very old and was never designed for localization.  Of course,
> > localization support can be added in principle, but it's probably not
> > a small job.  Neither is it medium sized, if you get my drift.
> 
> Of course. But there is a tutorial, there are manuals there is a  
> basic core GUI. That makes a set of a relatively limited scope, and  
> as far as I know most of the "external" data already has translation.

Emacs already displays the tutorial in the locale's language; there
are 20 translations of the tutorial to languages other than English
that come with Emacs 22.x distributions.  If translators volunteer to
translate the user manual (a formidable job, if you ask me, since the
manual is HUGE), there should be no problem at all to display a
localized manual, too.

IOW, the difficulties are not in the external docs, they are in the
internal doc strings, menus, tooltips, and various features that use
those internal documentation resources for their implementation.

> So I think the actual scope of the work is actually much smaller than  
> most people imagine.

You are wrong thinking that.  I will try to explain why in a separate
message.

But you have an excellent opportunity to prove that you are right and
others are wrong: step forward and volunteer to do some part of this
job.  Thanks in advance.

> > Did I hear you volunteer?  Good luck!
> 
> I would if a reasonably simple system exist. I am a translator by  
> trade, not a coder.

Then we are out of luck, for the time being, because the most
important part of the job is to design and implement the
infrastructure required for making Emacs localization possible.

However, you can still volunteer to translate the manual.  That
doesn't need almost any infrastructure changes, so as soon as a single
translation exists, the localized manuals can be made available to
users.

Re: Why emacs have not native language menu

[William Case]

Hi;

Hear, hear.

On Tue, 2007-07-24 at 23:00 +0900, Jean-Christophe Helary wrote:
> On 24 juil. 07, at 21:54, Thien-Thi Nguyen wrote:
> > i think it is unlikely we (the participants of this thread) can
> > come up w/ a design as you suggest.
> 
> I did not suggest much more than what already works in 99% of  
> software packages around the world.
> 
[snip]
> 
> It would be better if people who are not interested in localization  
> stop replying to this thread and let others discuss possibilities.
> 
> Jean-Christophe Helary
> 
I don't know why someone else should be concerned about what a user sees
in the personal space a 1 - 1 1/2 feet in front of him.

If those who are interested want to take on the task of localization --
why object?
-- 
Regards Bill

Re: Emacs localization (Re: Why emacs have not native language menu)

[Jean-Christophe Helary]

On 24 juil. 07, at 23:30, Eli Zaretskii wrote:

> IOW, the difficulties are not in the external docs, they are in the
> internal doc strings, menus, tooltips, and various features that use
> those internal documentation resources for their implementation.
>
>> So I think the actual scope of the work is actually much smaller than
>> most people imagine.
>
> You are wrong thinking that.  I will try to explain why in a separate
> message.

Here, I am strictly talking in terms of actual localization work. As  
you say the manual is huge (and sometimes poorly written, but this is  
yet a different issue), but the UI (I mean all the visible strings  
like menus, interactive help etc) is a much smaller set _if_ we  
consider the UI in a modular way (which it is in a way since we deal  
with modes). At least, that is my understanding.

I am _not_ talking about the system itself, since I have no way to  
estimate how hard a task that would be. But I can see that just like  
most big software packages, creating such a system is quite en endeavor.

> Then we are out of luck, for the time being, because the most
> important part of the job is to design and implement the
> infrastructure required for making Emacs localization possible.

I just needed a good reason to start learning emacs lisp...

> However, you can still volunteer to translate the manual.  That
> doesn't need almost any infrastructure changes, so as soon as a single
> translation exists, the localized manuals can be made available to
> users.

I am already a member of the translation effort to French (along with  
other localization projects) but I find translating the manual of a  
non localized application a waste of time in general, especially in  
the case of emacs where _most_ of the important stuff _cannot_  
currently be localized

Jean-Christophe Helary

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

> On 24 juil. 07, at 21:54, Thien-Thi Nguyen wrote:
>> i think it is unlikely we (the participants of this thread) can
>> come up w/ a design as you suggest.
>
> I did not suggest much more than what already works in 99% of
> software packages around the world.
>
>> why don't you propose something, after studying things a bit?
>> then when people say "there are technical issues" you will know
>> what they are talking about because you will have come to
>> understand the (in)applicable techniques.
>
> No because the people who pretend that there are technical issues or
> that "it is impossible" do not make sense in the first place.
>
> It is not the technical issues that are (not) discussed here, but the
> mere idea of localizing emacs.
>
> I think it is more a psychological issue than a technical issue right
> now.


For example, people who had problems with localized software of all
nature and from all aspects of the software (code, data, user
interface, OS, file formats, user support, etc) and this for almost 30
years.

One selling points of GUI (and I won't even try to explain here why
GUI are bad, compared to CLI or just more textual interfaces like
emacs'), is exactly that it _avoids_ localization, because graphics
are more universal than text (even discounting the graphics that have
to be localized).


> It would be better if people who are not interested in localization
> stop replying to this thread and let others discuss possibilities.



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 24 juil. 07, at 23:26, Thien-Thi Nguyen wrote:

> () Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
> () Tue, 24 Jul 2007 23:00:28 +0900
>
>    No because the people who pretend that there are technical
>    issues or that "it is impossible" do not make sense in the
>    first place.
>
> perhaps you misunderstand them (more than they misunderstand you).

Pascal Bourguignon's replies are a good example of misunderstanding  
me: I am not talking about localizing the function names, which would  
definitely create a mess, but about localizing the interface, as  
Hadron very clearly put it. Or maybe Hadron is totally misunderstood  
too ?

> you say, why not redesign to fit more the ideal?

It is not the ideal, it is the practical.

> i invite you to cross the schism between writer of text and writer
> of programs.  there is lots of fun on both sides.  in this way, i
> hope to "localize" you to reality.  :-D

My reality is already full of fun. I am trying to save time for the  
practical.


Jean-Christophe Helary

Re: Why emacs have not native language menu

[Eli Zaretskii]

> From: Hadron <hadronquark@googlemail.com>
> Newsgroups: gnu.emacs.help
> Date: Tue, 24 Jul 2007 15:10:41 +0200
> 
> > Nowadays, with the Internet and the worldwide job market, it's just
> > impossible to translate a programming language.  And this is what
> > emacs is.
> 
> No. That is NOT what emacs is. eLisp is the programming language. Emacs
> is an infrastructure which supports multiple applications programmed in
> elisp. They can be localised.

Don't forget that Lisp is a language without fundamental distinction
between program code and data.  In Lisp, I can construct a string in
memory, and then execute it as a function.

This happens a lot on the Lisp level, but spills into the low-level C
code as well.  Consider the following C snippet, for example:

      call1 (intern ("ask-user-about-supersession-threat"), fn);

Without knowing quite a few bits about Emacs internals, one cannot
decide whether the string here needs or needs not be translated.

So a clean separation between translatable strings and untranslatable
code symbols is much harder than in C or Pascal, for example.

Re: Why emacs have not native language menu

[Eli Zaretskii]

> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
> Date: Tue, 24 Jul 2007 23:00:28 +0900
> Cc: help-gnu-emacs@gnu.org
> 
> > why don't you propose something, after studying things a bit?
> > then when people say "there are technical issues" you will know
> > what they are talking about because you will have come to
> > understand the (in)applicable techniques.
> 
> No because the people who pretend that there are technical issues or  
> that "it is impossible" do not make sense in the first place.

People are entitled to their views, even if those views are
incorrect, exactly as you are entitled to yours.  But don't take
everything that's written in this thread as official opinion of Emacs
maintainers.

> It is not the technical issues that are (not) discussed here, but the  
> mere idea of localizing emacs.
> 
> I think it is more a psychological issue than a technical issue right  
> now.

The idea of localizing Emacs is accepted by the maintainers.  It's the
difficulties of implementing this that prevented it from happening
until now.  And there _are_ difficulties, Thien-Thi Nguyen is right in
suggesting that you study the issues first (e.g., by reading past
discussion on the Emacs development list) before dismissing those
difficulties as ``psychological''.

In any case, this forum is not the right place for serious discussion
of such issues.  If you really want to discuss the technical
difficulties and how to overcome them, come to emacs-devel (but please
read past discussions first, to avoid reiterating old arguments).

> It would be better if people who are not interested in localization  
> stop replying to this thread and let others discuss possibilities.

You cannot stop people from talking in a public forum.  Just stop
responding to messages that you think are not discussing the real
aspects of the problem.

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 24 juil. 07, at 23:40, William Case wrote:

>> It would be better if people who are not interested in localization
>> stop replying to this thread and let others discuss possibilities.
>>
>> Jean-Christophe Helary

> I don't know why someone else should be concerned about what a user  
> sees
> in the personal space a 1 - 1 1/2 feet in front of him.

Usually that is how software development starts: by caring for the  
needs of other people. Same for localization. _You_ may not need it,  
but some people, who have less skills at programming elisp than you  
do may need it.

Jean-Christophe Helary

Re: Emacs localization (Re: Why emacs have not native language menu)

[Lennart Borgman (gmail)]

Jean-Christophe Helary wrote:
> I am already a member of the translation effort to French (along with 
> other localization projects) but I find translating the manual of a non 
> localized application a waste of time in general, especially in the case 
> of emacs where _most_ of the important stuff _cannot_ currently be 
> localized


Some comments:

There are a couple of things to translate:
- manuals
- help texts
- menus
- interactive commands

* Translating manuals is a big job of course, but straight forward.

* The help texts (shown in the help buffer) are the documentation that 
are written together with the functions and variables etc, like this:

   (defun find-library (library)
      "Find the elisp source of LIBRARY."
     ;; body of function comes here

When this texts are shown in the help buffer they could of course be 
replaced with other texts from some table. Rather straight forward too 
since not very much need to be changed in Emacs. (The English 
documentation should of course just stay where it is. Otherwise it would 
be a nightmare to program.)

* menu texts? Ah, I would not even dream of translating them until menus 
are defined in a more simple manner.

* I believe you agree with me that they should not be translated. 
Translating them would IMO lead to confusion.

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 24 juil. 07, at 23:58, Eli Zaretskii wrote:

> So a clean separation between translatable strings and untranslatable
> code symbols is much harder than in C or Pascal, for example.

Do you think such clear separation has to be attained to create a  
localization system for emacs ?

Jean-Christophe Helary

Re: Emacs localization (Re: Why emacs have not native language menu)

[Eli Zaretskii]

> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
> Date: Tue, 24 Jul 2007 23:50:25 +0900
> 
> I am already a member of the translation effort to French (along with  
> other localization projects) but I find translating the manual of a  
> non localized application a waste of time in general

I really fail to see why.  Most of the manual is text explaining
things, not names of functions or menu items.  having the text in the
language one understands would be a great help for people whose
command of the English language is poor.

Here's a typical example:

       You can exit Rmail with `q' (`rmail-quit'); this expunges and saves
    the Rmail file, then buries the Rmail buffer as well as its summary
    buffer, if present (*note Rmail Summary::).  But there is no need to
    "exit" formally.  If you switch from Rmail to editing in other buffers,
    and never switch back, you have exited.  Just make sure to save the
    Rmail file eventually (like any other file you have changed).  `C-x s'
    is a suitable way to do this (*note Save Commands::).  The Rmail
    command `b', `rmail-bury', buries the Rmail buffer and its summary
    buffer without expunging and saving the Rmail file.

There are 2 command names here that should not be translated, but
other than that, I can easily imagine someone whose English is not so
good scratching her head (``expunge''? ``bury''? ``eventually''?)
trying to figure out what the heck does this paragraph tell.

Re: Why emacs have not native language menu

[Peter Dyballa]

Am 24.07.2007 um 13:12 schrieb Jean-Christophe Helary:

> Do you actually use localized applications or do you just suppose  
> that localizers are less good at doing their jobs then coders at  
> doing theirs ?

I see quite often terrible German localisations. Terrible use of  
language, independent of any rules, independent of orthography, too.

--
Greetings

   Pete       (:
         _    / __    -    -
       _/ \__/_/        -     -
      (´`)      (´`)   -    -
       `´        `´

Re: Emacs localization (Re: Why emacs have not native language menu)

[Jean-Christophe Helary]

On 25 juil. 07, at 00:11, Lennart Borgman (gmail) wrote:

> Some comments:
>
> * (interactive commands) I believe you agree with me that they  
> should not be translated. Translating them would IMO lead to  
> confusion.

Sure, in the current state of affairs. But in the end, the command  
names are just arbitrary strings and sometimes have very little to do  
with English, as seems to suggest Pascal Bourguignon.

I am sure if a Japanese developer created code with romaji command  
names you'd see what I mean :)

Jean-Christophe Helary

Re: Emacs localization (Re: Why emacs have not native language menu)

[Peter Dyballa]

Am 24.07.2007 um 13:19 schrieb Jean-Christophe Helary:

> What is the technical difference with the extensibility of emacs  
> and version upgrades or plugins in other apps ?
>
> I don't see any. And the common issue is that localizers have to  
> keep up with the dynamic in both cases.

Compare GNU Emacs with for example xrmap. Xrmap has *external* files  
that provide messages or menu entries in other languages. And then  
the CIA World Facts Book is still US English, names of rivers, lakes,  
towns, countries are in English ...

--
Greetings

   Pete

"Eternity is a terrible thought. I mean, where's it going to end?"
                                             - Tom Stoppard

Re: Why emacs have not native language menu

[Peter Dyballa]

Am 24.07.2007 um 14:18 schrieb Jean-Christophe Helary:

>> Of course, we all know that for a corporation market division is very
>> good (it allows them to put higher prices in the submarkets).  But  
>> for
>> users these translations  is costly in more than one way.
>
> I fail to see the rationale behind this opinion.

Compare the price of a Mac bought in the U.S.A. and one bought in  
Japan or France!

--
Greetings

   Pete

There is no worse tyranny than to force a man to pay for what he does  
not want merely because you think it would be good for him.
                                            -- Robert Heinlein

Re: Why emacs have not native language menu

[Peter Dyballa]

Am 24.07.2007 um 14:30 schrieb Pascal Bourguignon:

> emacs is a programming language with a library for textual user  
> interfaces.
>
> Asking for a localization of emacs is the same as asking for a
> localization of C++.  Where do you start, and where do you stop???

Yes, that's another item: a function or variable name in English  
describes itself to most GNU Emacs users. I often wonder whether I  
should use English or German names for variables or macros in LaTeX,  
Shell, or Perl. When I am sure that the source won't reach the  
Internet, then German is fine.

And now imagine the function or variable names are also written in  
Japanese, Korean, Chinese, Arabic, Indic, Cyrillic letters ...


Anyway, I think and feel an "official" interface for Unicode enabled  
localisation of menus and their entries and of messages in *Messages*  
buffer and/or echo area is needed. There is no need to let the nice  
Latin script dominate the whole world.

--
Greetings

   Pete

’Twas a woman who drove me to drink, and I never had the courtesy
  to thank her for it.         — W.C. Fields

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 25 juil. 07, at 00:21, Peter Dyballa wrote:

>
> Am 24.07.2007 um 13:12 schrieb Jean-Christophe Helary:
>
>> Do you actually use localized applications or do you just suppose  
>> that localizers are less good at doing their jobs then coders at  
>> doing theirs ?
>
> I see quite often terrible German localisations. Terrible use of  
> language, independent of any rules, independent of orthography, too.

When you see terrible code, do you conclude that coding is bad ?

I just finished working on a proofreading session for the next  
version of OpenOffice with translators, proofreaders, coordinators,  
checkers. When professionals volunteer in the field they are  
specialists of, free software rips all the benefits. When  
professionals volunteer in fields they are not specialist of, they  
need to be mentored by specialists so that free software can benefit  
from their activity.


Jean-Christophe Helary

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 25 juil. 07, at 00:24, Peter Dyballa wrote:

>
> Am 24.07.2007 um 14:18 schrieb Jean-Christophe Helary:
>
>>> Of course, we all know that for a corporation market division is  
>>> very
>>> good (it allows them to put higher prices in the submarkets).   
>>> But for
>>> users these translations  is costly in more than one way.
>>
>> I fail to see the rationale behind this opinion.
>
> Compare the price of a Mac bought in the U.S.A. and one bought in  
> Japan or France!

I just did, with the exchange rates found on http://www.xe.com/

Model/USD/EU/YEN as per the different Apple sites
conversion from USD to EU
conversion from USD to YEN

> MB $1099 €1049 ¥139.800
> €795
> ¥132.578
>
> MBP $1999 €1899 ¥259.800
> €1446
> ¥241.150
>
> MM $599 €619 ¥74.800
> €433
> ¥72.243
>
> iM $999 €999 ¥124.800
> €722
> ¥120.486
>
> MP $2499 €2499 ¥319.800
> €1808
> ¥301.352

Interestingly, it seems it is the French buyers who pay for the  
Japanese localization...

Jean-Christophe Helary

Re: Why emacs have not native language menu

[William Case]

Hi;

Just to add some real life experience.

On Tue, 2007-07-24 at 17:25 +0200, Peter Dyballa wrote:
> Am 24.07.2007 um 14:30 schrieb Pascal Bourguignon:
> 
[snip]
> Yes, that's another item: a function or variable name in English  
> describes itself to most GNU Emacs users. I often wonder whether I  
> should use English or German names for variables or macros in LaTeX,  
> Shell, or Perl. When I am sure that the source won't reach the  
> Internet, then German is fine.
> 
> And now imagine the function or variable names are also written in  
> Japanese, Korean, Chinese, Arabic, Indic, Cyrillic letters ...
> 
> 
> Anyway, I think and feel an "official" interface for Unicode enabled  
> localisation of menus and their entries and of messages in *Messages*  
> buffer and/or echo area is needed. There is no need to let the nice  
> Latin script dominate the whole world.

I live in Ottawa, and have lived most my life in Eastern Canda. My
mother tongue is English, but I can speak enough French not to starve to
death, find a place to live etc. etc.

I recently bought a brand name printer.  The front end instructions were
in English.  All the error codes, readmes, manuals etc. were in French.
Me and Mr. Roget always end up with nonsense when we try to read one of
those manuals.  My francophone friends assure me it is just as
frustrating the other way around.

On the other side, the Canadian government requires that most equipment
purchased by the Federal Government come with French documentation as
well as English.  Those francophone friends of mine who work on and
maintain that equipment (from computers to fighter planes) confess that
they always use the English manuals.  They say they do so because the
original manuals tend to be more accurate than the translated manuals
and because just sharing one manual at work insures that they see any
hand written notes or update memos.

There are arguments for both sides.  I come down on the side that says
let a person have what they want or need within their own personal
space.  For the rest, as the world gets smaller and smaller we are all
going to be bumping into someone else's language.  We had better get
used to it.  We had better figure out how to handle it.  What's going to
happen if the next killer app comes out of China or Uganda?

-- 
Regards Bill

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Hadron <hadronquark@googlemail.com>
>> Newsgroups: gnu.emacs.help
>> Date: Tue, 24 Jul 2007 15:10:41 +0200
>> 
>> > Nowadays, with the Internet and the worldwide job market, it's just
>> > impossible to translate a programming language.  And this is what
>> > emacs is.
>> 
>> No. That is NOT what emacs is. eLisp is the programming language. Emacs
>> is an infrastructure which supports multiple applications programmed in
>> elisp. They can be localised.
>
> Don't forget that Lisp is a language without fundamental distinction
> between program code and data.  In Lisp, I can construct a string in
> memory, and then execute it as a function.
>
> This happens a lot on the Lisp level, but spills into the low-level C
> code as well.  Consider the following C snippet, for example:
>
>       call1 (intern ("ask-user-about-supersession-threat"), fn);
>
> Without knowing quite a few bits about Emacs internals, one cannot
> decide whether the string here needs or needs not be translated.
>
> So a clean separation between translatable strings and untranslatable
> code symbols is much harder than in C or Pascal, for example.

The programmers must also tell the translators what the strings mean.
Really!


If you take a random program, and extract the strings, you may get:

"file"
"file"
"file"
"X"
"open"
"square diamond"

amongst a few others.


Without a comment from the programmer such as:

"file"           "The sequence of bytes where data is stored."
"file"           "The folder where documents are stored."
"file"           "The tool to rasp things."
"x"              "Letter X, as in X-Files."
"open"           "Verb, in a command, like 'open computer file'."
"square diamond" "Type of file (the tool one)."

the translators could not come with the a correct translation such as:

"file"           "fichier"
"file"           "dossier"
"file"           "lime"
"X"              "X"
"Open"           "Ouvrir"  // Note the switch from imperative to infinive...
"square diamond" "diamand carrée"

so you can get

"Ouvrir fichier" for "Open file",
"Dossier X" for "X File", and
"lime diamand carrée" for "square diamond file".

(See for example, NSLocalizedString in OpenStep)


Now, the bet is, how many such occurances exist in emacs sources?

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

In a World without Walls and Fences, 
who needs Windows and Gates?

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

> On 24 juil. 07, at 23:26, Thien-Thi Nguyen wrote:
>
>> () Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
>> () Tue, 24 Jul 2007 23:00:28 +0900
>>
>>    No because the people who pretend that there are technical
>>    issues or that "it is impossible" do not make sense in the
>>    first place.
>>
>> perhaps you misunderstand them (more than they misunderstand you).
>
> Pascal Bourguignon's replies are a good example of misunderstanding
> me: I am not talking about localizing the function names, which would
> definitely create a mess, but about localizing the interface, as
> Hadron very clearly put it. Or maybe Hadron is totally misunderstood
> too ?

But you don't understand me!  function names are a great part of the
interface of emacs.  I never use the menu (first thing in my ~/.emacs
is (mapc (lambda (f) (funcall f -1)) 
        '(menu-bar-mode scroll-bar-mode tool-bar-mode))
).  Command names (that is function names) are a big part of the my
interactive interface with emacs, thru M-x.



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.

Re: Why emacs have not native language menu

[Eli Zaretskii]

> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
> Date: Wed, 25 Jul 2007 00:12:41 +0900
> 
> On 24 juil. 07, at 23:58, Eli Zaretskii wrote:
> 
> > So a clean separation between translatable strings and untranslatable
> > code symbols is much harder than in C or Pascal, for example.
> 
> Do you think such clear separation has to be attained to create a  
> localization system for emacs ?

No, I just meant to cool some heads who evidently think that
localizing Emacs is no different from localizing GCC, say.

Re: Why emacs have not native language menu -- TYPO

[William Case]

On Tue, 2007-07-24 at 11:52 -0400, William Case wrote:
> Hi;
> 
> Just to add some real life experience.
> 
> On Tue, 2007-07-24 at 17:25 +0200, Peter Dyballa wrote:
> > Am 24.07.2007 um 14:30 schrieb Pascal Bourguignon:
> > 
> [snip]
> > Yes, that's another item: a function or variable name in English  
> > describes itself to most GNU Emacs users. I often wonder whether I  
> > should use English or German names for variables or macros in LaTeX,  
> > Shell, or Perl. When I am sure that the source won't reach the  
> > Internet, then German is fine.
> > 
> > And now imagine the function or variable names are also written in  
> > Japanese, Korean, Chinese, Arabic, Indic, Cyrillic letters ...
> > 
> > 
> > Anyway, I think and feel an "official" interface for Unicode enabled  
> > localisation of menus and their entries and of messages in *Messages*  
> > buffer and/or echo area is needed. There is no need to let the nice  
> > Latin script dominate the whole world.
> 
> I live in Ottawa, and have lived most my life in Eastern Canda. My
> mother tongue is English, but I can speak enough French not to starve to
> death, find a place to live etc. etc.
> 
> I recently bought a brand name printer.  The front end instructions were
> in English.  All the error codes, readmes, manuals etc. were in French.
> Me and Mr. Roget always end up with nonsense when we try to read one of
         ^^^^^^^^^ M. Larousse
> those manuals.  My francophone friends assure me it is just as
> frustrating the other way around.
> 
> On the other side, the Canadian government requires that most equipment
> purchased by the Federal Government come with French documentation as
> well as English.  Those francophone friends of mine who work on and
> maintain that equipment (from computers to fighter planes) confess that
> they always use the English manuals.  They say they do so because the
> original manuals tend to be more accurate than the translated manuals
> and because just sharing one manual at work insures that they see any
> hand written notes or update memos.
> 
> There are arguments for both sides.  I come down on the side that says
> let a person have what they want or need within their own personal
> space.  For the rest, as the world gets smaller and smaller we are all
> going to be bumping into someone else's language.  We had better get
> used to it.  We had better figure out how to handle it.  What's going to
> happen if the next killer app comes out of China or Uganda?
> 
-- 
Regards Bill

Re: Emacs localization (Re: Why emacs have not native language menu)

[Pascal Bourguignon]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

> On 25 juil. 07, at 00:11, Lennart Borgman (gmail) wrote:
>
>> Some comments:
>>
>> * (interactive commands) I believe you agree with me that they
>> should not be translated. Translating them would IMO lead to
>> confusion.
>
> Sure, in the current state of affairs. But in the end, the command
> names are just arbitrary strings and sometimes have very little to do
> with English, as seems to suggest Pascal Bourguignon.
>
> I am sure if a Japanese developer created code with romaji command
> names you'd see what I mean :)

Theorically, as I'm able to take some (small) compiled program and
reverse engineer it to some meaningful source form.  But this is not
an efficient process.  That's why all my employers, in all the
countries they're located (4 so far, with 4 different languages) asked
me to write the code, the comments and documentation in English.  In
my last job, considering only programmers, we were 6 different
nationalities, with 5 different native languages.

So in my opinion, now is the worst time to involve oneself in such a
project.  When it will be completed either everybody will speak
English, or there will be AI to do the translation for us.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.

Re: Emacs localization (Re: Why emacs have not native language menu)

[Eli Zaretskii]

> Date: Tue, 24 Jul 2007 17:11:30 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> 
> There are a couple of things to translate:
> - manuals
> - help texts
> - menus
> - interactive commands

 - option names
 - tooltips
 - text of messages in the echo area
 - text of prompts in the minibuffer
 - text we insert into special-purpose buffers, like Dired and *Help*
 - text of customization widgets

> * The help texts (shown in the help buffer) are the documentation that 
> are written together with the functions and variables etc, like this:
> 
>    (defun find-library (library)
>       "Find the elisp source of LIBRARY."
>      ;; body of function comes here
> 
> When this texts are shown in the help buffer they could of course be 
> replaced with other texts from some table. Rather straight forward too 
> since not very much need to be changed in Emacs.

I disagree.  Consider a random example:

    tty-color-alist is a compiled Lisp function in lisp/term/tty-colors.elc'.
    (tty-color-alist &optional FRAME)

    Return an alist of colors supported by FRAME's terminal.
    FRAME defaults to the selected frame.

    [back]

Notice how FRAME is generated automatically for the argument list,
and then repeated in the doc string, where it was typed by a
programmer who wrote that function.  Note also the auto-generated
"back" button.  These are all parts of the display, but they originate
from different places, some are literal strings, others are generated
on the fly.  And they all need to look and work together well
eventually.  As someone who is a TP team leader, I can tell you: this
kind of stuff is a translator's nightmare!  One of the first things we
teach newbie translators is that translating text in pieces is an
absolute no-no; you need to see the whole phrase to produce a valid
translation.  In text-based programs we convince programmers to modify
their code so that messages are not constructed a piece at a time;
however, such techniques are unimaginable in the Emacs help system
without a complete redesign (which no one will dare to undertake).

And then there's the sheer size.  etc/DOC, the repository of Emacs doc
strings, is 2MB, and that's only for built-in symbols (i.e. those
defined in C) and packages preloaded at dump time.  Add to that
packages loaded at run time, and you'll probably get to 10MB of
strings that need translating.  Loading a message catalog for a single
language would thus add several MBs to the footprint of a running
session.  It's possible to have separate catalogs for each Lisp
package, but such a scheme needs to be designed and implemented
first.

> * menu texts? Ah, I would not even dream of translating them until menus 
> are defined in a more simple manner.

Actually, given the appropriate infrastructure, this isn't as hard as
you seem to think: the menu display code just needs to take the
English string and look it up in a message catalog.  The more
fundamental problem is that only recently Emacs got Unicode support in
most (if not all) of the GUI toolkits used to build it.

But menus whose items are computed dynamically are still a hard
problem.

Re: Why emacs have not native language menu

[Peter Dyballa]

Am 24.07.2007 um 17:52 schrieb William Case:

> On the other side, the Canadian government requires that most  
> equipment
> purchased by the Federal Government come with French documentation as
> well as English.  Those francophone friends of mine who work on and
> maintain that equipment (from computers to fighter planes) confess  
> that
> they always use the English manuals.  They say they do so because the
> original manuals tend to be more accurate than the translated manuals
> and because just sharing one manual at work insures that they see any
> hand written notes or update memos.

That's correct! I once helped to translate a short German  
documentation into English. I had to ask the authors half a dozen  
times what they were trying to express with these or those words.  
They were writing in my and their native language and they were  
writing on a topic me and them completely understood – however when  
you have to be exact it happens easily that you find the original  
work ambiguous, and even a professional translator would not be able  
to improve the resulting document, quite contrary. Then it's better  
to go back to the first version – hoping it was written by experts.

Localising GNU Emacs is a challenge, even for those who understand  
Lisp, computers, and humans.

--
Greetings

   Pete

Real Time, adj.:
Here and now, as opposed to fake time, which only occurs there and then.

Re: Emacs localization (Re: Why emacs have not native language menu)

[Peter Dyballa]

Am 24.07.2007 um 18:58 schrieb Eli Zaretskii:

>> There are a couple of things to translate:
>> - manuals
>> - help texts
>> - menus
>> - interactive commands
>
>  - option names
>  - tooltips
>  - text of messages in the echo area
>  - text of prompts in the minibuffer
>  - text we insert into special-purpose buffers, like Dired and *Help*
>  - text of customization widgets

  - names of special-purpose buffers


I use for my germanised calendar "Kalender," "Termine,"  
"Bemerkenswerte Tage von ... bis ...," "Feiertage im Jahr ..." ...

--
Greetings

   Pete

A morning without coffee is like something without something else.

Re: Why emacs have not native language menu

[David Kastrup]

Pascal Bourguignon <pjb@informatimago.com> writes:

> Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:
>> [...]
>> That is a possibility but obviously there are much more Japanese or
>> French people who use their software now than then.
>
> Yes, applications.
>
>
>> What good is a software package if it can't be used by
>> linguistically challenged people ?
>
> Linguistically challenged people just cannot program.

Interestingly, pretty much the only people I know without computing,
mathematics or science backgrounds that developed admirable mastery
with Emacs or TeX were proficient in the classics.

And if you have read classical Greek, with its 3 modes, 7 tenses, 3
numeri, 3 voices, and its complex grammatical structure that has no
problems spreading some unsuspecting sentence across several pages, a
sentence which, not entirely unlike a delicate spring, to a river of
sense swilling and into a sea expelling itself, from a slow start to a
furious - Odysseus in his ire would have been no less intimidating -
end continously waxing will finally, after a long, but yet not to be
compared to those of the masters who can express sentiments like "you
two should then have started to be a little ashamed of yourself" in a
single word by choosing all the grammatical details appropriately,
climax come to an end which, had you not been carefully nesting and
unnesting the twines of the silkily woven threads of language not
unlike a stack of bee hives or perhaps the playcards of a master,
might have been unexpected or at least no longer fathomable.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Why emacs have not native language menu

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Stefan Monnier 
<monnier@iro.umontreal.ca>], who wrote in article <jwvir8apj5p.fsf-monnier+gnu.emacs.help@gnu.org>:
> As for why, I would guess it's a mix of difficulty (need someone who
> understand enough of Emacs and of localization to deal with it both at the
> C and the Lisp level)

Would not it be trivial to just advice() bind-key() (sp?)?

> - many elements are sufficiently dynamic that it's going to be
>   difficult to add support to translate them.

How this is different from localization of other applications?

> - an important side of Emacs is that it exposes a lot of its internals: many
>   important commands are reached via M-x where the term you enter is the
>   name of a function (i.e. not quite a string), and all the online help
>   refers to those things as well.

How this is related to the menu?

> Still, it's quite doable.

I think it is practically trivial.  The C part is just to expose the
localization part of CRTL to Lisp; the rest can be done through
advice().

Please correct me if I'm wrong,
Ilya

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 25 juil. 07, at 01:02, Pascal Bourguignon wrote:

> Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:
>
>> On 24 juil. 07, at 23:26, Thien-Thi Nguyen wrote:
>>
>>> () Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
>>> () Tue, 24 Jul 2007 23:00:28 +0900
>>>
>>>    No because the people who pretend that there are technical
>>>    issues or that "it is impossible" do not make sense in the
>>>    first place.
>>>
>>> perhaps you misunderstand them (more than they misunderstand you).
>>
>> Pascal Bourguignon's replies are a good example of misunderstanding
>> me: I am not talking about localizing the function names, which would
>> definitely create a mess, but about localizing the interface, as
>> Hadron very clearly put it. Or maybe Hadron is totally misunderstood
>> too ?
>
> But you don't understand me!  function names are a great part of the
> interface of emacs.  I never use the menu (first thing in my ~/.emacs
> is (mapc (lambda (f) (funcall f -1))
>         '(menu-bar-mode scroll-bar-mode tool-bar-mode))
> ).  Command names (that is function names) are a big part of the my
> interactive interface with emacs, thru M-x.

I understand that you enjoy talking about your specific settings and  
how proficient you are at English and how everybody should be just as  
proficient as you so nobody would bother anybody with such silly  
requests as "localizing" (what a barbarous word!) such a wonderful  
application/language/whatever that is emacs in your eyes, but if you  
take some time off the mirror in which you find yourself so good at  
English, you'll notice that the real world is profoundly localized  
and that the cultural singularity that made computers and free  
software in the English speaking sphere is slowly fading away  
_thanks_ to the power of free software and its potential for computer  
literacy (and _not_ for English literacy).

Since we are talking about languages, you should be aware that  
computer languages (lisp included) propose different ways to  
appreciate the computer culture and it would be very  
counterproductive to expect all computer users to "speak" only a  
minimum sub-set of one dialect of one language.

It is just the same for natural languages. And since obviously  
English is not your native language you should be much more aware of  
that than native English users who obviously have no "need" for  
learning other languages since the world comes to them in English...

Have fun in your function-name English !

Jean-Christophe Helary

Re: Why emacs have not native language menu

[Stefan Monnier]

> I think it is practically trivial.

Probably.  I wish someone actually tried it.


        Stefan

Re: Why emacs have not native language menu

[Stefan Monnier]

> And there _are_ difficulties, Thien-Thi Nguyen is right in
> suggesting that you study the issues first (e.g., by reading past
> discussion on the Emacs development list) before dismissing those
> difficulties as ``psychological''.

I think a more worthwhile plan is to first come up with a sample solution,
then see how well it works, what are its most glaring flaws, then try to fix
those flaws, etc...
I suspect it won't be that hard conceptually, but it will require (minor)
changes in most/all Elisp packages, just like Custom did.


        Stefan

Re: Why emacs have not native language menu

[Alexey Pustyntsev]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

> It is just the same for natural languages. And since obviously
> English is not your native language you should be much more aware of
> that than native English users who obviously have no "need" for
> learning other languages since the world comes to them in English...

Speaking about computers, programming etc, I hardly understand
why people won't need to learn English if Emacs is localized. They
need to learn it anyway, needn't they? Hence, there is not much point in
localizing Emacs, unless you want to make things more complex. But is
the expense really worth it? I am afraid not. There are more important
problems to be solved, like printing international characters
correctly (htmlizing a buffer doesn't seem to be Ok, the output may
be ugly). This is, of course, my personal opinion. 

-- 
Rgds
Alexey

Today is Sweetmorn, the 60th day of Confusion in the YOLD 3173

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 25 juil. 07, at 15:44, Alexey Pustyntsev wrote:

> Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:
>
>> It is just the same for natural languages. And since obviously
>> English is not your native language you should be much more aware of
>> that than native English users who obviously have no "need" for
>> learning other languages since the world comes to them in English...
>
> Speaking about computers, programming etc, I hardly understand
> why people won't need to learn English if Emacs is localized. They
> need to learn it anyway, needn't they?

No they don't. Code is just arbitrary strings that mean only what the  
manual (in whatever language it is written) says they mean.

Confusing code (that looks like English words) and English is the  
biggest mistake people make when learning computer languages. And it  
seems like some members of this list have yet to make the difference  
between emacs "function-name" that looks like English and plain English.

> Hence, there is not much point in
> localizing Emacs, unless you want to make things more complex. But is
> the expense really worth it? I am afraid not. There are more important
> problems to be solved, like printing international characters
> correctly (htmlizing a buffer doesn't seem to be Ok, the output may
> be ugly). This is, of course, my personal opinion.

Very good. You know enough English to find your way in emacs. Reverse  
question: is emacs the reason why you learned English ? Is emacs the  
only activity that involves your using English ? Is programming so ?

Can you imagine contexts where emacs can be used in a linguistically  
"neutral" environment ?

Can you imagine that using emacs in this linguistically "neutral"  
environment would benefit from actual native linguistic information ?

If you can't imagine that then you are right: you should focus on  
other issues.


Jean-Christophe Helary

ps: did it ever occur to you that some massively succesful  
programming languages originated from non-English cultural/linguistic  
environments ?

Re: Why emacs have not native language menu

[Peter Dyballa]

Am 25.07.2007 um 02:48 schrieb Ilya Zakharevich:

>> - many elements are sufficiently dynamic that it's going to be
>>   difficult to add support to translate them.
>
> How this is different from localization of other applications?

Look at the changes in CVS: some are "simple" alterations of word  
order in the docstring.

--
Greetings

   Pete                                           0
                                            %-/\_//
                                             (*)(*)

Re: Why emacs have not native language menu

[Dmitri Minaev]

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

On 7/25/07, Alexey Pustyntsev <nospam@dev.null> wrote:
There are more important
> problems to be solved, like printing international characters
> correctly (htmlizing a buffer doesn't seem to be Ok, the output may
> be ugly).

Is it really that bad? The HTML code below and a fragment of its
screenshot seems to be quite close to the state of usability (had it
not been for the entities :))

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<!-- Created by htmlize-1.16 in css mode. -->
<html>
  <head>
    <title>test.org</title>
    <style type="text/css">
    <!--
      body {
        color: #000000;
        background-color: #ffffff;
      }
      .highlight {
        /* highlight */
        background-color: #b4eeb4;
      }
      .org-level-1 {
        /* org-level-1 */
        color: #0000ff;
      }
      .org-level-2 {
        /* org-level-2 */
        color: #b8860b;
      }
      .org-level-3 {
        /* org-level-3 */
        color: #a020f0;
      }
      a {
        color: inherit;
        background-color: inherit;
        font: inherit;
        text-decoration: inherit;
      }
      a:hover {
        text-decoration: underline;
      }
    -->
    </style>
  </head>
  <body>
    <pre>

<span class="org-level-1">* Latin</span>
<span class="org-level-2">**
&#1050;&#1080;&#1088;&#1080;&#1083;&#1083;&#1080;&#1094;&#1072;</span>
<span class="org-level-3">***
&#949;&#955;&#955;&#951;&#957;&#953;&#954;&#942;
&#947;&#955;&#974;&#963;&#963;&#945;</span>
</pre>
  </body>
</html>

-- 
With best regards,
Dmitri Minaev

Russian history blog: http://minaev.blogspot.com

[-- Attachment #2: test.png --]
[-- Type: image/png, Size: 4552 bytes --]

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: Why emacs have not native language menu

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Peter Dyballa 
<Peter_Dyballa@Web.DE>], who wrote in article <mailman.3947.1185351202.32220.help-gnu-emacs@gnu.org>:
> >> - many elements are sufficiently dynamic that it's going to be
> >>   difficult to add support to translate them.
> >
> > How this is different from localization of other applications?
> 
> Look at the changes in CVS: some are "simple" alterations of word  
> order in the docstring.

So what?  I suspect you wanted to add: ... and other applications do
not do this...  1/4 ;-)

Puzzled,
Ilya

P.S.  You sent a blind Cc (A Cc which is not explicitly marked as a Cc
      of a posting).  Such Cc's are very confusing; please do not do
      this.

Re: Why emacs have not native language menu

[Alexey Pustyntsev]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

> No they don't. Code is just arbitrary strings that mean only what the
> manual (in whatever language it is written) says they mean.

I don't think I agree. They need to understand the code, needn't they?

>
> Confusing code (that looks like English words) and English is the
> biggest mistake people make when learning computer languages. And it
> seems like some members of this list have yet to make the difference
> between emacs "function-name" that looks like English and plain
> English.

People created programming languages using a language spoken by human
beings. I think, you see why. Historically, programming languages
were based on English, which, in my opinion, is a good choice. 

> Very good. You know enough English to find your way in emacs. Reverse
> question: is emacs the reason why you learned English ? Is emacs the
> only activity that involves your using English ? Is programming so ?

As a programmer I need English to work with information. I can hardly
imagine my job without the use of English. In most cases, it's just
safer to read an article/book in English than, as it's been correctly
noted, be fooled by a bad translation that is (frequently) done by
non-programmers.     

>
> Can you imagine contexts where emacs can be used in a linguistically
> "neutral" environment ?
>
> Can you imagine that using emacs in this linguistically "neutral"
> environment would benefit from actual native linguistic information ?
>
> If you can't imagine that then you are right: you should focus on
> other issues.

I think creation of a "neutral environment" is a waste of time
as we all can use the environment that's already been created. That
is why I focus on other issues. You are right. 

>
>
> Jean-Christophe Helary
>
> ps: did it ever occur to you that some massively succesful
> programming languages originated from non-English cultural/linguistic
> environments ?

That may suggest that English as a basis for a programming language is
probably a better choice. 

-- 
Rgds
Alexey

Today is Sweetmorn, the 60th day of Confusion in the YOLD 3173

Re: Why emacs have not native language menu

[Pascal Bourguignon]

David Kastrup <dak@gnu.org> writes:

> Pascal Bourguignon <pjb@informatimago.com> writes:
>
>> Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:
>>> [...]
>>> That is a possibility but obviously there are much more Japanese or
>>> French people who use their software now than then.
>>
>> Yes, applications.
>>
>>
>>> What good is a software package if it can't be used by
>>> linguistically challenged people ?
>>
>> Linguistically challenged people just cannot program.
>
> Interestingly, pretty much the only people I know without computing,
> mathematics or science backgrounds that developed admirable mastery
> with Emacs or TeX were proficient in the classics.
>
> And if you have read classical Greek, with its 3 modes, 7 tenses, 3
> numeri, 3 voices, and its complex grammatical structure that has no
> problems spreading some unsuspecting sentence across several pages, a
> sentence which, not entirely unlike a delicate spring, to a river of
> sense swilling and into a sea expelling itself, from a slow start to a
> furious - Odysseus in his ire would have been no less intimidating -
> end continously waxing will finally, after a long, but yet not to be
> compared to those of the masters who can express sentiments like "you
> two should then have started to be a little ashamed of yourself" in a
> single word by choosing all the grammatical details appropriately,
> climax come to an end which, had you not been carefully nesting and
> unnesting the twines of the silkily woven threads of language not
> unlike a stack of bee hives or perhaps the playcards of a master,
> might have been unexpected or at least no longer fathomable.

Yep.  That said, it's still advised to keep your functions within one
screen.  That is, 80x25, which you've done, so no problem.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Nobody can fix the economy.  Nobody can be trusted with their finger
on the button.  Nobody's perfect.  VOTE FOR NOBODY.

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:
> ps: did it ever occur to you that some massively succesful
> programming languages originated from non-English cultural/linguistic
> environments ?

LSE: dead.

There probably was some sovietic programming languages in
Russian.  AFAIK, totally dead.


ADA: designed by French people in English. 

etc...


A lot of programming languages originated from non-English cultural or
linguistic environment (eg, Pascal, Modula-2, Oberon, etc), but they
ALL were designed in English.

It looks like we just don't have enough resources to duplicate science
and techniques in hundreds of different versions.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Why emacs have not native language menu

[Alexey Pustyntsev]

"Dmitri Minaev" <minaev@gmail.com> writes:

> On 7/25/07, Alexey Pustyntsev <nospam@dev.null> wrote:
> There are more important
>> problems to be solved, like printing international characters
>> correctly (htmlizing a buffer doesn't seem to be Ok, the output may
>> be ugly).
>
> Is it really that bad? The HTML code below and a fragment of its
> screenshot seems to be quite close to the state of usability (had it
> not been for the entities :))

Hi Dmitri!

The issue I am considering now is that (my) Cyrillic characters may be
of different height. When I check the result in Firefox they may look
as follows. 

"ЭтА СтрОкА мОжет вЫглЯдеТь ТаК".

It's ugly, isn't it? However, I am not 100% sure the fault is in
htmlize.el. 

-- 
Rgds
Alexey

Today is Sweetmorn, the 60th day of Confusion in the YOLD 3173

Re: Why emacs have not native language menu

[Dmitri Minaev]

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

On 7/25/07, Alexey Pustyntsev <nospam@dev.null> wrote:
> The issue I am considering now is that (my) Cyrillic characters may be
> of different height. When I check the result in Firefox they may look
> as follows.
>
> "ЭтА СтрОкА мОжет вЫглЯдеТь ТаК".
>
> It's ugly, isn't it? However, I am not 100% sure the fault is in
> htmlize.el.

It is. Could you show the HTML code and give the versions of emacs and
htmlize.el?

-- 
With best regards,
Dmitri Minaev

Russian history blog: http://minaev.blogspot.com

[-- Attachment #2: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 25 juil. 07, at 19:51, Pascal Bourguignon wrote:

> Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:
>> ps: did it ever occur to you that some massively succesful
>> programming languages originated from non-English cultural/linguistic
>> environments ?

> A lot of programming languages originated from non-English cultural or
> linguistic environment (eg, Pascal, Modula-2, Oberon, etc), but they
> ALL were designed in English.

Which is totally unrelated to the discussion. When Matsumoto wrote  
his first books on ruby, even if the reserved words were in "English"  
the explanations had to be translated from Japanese. To be  
"localized" to English.

Jean-Christophe Helary

Re: Why emacs have not native language menu

[Peter Dyballa]

Am 25.07.2007 um 12:19 schrieb Ilya Zakharevich:

>>>> - many elements are sufficiently dynamic that it's going to be
>>>>   difficult to add support to translate them.
>>>
>>> How this is different from localization of other applications?
>>
>> Look at the changes in CVS: some are "simple" alterations of word
>> order in the docstring.
>
> So what?  I suspect you wanted to add: ... and other applications do
> not do this...  1/4 ;-)

No, it wasn't this. I was trying to express that it can be very  
cumbersome to keep pace in other languages with all these sublime  
changes.

>
> P.S.  You sent a blind Cc (A Cc which is not explicitly marked as a Cc
>       of a posting).  Such Cc's are very confusing; please do not do
>       this.

I noticed that (Apple) Mail had created a Bcc header and tried to  
remove it, which obviously failed ... Sorry!

--
Greetings

   Pete

Well done is better than well said.
                            -- Benjamin Franklin

Re: Why emacs have not native language menu

[Peter Dyballa]

Am 25.07.2007 um 13:15 schrieb Alexey Pustyntsev:

> "ЭтА СтрОкА мОжет вЫглЯдеТь ТаК".

Can you check in GNU Emacs with C-u C-x = from which font(s) GNU  
Emacs takes these characters? (Save the previous output in *scratch*  
or somewhere else, it will be overwritten when you call describe-char  
next time.) Could be you'd need to prepare a better fontset ...

--
Greetings

   Pete

One doesn't expect governments to obey the law because of some higher  
moral development.  One expects them to obey the law because they  
know that if they don't, those who aren't shot will be hanged.
                                                  --Michael Shirley

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

> On 25 juil. 07, at 19:51, Pascal Bourguignon wrote:
>
>> Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:
>>> ps: did it ever occur to you that some massively succesful
>>> programming languages originated from non-English cultural/linguistic
>>> environments ?
>
>> A lot of programming languages originated from non-English cultural or
>> linguistic environment (eg, Pascal, Modula-2, Oberon, etc), but they
>> ALL were designed in English.
>
> Which is totally unrelated to the discussion. When Matsumoto wrote
> his first books on ruby, even if the reserved words were in "English"
> the explanations had to be translated from Japanese. To be
> "localized" to English.

Well, AFAIK, the firsts versions of the Pascal Report and possibly the
following language were written in Swiss German and later translated
to English, for publication.

What do you think would be the status of ruby in the world today if
this first ruby book hadn't been translated to English?  Wouldn't it
have been easier to directly write it in English?


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Why emacs have not native language menu

[Lennart Borgman (gmail)]

Peter Dyballa wrote:
> 
> Am 25.07.2007 um 13:15 schrieb Alexey Pustyntsev:
> 
>> "ЭтА СтрОкА мОжет вЫглЯдеТь ТаК".
> 
> Can you check in GNU Emacs with C-u C-x = from which font(s) GNU Emacs 
> takes these characters? (Save the previous output in *scratch* or 
> somewhere else, it will be overwritten when you call describe-char next 
> time.) Could be you'd need to prepare a better fontset ...


Maybe it is better to clone the buffer to save the characters:

   M-x clone-buffer

Re: Why emacs have not native language menu

[Alexey Pustyntsev]

"Dmitri Minaev" <minaev@gmail.com> writes:

> On 7/25/07, Alexey Pustyntsev <nospam@dev.null> wrote:
>> The issue I am considering now is that (my) Cyrillic characters may be
>> of different height. When I check the result in Firefox they may look
>> as follows.
>>
>> "ЭтА СтрОкА мОжет вЫглЯдеТь ТаК".
>>
>> It's ugly, isn't it? However, I am not 100% sure the fault is in
>> htmlize.el.
>
> It is. Could you show the HTML code and give the versions of emacs and
> htmlize.el?

Yes, of course. 

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<!-- Created by htmlize-1.16 in css mode. -->
<html>
  <head>
    <title>test_htmlize.txt</title>
    <style type="text/css">
    <!--
      body {
        color: #000000;
        background-color: #8b6508;
        font-weight: bold;
      }
      a {
        color: inherit;
        background-color: inherit;
        font: inherit;
        text-decoration: inherit;
      }
      a:hover {
        text-decoration: underline;
      }
    -->
    </style>
  </head>
  <body>
    <pre>
&#1055;&#1086;&#1089;&#1084;&#1086;&#1090;&#1088;&#1080;&#1090;&#1077;, &#1082;&#1072;&#1082; &#1074;&#1099;&#1075;&#1083;&#1103;&#1076;&#1080;&#1090; &#1101;&#1090;&#1072; &#1089;&#1090;&#1088;&#1086;&#1082;&#1072;.
</pre>
  </body>
</html>

Emacs-CVS 22.0.95.1, htmlize.el-1.16, utf-8.



-- 
Rgds
Alexey

Today is Boomtime, the 61st day of Confusion in the YOLD 3173

Re: Why emacs have not native language menu

[Lennart Borgman (gmail)]

Alexey Pustyntsev wrote:
> Emacs-CVS 22.0.95.1, htmlize.el-1.16, utf-8.

Latest version of htmlize is 1.34:

    http://fly.srk.fer.hr/~hniksic/emacs/htmlize.el

Re: Why emacs have not native language menu

[William Case]

Hi;

Another 2¢


On Wed, 2007-07-25 at 15:55 +0900, Jean-Christophe Helary wrote:
> On 25 juil. 07, at 15:44, Alexey Pustyntsev wrote:
> 
> > Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:
[big snip]
> 
> Jean-Christophe Helary
> 
> ps: did it ever occur to you that some massively succesful  
> programming languages originated from non-English cultural/linguistic  
> environments ?
> 

I have always thought that programming has long ago run out of contorted
Engilsh words and Latin/English script symbols while there are hundreds
of different languages and symbols available and used around the world.
Programming need not be just English based.  Make use of everything that
is available at the actual programming level not just as a translation.

-- 
Regards Bill

Re: Why emacs have not native language menu

[Reiner Steib]

On Tue, Jul 24 2007, Tassilo Horn wrote:

> Another cause is that emacs has a precise terminology. To blur it
> would be a source of confusion.

Do you think the German tutorial blurs the precise terminology?

> Also, emacs has a gazillion extension packages developed mostly by
> one author each and those won't be localized anyway. IMHO a program
> that uses one language and the same terminology everywhere is much
> better than a mixture of (possibly bad) localizations and original
> content.

I agree that a mixture is bad.  But complete translations of manuals
would be fine, I think.

> And finally I think there's no real demand for localizations. The
> average emacs user is a techie, a programer or maybe an author -- at
> least somebody who needs to edit huge amounts of text (no, not M$
> Word). Gretchen Müller won't fetch her mail with Gnus anyway, even
> though it was localized.

There are several people in de.comm.software.gnus who say that they
often have difficulties to understand Gnus manuals.  Such users would
benefit from German translations of the Gnus manuals.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Why emacs have not native language menu

[Reiner Steib]

On Tue, Jul 24 2007, Tassilo Horn wrote:

> Let's take "Kill Buffer" as an example. That would be "Töte
> Zwischenspeicher" in German

No need to search for a bad translation of buffer.  "Puffer" is good
enough.

> or "tuer cet amortisseur" in French if you translate it
> literally. Ok, literal translation won't be done by good localizers,
> but it's really hard to translate a concept like "killing" in emacs
> consistently.

,----[ TUTORIAL.de ]
| Emacs unterscheidet zwei Klassen von Löschbefehlen (was man im
| Deutschen leider nicht gut wiedergeben kann): `killing' (umbringen)
| und `deleting' (löschen).  Wenn man sich vorstellt, daß `yanking' den
| Begriff `von den Toten erwecken' darstellt, dann hat man ungefähr eine
| Vorstellung von der Metapher -- Von einem `kill'-Befehl gelöschter
| Text wird gespeichert und kann bei Bedarf mit C-y zurückgeholt
| werden.  Von einem `delete'-Befehl entfernter Text (in der Regel
| einzelne Zeichen, leere Zeilen und Zwischenräume) wird nicht extra
| gespeichert und kann daher auch nicht zurückgeholt werden.
`----

Not too bad, I think.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Translation of Emacs Info manuals (was: Emacs localization ...)

[Reiner Steib]

On Tue, Jul 24 2007, Eli Zaretskii wrote:

> If translators volunteer to translate the user manual (a formidable
> job, if you ask me, since the manual is HUGE), there should be no
> problem at all to display a localized manual, too.

On <http://www.jpl.org/gnus-doc-ja.html>, Katsumi Yamaoka (Cc-ed)
provides Japanese translations of all Gnus related Info manuals:

  emacs-mime-ja gnus-coding-ja gnus-ja message-ja pgg-ja sasl-ja sieve-ja

If we can get assignments for these (I'm not sure if he has done all
the translation himself), it might be a start to add those to Emacs.

It would be interesting to know how much work it was and what were the
major difficulties.  (The Gnus manual is (roundabout) half of the size
of the Emacs manual.)

[ Should we shift this to emacs-devel? ]

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Why emacs have not native language menu

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Peter Dyballa 
<Peter_Dyballa@Web.DE>], who wrote in article <mailman.3958.1185366162.32220.help-gnu-emacs@gnu.org>:

> >>>> - many elements are sufficiently dynamic that it's going to be
> >>>>   difficult to add support to translate them.
> >>>
> >>> How this is different from localization of other applications?
> >>
> >> Look at the changes in CVS: some are "simple" alterations of word
> >> order in the docstring.
> >
> > So what?  I suspect you wanted to add: ... and other applications do
> > not do this...  1/4 ;-)
> 
> No, it wasn't this. I was trying to express that it can be very  
> cumbersome to keep pace in other languages with all these sublime  
> changes.

And AGAIN, you did not explain why do you think Emacs differs any way
from other application.

> I noticed that (Apple) Mail had created a Bcc header and tried to  
> remove it, which obviously failed ... Sorry!

[I do not think this is the Bcc thing.  Your messages are To: me, and
 Cc the mailing list.  The confusion comes from the fact that the list
 is mirrored into a newsgroup.  One can consider it as a gray area
 of netiquette.]

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
>> No, it wasn't this. I was trying to express that it can be very  
>> cumbersome to keep pace in other languages with all these sublime  
>> changes.
>
> And AGAIN, you did not explain why do you think Emacs differs any way
> from other application.

You'd have to read GEB to understand why emacs differs from other
applications...  (And remember that GEB took 11 years to translate to
French).

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
        Un chat errant
se soulage
        dans le jardin d'hiver
                                        Shiki

Re: Why emacs have not native language menu

[Giorgos Keramidas]

On Tue, 24 Jul 2007 16:19:14 +0200, Hadron <hadronquark@googlemail.com> wrote:
>Pascal Bourguignon <pjb@informatimago.com> writes:
>>> No. That is NOT what emacs is. eLisp is the programming
>>> language. Emacs is an infrastructure which supports multiple
>>> applications programmed in elisp. They can be localised.
>>
>> Look, if you asked to localize microemacs or nano, I'd say, no
>> problem go ahead.  But emacs is lisp.
>
> We are talking the command names interfaces and help texts - not the
> function names. e.g you dont see "find-file-at-point" in the
> menu. No. You find "Open File" or similar.

But then you have to write the manual for this localized menu,
and all sorts of problems creep up.  For example it is _very_
easy to explain to an English-speaking person that `M-x find-file
RET path RET' is the same as `menu: File | Open ...', and the
English-speaking person will quickly get used to the term
`find-file'.  If you describe in an ISO 8859-7 Greek manual that
the following are equivalent:

    M-x find-file RET διαδρομή RET
    μενού: Αρχείο | Άνοιγμα ...

which are the localized versions, then it's not as easy to
remember that the `random' name `find-file' maps easily to the
Greek text for "Open..." :-(

While I agree that localization *is* useful, it's also my
understanding that it is not a particularly easy task, nor an
effort that can always create the same mental `mappings' between
menu entries, help text, tooltips, keyboard sequences, etc.

Re: Translation of Emacs Info manuals (was: Emacs localization ...)

[Eli Zaretskii]

> From: Reiner Steib <reinersteib+gmane@imap.cc>
> Cc: help-gnu-emacs@gnu.org, Katsumi Yamaoka <yamaoka@jpl.org>
> Date: Wed, 25 Jul 2007 22:00:08 +0200
> 
> On <http://www.jpl.org/gnus-doc-ja.html>, Katsumi Yamaoka (Cc-ed)
> provides Japanese translations of all Gnus related Info manuals:
> 
>   emacs-mime-ja gnus-coding-ja gnus-ja message-ja pgg-ja sasl-ja sieve-ja
> 
> If we can get assignments for these (I'm not sure if he has done all
> the translation himself), it might be a start to add those to Emacs.

Indeed.

> [ Should we shift this to emacs-devel? ]

Yes, please.

Re: Why emacs have not native language menu

[Dmitri Minaev]

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

On 7/25/07, Alexey Pustyntsev <nospam@dev.null> wrote:
> Emacs-CVS 22.0.95.1, htmlize.el-1.16, utf-8.
>

>From what I see in the browser, it's OK (see the attached image).
Could it be a problem with the fonts used by Firefox?

-- 
With best regards,
Dmitri Minaev

Russian history blog: http://minaev.blogspot.com

[-- Attachment #2: test.png --]
[-- Type: image/png, Size: 2389 bytes --]

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]

_______________________________________________
help-gnu-emacs mailing list
help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Re: Translation of Emacs Info manuals

[Katsumi Yamaoka]

> On Tue, Jul 24 2007, Eli Zaretskii wrote:

>> If translators volunteer to translate the user manual (a formidable
>> job, if you ask me, since the manual is HUGE), there should be no
>> problem at all to display a localized manual, too.

>>>>> Reiner Steib wrote:

> On <http://www.jpl.org/gnus-doc-ja.html>, Katsumi Yamaoka (Cc-ed)
> provides Japanese translations of all Gnus related Info manuals:

>   emacs-mime-ja gnus-coding-ja gnus-ja message-ja pgg-ja sasl-ja sieve-ja

> If we can get assignments for these (I'm not sure if he has done all
> the translation himself), it might be a start to add those to Emacs.

It can be a formidable job, too.  The main problem is that
the whereabouts of at least a certain author who worked in early
days is now unknown.  (And even if I can contact him, the companies
in Japan that employ him and other authors might grudge issuing
a disclaimer.)  Anyway I'm going to try contacting the authors.

The Japanese translation of the Gnus manual was first made by
Kazuyuki Ienaga with Gnus v5.0.15, and Yoshiki Hayashi and
Keisuke Mori upgraded it for Semi-gnus afterward.  I and Hiroyuki
Nakaji made it be for No Gnus again.

> It would be interesting to know how much work it was and what were the
> major difficulties.  (The Gnus manual is (roundabout) half of the size
> of the Emacs manual.)

It took about four months first to read through the English
version, compare it with the existing Japanese version, correct
it, add new translations, and sometimes fix the original and
the Lisp source.   If it was made from scratch, it might have
taken a year or more.  People who wish to make a new translation,
in Chinese for example, will probably need to be skillful in Gnus
and Emacs Lisp to understand what Lars meant in the manual.
Since I don't necessarily know all about Gnus, I frequently read
the source code while translating the manual.  But it was not a
boring work because Lars is a very good writer.  His work sparkled
with wit and was humorous, though some clueless expressions
annoyed me.  (I went to the library to ask for the Japanese
translations of Edgar Allan Poe's and Charles Reznikoff's works.)

> [ Should we shift this to emacs-devel? ]

Well, please do so if it is not a mater that devel is not open
to Usenet.

Re: Why emacs have not native language menu

[Tassilo Horn]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

Hi Reiner,

>> Another cause is that emacs has a precise terminology. To blur it
>> would be a source of confusion.
>
> Do you think the German tutorial blurs the precise terminology?

I've never read it. But after a quick overview I'd say, no. But the
tutorial is written by one person, wheras if every emacs manual was to
be translated, there would be a need for quite a few more translators.
And the bigger the group, the less are the chances to keep terminology
precise and consistent.

But what is this English warning talking about? Here, with `emacs -Q'
`C-x C-b' is still bound to `list-buffers'.

,----
| ** C-x C-b has been rebound, but you can use the `Buffers' menu instead
|    [More] **
`----

> I agree that a mixture is bad.  But complete translations of manuals
> would be fine, I think.

Yes, for manuals I agree somewhat, but as others mentioned: Only the
original English manual is the definitive guide.

But translations could be useful for poeple, anyway.

>> Gretchen Müller won't fetch her mail with Gnus anyway, even though it
>> was localized.
>
> There are several people in de.comm.software.gnus who say that they
> often have difficulties to understand Gnus manuals.

The Gnus manual is quite special, because Lars wrote it in a very
entertaining style. Maybe it's a bit harder to read and less precise
than the usual emacs documentation.

Bye,
Tassilo
-- 
My work on  free software is motivated by  an idealistic goal: spreading
freedom and  cooperation. I want  to encourage free software  to spread,
replacing proprietary  software that forbids cooperation,  and thus make
our society better. (Richard M. Stallman)

Re: Why emacs have not native language menu

[Tassilo Horn]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

Hi Reiner,

> ,----[ TUTORIAL.de ]
> | Emacs unterscheidet zwei Klassen von Löschbefehlen (was man im
> | Deutschen leider nicht gut wiedergeben kann): `killing' (umbringen)
> | und `deleting' (löschen).  Wenn man sich vorstellt, daß `yanking'
> | den Begriff `von den Toten erwecken' darstellt, dann hat man
> | ungefähr eine Vorstellung von der Metapher -- Von einem
> | `kill'-Befehl gelöschter Text wird gespeichert und kann bei Bedarf
> | mit C-y zurückgeholt werden.  Von einem `delete'-Befehl entfernter
> | Text (in der Regel einzelne Zeichen, leere Zeilen und Zwischenräume)
> | wird nicht extra gespeichert und kann daher auch nicht zurückgeholt
> | werden.
> `----
>
> Not too bad, I think.

Indeed. But I miss a hint that you often can get back deleted text with
`undo'.

Anyway, you can read that the translator knows emacs, because that's not
just a translation. The German tutorial uses a lot additions to clearify
terminology. But to translate all of emacs manuals there are probably
not enough emacs users to do it, so we need to let it be done by people
that are skilled in linguistics but don't know emacs good enough.

Bye,
Tassilo
-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_

Re: Why emacs have not native language menu

[Tassilo Horn]

Tassilo Horn <tassilo@member.fsf.org> writes:

Hey,

> But what is this English warning talking about? Here, with `emacs -Q'
> `C-x C-b' is still bound to `list-buffers'.
>
> ,----
> | ** C-x C-b has been rebound, but you can use the `Buffers' menu instead
> |    [More] **
> `----

That's really a cool feature. Emacs found out that I've bound `C-x C-b'
to `ibuffer' instead of the standard `list-buffers' and inserted this
warning dynamically. But, of course, in TUTORIAL.de it should have been
localized. ;-)

Bye,
Tassilo
-- 
A child of five could understand this! Fetch me a child of five!

Re: Why emacs have not native language menu

[Hadron]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
> Hi Reiner,
>
>>> Another cause is that emacs has a precise terminology. To blur it
>>> would be a source of confusion.
>>
>> Do you think the German tutorial blurs the precise terminology?
>
> I've never read it. But after a quick overview I'd say, no. But the
> tutorial is written by one person, wheras if every emacs manual was to
> be translated, there would be a need for quite a few more translators.
> And the bigger the group, the less are the chances to keep terminology
> precise and consistent.

It is neither precise nor consistent if someone misunderstands it.

It is fairly self evident that emacs applications that could talk
multiple languages and manuals in multiple languages would be a benefit
for the end user IF it could be done.

e.g C is "in English" but there are plenty of German C Manuals and
tutorials to explain what the "English" keywords mean.

Re: Translation of Emacs Info manuals

[Eli Zaretskii]

> Date: Thu, 26 Jul 2007 13:42:19 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: help-gnu-emacs@gnu.org
> 
> People who wish to make a new translation,
> in Chinese for example, will probably need to be skillful in Gnus
> and Emacs Lisp to understand what Lars meant in the manual.

That is generally bad, since most translators are not programmers.
It is for this reason that program developers are generally requested
to write code that produces text messages in a way that a message's
intent is clear without looking at the code which produces it.

Re: Why emacs have not native language menu

[Hadron]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On Tue, 24 Jul 2007 16:19:14 +0200, Hadron <hadronquark@googlemail.com> wrote:
>>Pascal Bourguignon <pjb@informatimago.com> writes:
>>>> No. That is NOT what emacs is. eLisp is the programming
>>>> language. Emacs is an infrastructure which supports multiple
>>>> applications programmed in elisp. They can be localised.
>>>
>>> Look, if you asked to localize microemacs or nano, I'd say, no
>>> problem go ahead.  But emacs is lisp.
>>
>> We are talking the command names interfaces and help texts - not the
>> function names. e.g you dont see "find-file-at-point" in the
>> menu. No. You find "Open File" or similar.
>
> But then you have to write the manual for this localized menu,
> and all sorts of problems creep up.  For example it is _very_
> easy to explain to an English-speaking person that `M-x find-file
> RET path RET' is the same as `menu: File | Open ...', and the
> English-speaking person will quickly get used to the term
> `find-file'.  If you describe in an ISO 8859-7 Greek manual that
> the following are equivalent:
>
>     M-x find-file RET διαδρομή RET
>     μενού: Αρχείο | Άνοιγμα ...
>
> which are the localized versions, then it's not as easy to
> remember that the `random' name `find-file' maps easily to the
> Greek text for "Open..." :-(
>
> While I agree that localization *is* useful, it's also my
> understanding that it is not a particularly easy task, nor an
> effort that can always create the same mental `mappings' between
> menu entries, help text, tooltips, keyboard sequences, etc.
>

No one suggested it was trivial. But to discount it out of course just
because emacs "is eLisp" is a tad silly IMO.

Jesus, half the Emacs manual is hard enough to understand in English! :)

Re: Why emacs have not native language menu

[David Hansen]

On Thu, 26 Jul 2007 13:33:57 +0200 Hadron wrote:

> e.g C is "in English" but there are plenty of German C Manuals and
> tutorials to explain what the "English" keywords mean.

Hrm, I think that was some computer science book: "Wir unterscheiden die
Funktion f nach x." :)

Translations of scientific or technical Literature is usually pretty
bad.  That doesn't mean there are exceptions to this rule:  A physics
professor told a story that it was quite common to translate Russian
books to English and vice versa w/o giving clear credit to the
original.  So one time it happens that a book got translated back to the
original language and someone was surprised that finally it's possible
to understand the book :)

David

Re: Why emacs have not native language menu

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
> Date: Thu, 26 Jul 2007 00:56:14 +0300
> 
> If you describe in an ISO 8859-7 Greek manual that
> the following are equivalent:
> 
>     M-x find-file RET διαδρομή RET
>     μενού: Αρχείο | Άνοιγμα ...
> 
> which are the localized versions, then it's not as easy to
> remember that the `random' name `find-file' maps easily to the
> Greek text for "Open..." :-(

If those hypothetical Greek users understand and remember find-file
_today_, when it is described in a purely English manual, they won't
have a harder time when the explanations are in Greek.  Just like a
Greek book talking about `typedef' in C or `defun' in Lisp will be
easier for them to read than an English book.

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 26 juil. 07, at 22:36, Hadron wrote:

> Jesus, half the Emacs manual is hard enough to understand in  
> English! :)

This is basically why translating is difficult: the original  
documentation is poorly written.

And technical documentation is generally poorly written. (I'm just  
trying a silly generalization to balance with other silly  
generalizations...)


Jean-Christophe Helary

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On Tue, 24 Jul 2007 16:19:14 +0200, Hadron <hadronquark@googlemail.com> wrote:
>> We are talking the command names interfaces and help texts - not the
>> function names. e.g you dont see "find-file-at-point" in the
>> menu. No. You find "Open File" or similar.
>
> But then you have to write the manual for this localized menu,
> and all sorts of problems creep up.  For example it is _very_
> easy to explain to an English-speaking person that `M-x find-file
> RET path RET' is the same as `menu: File | Open ...', and the
> English-speaking person will quickly get used to the term
> `find-file'.  If you describe in an ISO 8859-7 Greek manual that
> the following are equivalent:
>
>     M-x find-file RET διαδρομή RET
>     μενού: Αρχείο | Άνοιγμα ...
>
> which are the localized versions, then it's not as easy to
> remember that the `random' name `find-file' maps easily to the
> Greek text for "Open..." :-(
>
> While I agree that localization *is* useful, it's also my
> understanding that it is not a particularly easy task, nor an
> effort that can always create the same mental `mappings' between
> menu entries, help text, tooltips, keyboard sequences, etc.

While theorically I wouldn't object to the translation of user
interface elements, in practice, and by my experience, I still think
it's not a good idea.  

lisp function:   find-file

emacs command:   find-file      ; on GNU emacs, command names are identical 
                                ; to the name of the function declared 
                                ; interactive. On some other emacs, 
                                ; find-file may give a command named:
                                ; Find File

menu:            File / Open...         ; in English
                 Fichier / Ouvrir...    ; in French
                 Archivos / Abrir...    ; in Spanish
                                        ; etc..

Ok, so the practical problem we have when we translate user interface
elements occurs in these kind of situation:

A French speaking user, using a French localized emacs, ask a support
question to somebody who use a Russian emacs.  The common language of
these two people is German.

Assume the French user doesn't know anything about lisp and English
and obviously Russian, and the Russian doesn't know anything about
French.
 

Well with their localized emacs they're stranded.  They cannot help
each other.  They can try, the Russian will try to translate File/Open
from Russian into German, and the French one will try to translate
from German to French, and the risk of errors in these double
translations is very big.

These situations happen everyday with MacOSX (and I assume
MS-Windows), and there is no way arround it, unless you can tell the
user to open the terminal window and give him commands to type in
"computer english" (unix shell).  Well, there is a way arround it,
it's to have the "support" person to use the same localization as the
supported user. But this increase cost.  You have to pay for
commercial support, that's why it's a good thing for commercial
vendors to localize.  But for free software, when you want to provide
free support on the Internet, or if you want to get expert support on
the Internet, localization will prevent you do interchange it.


If you stop the localization at the level of menus, you could still
indicate the user to type M-x find-file RET.  If you translate also
the command names, you will have to tell him to go to the *scratch*
buffer, and type (find-file "/some/file") C-x C-e.  If you also
translate the lisp language, you've won a battle against the free
software philosophy, totally preventing users to help each others.



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 27 juil. 07, at 00:03, Pascal Bourguignon wrote:

> A French speaking user, using a French localized emacs, ask a support
> question to somebody who use a Russian emacs.  The common language of
> these two people is German.

A French speaking user using a French localized emacs will ask people  
from the French emacs community. Such language based communities  
already exist.

I don't really understand what your practical experiences with  
translations or multilingual support or locale based communities are,  
but I think you've been in emacs too long.

Jean-Christophe Helary

Re: Why emacs have not native language menu

[Pascal Bourguignon]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

> On 27 juil. 07, at 00:03, Pascal Bourguignon wrote:
>
>> A French speaking user, using a French localized emacs, ask a support
>> question to somebody who use a Russian emacs.  The common language of
>> these two people is German.
>
> A French speaking user using a French localized emacs will ask people
> from the French emacs community. Such language based communities
> already exist.

Yes, but obviously, they don't contain all the experts, and often they
don't contain THE expert who is needed.

That's why we're on gnu.emacs.help, not on fr.comp.applications.emacs.


> I don't really understand what your practical experiences with
> translations or multilingual support or locale based communities are,
> but I think you've been in emacs too long.

Just compare the traffic in comp.any.thing and the equivalent
CC.comp.translated.any.thing groups.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.

Re: Why emacs have not native language menu

[Giorgos Keramidas]

On Thu, 26 Jul 2007 10:56:36 -0400, Eli Zaretskii <eliz@gnu.org> wrote:
>> Newsgroups: gnu.emacs.help
>> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
>> Date: Thu, 26 Jul 2007 00:56:14 +0300
>>
>> If you describe in an ISO 8859-7 Greek manual that
>> the following are equivalent:
>>
>>     M-x find-file RET διαδρομή RET
>>     μενού: Αρχείο | Άνοιγμα ...
>>
>> which are the localized versions, then it's not as easy to
>> remember that the `random' name `find-file' maps easily to the
>> Greek text for "Open..." :-(
>
> If those hypothetical Greek users understand and remember find-file
> _today_, when it is described in a purely English manual, they won't
> have a harder time when the explanations are in Greek.  Just like a
> Greek book talking about `typedef' in C or `defun' in Lisp will be
> easier for them to read than an English book.

True.  What I mean is that for an English-speaking reader, the
explanation of `defun' can be ``define function'', and the
English-speaking user will appreciate the `de'-fine `fun'-ction mnemonic
rule, and will even enjoy the wordplay: `define' <=> `defun'.

That's impossible for a Greek user who reads a Greek translation of the
manual.  Losing some of the fun of reading an English version of the
manual does _not_ invalidate the reasons why people choose to translate
English documentation, though.  This is _exactly_ why I am part of the
team which translates FreeBSD documentation to Greek, after all :-)

- Giorgos

Re: Why emacs have not native language menu

[Eli Zaretskii]

> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
> Date: Fri, 27 Jul 2007 00:02:33 +0900
> 
> 
> On 26 juil. 07, at 22:36, Hadron wrote:
> 
> > Jesus, half the Emacs manual is hard enough to understand in  
> > English! :)
> 
> This is basically why translating is difficult: the original  
> documentation is poorly written.
> 
> And technical documentation is generally poorly written. (I'm just  
> trying a silly generalization to balance with other silly  
> generalizations...)

I hope this particular silly generalization doesn't include the Emacs
manual, because I think it's actually written quite well, as
documentation goes.  At least the attention it gets from the
maintainers is significant.

If you have examples of poor Emacs documentation to show, please do
(and eventually submit them as bug report to bug-gnu-emacs mailing
list).

Re: Why emacs have not native language menu

[Reiner Steib]

On Thu, Jul 26 2007, Tassilo Horn wrote:

> But, of course, in TUTORIAL.de it should have been localized. ;-)

ACK, I have raised this issue in November 2006
<http://thread.gmane.org/v9d57gcxq1.fsf%40marauder.physik.uni-ulm.de>.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 27 juil. 07, at 04:12, Eli Zaretskii wrote:

>> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
>> Date: Fri, 27 Jul 2007 00:02:33 +0900
>>
>>
>> On 26 juil. 07, at 22:36, Hadron wrote:
>>
>>> Jesus, half the Emacs manual is hard enough to understand in
>>> English! :)
>>
>> This is basically why translating is difficult: the original
>> documentation is poorly written.
>>
>> And technical documentation is generally poorly written. (I'm just
>> trying a silly generalization to balance with other silly
>> generalizations...)
>
> I hope this particular silly generalization doesn't include the Emacs
> manual, because I think it's actually written quite well, as
> documentation goes.  At least the attention it gets from the
> maintainers is significant.
>
> If you have examples of poor Emacs documentation to show, please do
> (and eventually submit them as bug report to bug-gnu-emacs mailing
> list).

I sincerely think the emacs documentation (manual, elisp reference,  
elist introduction) is verbose. I think the structure is not explicit  
enough. I think they don't provide an easy access to information.  
Basically such manuals could be at least half the size they are. But  
this is obviously not something that can be fixed easily, and is also  
a matter of taste more than anything else. The tutorial is much  
better though.

And I think that is the reason why we've seen so little translation  
of the whole thing, even though emacs has been around for a while  
now. The fact that there is no localization framework also helps: it  
shows that emacs developers were specifically _not_ interested in  
getting involved with reaching out to other linguistic communities.  
It makes it difficult for translators to have their work advertised  
properly (even though there are links to some translations), it makes  
updating the translation a fantastic endeavor.



Jean-Christophe Helary

Re: Why emacs have not native language menu

[Eli Zaretskii]

> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
> Date: Fri, 27 Jul 2007 09:23:45 +0900
> 
> I sincerely think the emacs documentation (manual, elisp reference,  
> elist introduction) is verbose. I think the structure is not explicit  
> enough. I think they don't provide an easy access to information.  

You will have to back this up with explicit examples (more than one
for each category, preferably), to convince the maintainers to treat
these assertions seriously.  (The emacs-devel list is the right place
to post the examples and for any serious discussion of problems with
the Emacs documentation.)

Wrt to verbosity, the manual is usually accused of the opposite: that
it leaves too much out.

I have no idea what you mean under ``the structure is not explicit
enough''--the structure of what?

As for easy access to information (assuming I understood what you
mean), the index search command (`i' in Info mode) normally gets me to
the right place very quickly and efficiently.

> And I think that is the reason why we've seen so little translation  
> of the whole thing, even though emacs has been around for a while  
> now. The fact that there is no localization framework also helps: it  
> shows that emacs developers were specifically _not_ interested in  
> getting involved with reaching out to other linguistic communities.  

I think the real problem is that no one stepped forward and
volunteered.  It's true that the core maintainers generally have a
good command of English, and have too much on their plate to make this
their first priority, but that would not prevent them from welcoming
any work on localization--witness the proliferation of translations of
the tutorial and reference cards between Emacs 21.x and 22.1.

Emacs is a project run by volunteers on their free time, so features
that get implemented are those for which interested individuals have
enough motivation to sit down and code them.  There are other
important features that Emacs doesn't have because no one volunteered;
it is really silly to accuse the maintainers of being not interested
in all of them.

> It makes it difficult for translators to have their work advertised  
> properly (even though there are links to some translations), it makes  
> updating the translation a fantastic endeavor.

I don't understand what difficulties you have in mind.  It's not like
the Emacs maintainers are actively interfering with adding links or
advertisement.

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 27 juil. 07, at 19:47, Eli Zaretskii wrote:

>> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
>> Date: Fri, 27 Jul 2007 09:23:45 +0900
>>
>> I sincerely think the emacs documentation (manual, elisp reference,
>> elist introduction) is verbose. I think the structure is not explicit
>> enough. I think they don't provide an easy access to information.
>
> You will have to back this up with explicit examples (more than one
> for each category, preferably), to convince the maintainers to treat
> these assertions seriously.  (The emacs-devel list is the right place
> to post the examples and for any serious discussion of problems with
> the Emacs documentation.)

I did not intend to discuss the issues because I have no solution to  
propose, but you asked me what I thought about the manuals and I  
replied.

There is a lot of talk about the necessity of learning English to be  
a programmer etc but the thing is that the utter mass of the thing  
and the way it is visually displayed does not facilitates reading  
_especially_ for non natives (and I am strictly writing from this  
point of view).

> As for easy access to information (assuming I understood what you
> mean), the index search command (`i' in Info mode) normally gets me to
> the right place very quickly and efficiently.

I work with OSX and I have yet to find how to set the dictionary for  
the spell-buffer function. The code (not the manual) says that it is  
an interface to the UNIX spell program. "man spell" on OSX does not  
give anything, on the web I find that spell is mapped to ispell, but  
for some reason the dictionary spell uses in emacs is different from  
the dictionary set for ispell... The manual itself does not mention  
spell-buffer at all.

> I think the real problem is that no one stepped forward and
> volunteered.  It's true that the core maintainers generally have a
> good command of English, and have too much on their plate to make this
> their first priority, but that would not prevent them from welcoming
> any work on localization--witness the proliferation of translations of
> the tutorial and reference cards between Emacs 21.x and 22.1.

Considering that the last serious exchange on localization dates back  
from 2001 and that a number of the participants now are either of the  
"we don't need localization/localization is dangerous" type or of the  
"we don't need elisp for that let's use gettext" type I don't really  
wonder why things have not progressed in 6 years.

> Emacs is a project run by volunteers on their free time, so features
> that get implemented are those for which interested individuals have
> enough motivation to sit down and code them.  There are other
> important features that Emacs doesn't have because no one volunteered;
> it is really silly to accuse the maintainers of being not interested
> in all of them.

I am not accusing anybody. I am myself spending a lot of time on a  
free software by writing documentation and handling user support in a  
number of languages and I know _exactly_ what you are saying. But not  
being a coder myself the only thing I can do is suggest ways from  
experience as a translator who does that for a living and as a  
localization community participant and organizer.

>> It makes it difficult for translators to have their work advertised
>> properly (even though there are links to some translations), it makes
>> updating the translation a fantastic endeavor.
>
> I don't understand what difficulties you have in mind.  It's not like
> the Emacs maintainers are actively interfering with adding links or
> advertisement.

Practically speaking it is difficult to translate a manual that  
refers to menu items and messages in a language that is different  
from the language used in the manual. That sometimes requires a lot  
of extra explanations. This is why most of the successfully localized  
software packages are localized from the ground up. Even though that  
looks like a more daunting tasks it is in fact much easier and  
straightforward.


Jean-Christophe Helary

Re: Why emacs have not native language menu

[Hadron]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

> On 27 juil. 07, at 04:12, Eli Zaretskii wrote:
>
>>> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
>>> Date: Fri, 27 Jul 2007 00:02:33 +0900
>>>
>>>
>>> On 26 juil. 07, at 22:36, Hadron wrote:
>>>
>>>> Jesus, half the Emacs manual is hard enough to understand in
>>>> English! :)
>>>
>>> This is basically why translating is difficult: the original
>>> documentation is poorly written.
>>>
>>> And technical documentation is generally poorly written. (I'm just
>>> trying a silly generalization to balance with other silly
>>> generalizations...)
>>
>> I hope this particular silly generalization doesn't include the Emacs
>> manual, because I think it's actually written quite well, as
>> documentation goes.  At least the attention it gets from the
>> maintainers is significant.
>>
>> If you have examples of poor Emacs documentation to show, please do
>> (and eventually submit them as bug report to bug-gnu-emacs mailing
>> list).
>
> I sincerely think the emacs documentation (manual, elisp reference,
> elist introduction) is verbose. I think the structure is not explicit
> enough. I think they don't provide an easy access to information.
> Basically such manuals could be at least half the size they are. But
> this is obviously not something that can be fixed easily, and is also
> a matter of taste more than anything else. The tutorial is much
> better though.

The "Learning Gnu Emacs" book is excellent.

>
> And I think that is the reason why we've seen so little translation of
> the whole thing, even though emacs has been around for a while
> now. The fact that there is no localization framework also helps: it
> shows that emacs developers were specifically _not_ interested in
> getting involved with reaching out to other linguistic communities.
> It makes it difficult for translators to have their work advertised
> properly (even though there are links to some translations), it makes
> updating the translation a fantastic endeavor.
>
>
>
> Jean-Christophe Helary
>
>
>

-- 

Re: Why emacs have not native language menu

[Eli Zaretskii]

> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
> Date: Fri, 27 Jul 2007 20:52:50 +0900
> 
> 
> On 27 juil. 07, at 19:47, Eli Zaretskii wrote:
> 
> >> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
> >> Date: Fri, 27 Jul 2007 09:23:45 +0900
> >>
> >> I sincerely think the emacs documentation (manual, elisp reference,
> >> elist introduction) is verbose. I think the structure is not explicit
> >> enough. I think they don't provide an easy access to information.
> >
> > You will have to back this up with explicit examples (more than one
> > for each category, preferably), to convince the maintainers to treat
> > these assertions seriously.  (The emacs-devel list is the right place
> > to post the examples and for any serious discussion of problems with
> > the Emacs documentation.)
> 
> I did not intend to discuss the issues because I have no solution to  
> propose, but you asked me what I thought about the manuals and I  
> replied.

I'm asking to give the details.  What you wrote cannot be used to
improve the documentation because it does not say anything specific,
just slogans.

> > As for easy access to information (assuming I understood what you
> > mean), the index search command (`i' in Info mode) normally gets me to
> > the right place very quickly and efficiently.
> 
> I work with OSX and I have yet to find how to set the dictionary for  
> the spell-buffer function. The code (not the manual) says that it is  
> an interface to the UNIX spell program. "man spell" on OSX does not  
> give anything, on the web I find that spell is mapped to ispell, but  
> for some reason the dictionary spell uses in emacs is different from  
> the dictionary set for ispell... The manual itself does not mention  
> spell-buffer at all.

Why are you trying to use spell-buffer, when the current spelling
interface is ispell-buffer and flyspell-mode?  Both of them use aspell
or ispell, which are much more modern spellers than the ancient spell.

I think this is your problem.

In any case, this does not seem to be an Emacs documentation problem,
since the manuals you mention are not Emacs manuals.  If you type
"i spelling RET" in the Emacs manual inside the Emacs Info mode, you
will land in the section that describes the commands which should
"just work".

> > I think the real problem is that no one stepped forward and
> > volunteered.  It's true that the core maintainers generally have a
> > good command of English, and have too much on their plate to make this
> > their first priority, but that would not prevent them from welcoming
> > any work on localization--witness the proliferation of translations of
> > the tutorial and reference cards between Emacs 21.x and 22.1.
> 
> Considering that the last serious exchange on localization dates back  
> from 2001 and that a number of the participants now are either of the  
> "we don't need localization/localization is dangerous" type or of the  
> "we don't need elisp for that let's use gettext" type I don't really  
> wonder why things have not progressed in 6 years.

Like I said: no one stepped forward.  We are still waiting.

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 27 juil. 07, at 21:06, Eli Zaretskii wrote:

> I'm asking to give the details.  What you wrote cannot be used to
> improve the documentation because it does not say anything specific,
> just slogans.

If I think it is verbose and most of the reviewers don't think it is,  
it would be arrogant of me to try to modify stuff. I don't like the  
style and I don't like the way the sentence look when displayed  
either as HTML or PDF or anything I try to read them with. From what  
I have read online from the manual I am not going to spend money to  
buy it. And even if I had to translate it for money I don't think I  
would do it. Even though I bought the introduction to elisp, which I  
think also is badly written. Specifically there is too much text for  
too little code and too little exercises. The functions don't seem to  
come in any specific order but what Chassell had in mind when he  
wrote the text and if there is an order of progression it is not  
explicit at all.

> Why are you trying to use spell-buffer, when the current spelling
> interface is ispell-buffer and flyspell-mode?  Both of them use aspell
> or ispell, which are much more modern spellers than the ancient spell.
>
> I think this is your problem.
>
> In any case, this does not seem to be an Emacs documentation problem,
> since the manuals you mention are not Emacs manuals.  If you type
> "i spelling RET" in the Emacs manual inside the Emacs Info mode, you
> will land in the section that describes the commands which should
> "just work".

Of course the spell-buffer problem is a manual problem.

This function is a part of the distribution and generally speaking I  
don't "ispellcheck" a text, I spellcheck a text, hence I find it more  
straightforward to M-x spell-buffer my text.

There is no information about spell-buffer in the manual and one has  
to look at the function code to find that it refers to something that  
is supposed to me mapped to ispell but then the ispell-change- 
dictionary does not affect the behavior of spell-buffer.

So either this is a manual bug, or the distribution should _really_  
map spell-buffer to ispell-buffer.


Jean-Christophe Helary

Re: Why emacs have not native language menu

[Jean-Christophe Helary]

On 27 juil. 07, at 21:00, Hadron wrote:
>
> The "Learning Gnu Emacs" book is excellent.

Maybe it is because it is written by people who write for a living :)

I am not dismissing the hard work of volunteers of course. As I wrote  
before I am one of the volunteers in the projects to which I  
participate. But there is no doubt whatsoever that what I do for  
money (as a freelance translator) will _have_ to be of a much higher  
quality than _anything_ I do on a volunteer basis, because I need to  
feed the kids and because I can always fall back on the fact that  
there are other volunteers who can fix my mistakes.

Jean-Christophe Helary

Re: Why emacs have not native language menu

[Eli Zaretskii]

> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
> Date: Fri, 27 Jul 2007 22:32:50 +0900
> 
> There is no information about spell-buffer in the manual

That's because you aren't supposed to use it, in general.

Look, I told you how to find in the manual the description of commands
for spell-checking that will most probably work for you.  I see no
reason to continue this discussion if you insist on ignoring what I
say and instead continue arguing about spell-buffer.

> the distribution should _really_ map spell-buffer to ispell-buffer.

I think you read too much into a name of a command.

Re: Why emacs have not native language menu

[Eli Zaretskii]

> From: Jean-Christophe Helary <fusion@mx6.tiki.ne.jp>
> Date: Fri, 27 Jul 2007 22:32:50 +0900
> 
> I don't like the style and I don't like the way the sentence look
> when displayed either as HTML or PDF or anything I try to read them
> with.

Can't argue with style preferences.  FWIW, I do like it.

> Specifically there is too much text for too little code and too
> little exercises.

Unless there's a way of saying the same with fewer words, the above
boils down to add examples and exercises, which I think is a good
idea.  If you have suggestions for more exercises, I'm sure the
maintainers will be glad to hear them.

Re: Why emacs have not native language menu

[Eli Zaretskii]

> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
> Date: Thu, 26 Jul 2007 20:57:11 +0300
> 
> What I mean is that for an English-speaking reader, the
> explanation of `defun' can be ``define function'', and the
> English-speaking user will appreciate the `de'-fine `fun'-ction mnemonic
> rule, and will even enjoy the wordplay: `define' <=> `defun'.
> 
> That's impossible for a Greek user who reads a Greek translation of the
> manual.

Yes, the fun of the pun is lost to some degree.  There's nothing we
can do about it, however, because pun cannot be translated in most
cases, just explained.

Re: Why emacs have not native language menu

[David Kastrup]

William Case <billlinux@rogers.com> writes:

> On Wed, 2007-07-25 at 15:55 +0900, Jean-Christophe Helary wrote:
>> 
>> ps: did it ever occur to you that some massively succesful
>> programming languages originated from non-English
>> cultural/linguistic environments ?
>> 
>
> I have always thought that programming has long ago run out of
> contorted Engilsh words and Latin/English script symbols while there
> are hundreds of different languages and symbols available and used
> around the world.  Programming need not be just English based.  Make
> use of everything that is available at the actual programming level
> not just as a translation.

APL is also dead.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Why emacs have not native language menu

[David Kastrup]

Jean-Christophe Helary <fusion@mx6.tiki.ne.jp> writes:

> On 26 juil. 07, at 22:36, Hadron wrote:
>
>> Jesus, half the Emacs manual is hard enough to understand in
>> English! :)
>
> This is basically why translating is difficult: the original
> documentation is poorly written.

Among all the manuals I know, the Emacs manual ranks among the best.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Why emacs have not native language menu

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Newsgroups: gnu.emacs.help
>> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
>> Date: Thu, 26 Jul 2007 00:56:14 +0300
>> 
>> If you describe in an ISO 8859-7 Greek manual that
>> the following are equivalent:
>> 
>>     M-x find-file RET διαδρομή RET
>>     μενού: Αρχείο | Άνοιγμα ...
>> 
>> which are the localized versions, then it's not as easy to
>> remember that the `random' name `find-file' maps easily to the
>> Greek text for "Open..." :-(
>
> If those hypothetical Greek users understand and remember find-file
> _today_, when it is described in a purely English manual, they won't
> have a harder time when the explanations are in Greek.

But we are talking about extending the user base here.  We are talking
about those hypothetical Greek users whom English gives a headache.
Not those who have already learnt to survive.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Why emacs have not native language menu

[ryofurue]

On Jul 27, 10:31 am, David Kastrup <d...@gnu.org> wrote:

> > This is basically why translating is difficult: the original
> > documentation is poorly written.
>
> Among all the manuals I know, the Emacs manual ranks among the best.

That's my experience, too.  I sincerely wish other applications were
documented as well as emacs.

Ryo

Re: Why emacs have not native language menu

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 27 Jul 2007 22:35:09 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If those hypothetical Greek users understand and remember find-file
> > _today_, when it is described in a purely English manual, they won't
> > have a harder time when the explanations are in Greek.
> 
> But we are talking about extending the user base here.  We are talking
> about those hypothetical Greek users whom English gives a headache.

Those will have less headache with a translated manual.