Re: Summary (Re: A system for localizing documentation strings)

["Jan Djärv" <jan.h.d@swipnet.se>]

David Kastrup skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Translations does not belong in the code, that is why this
>> requirement is automatically satisfied if gettext is used.
>>
>> We need a way to identify elisp strings to be translated, maybe
>> gettext must be modified to do this.  We also need to find where in
>> Emacs gettext shall be called.  And that is it, but probably hard
>> work nonetheless.
> 
> It is not just that because not just strings are involved: Emacs is
> permeated with English.  All the function names are based on English,
> M-x is used transparently, menus are identified in the code by name,
> apropos of course works on English function names, customization
> groups are displayed by symbol, keyboard events are described by
> symbols and so on.
> 
> Emacs has no layers separating the user from the programmer.  It is,
> after all, the greatest prototyping platform for editing ever
> invented.  It is quite illusionary to separate "English" from
> "international" layers.  But that does not mean that _explanations_
> could not be done in English, or that menu entries and help texts
> could not be made in English.  Or even customization group names.  But
> what about "talking variable names" which are converted into
> capitalized space-separated sequences in the customize groups?
> Translate or not?  If yes, how does one get to know the actual
> variable name?
> 

I'd say no.  Once upon a time there was some swedish MS Excel version that had
all functions translated to swedih.  That didn't work so well when trying to
open a spreadsheet from the US...

If we wan't to be able to use an international .emacs everywhere, variables
must have just one name globally.  Even if some people find it sad, english
seems to be the best.

	Jan D.