|
From: | Jean-Christophe Helary |
Subject: | Re: Emacs localization (Re: Why emacs have not native language menu) |
Date: | Tue, 24 Jul 2007 23:50:25 +0900 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |