[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Summary (Re: A system for localizing documentation strings)

From: Jean-Christophe Helary
Subject: Summary (Re: A system for localizing documentation strings)
Date: Fri, 27 Jul 2007 11:16:31 +0900

I will try here to make a short summary of the discussions.

I'll start with quoting myself (with a modification in the 3rd requirement):

What we need is provide:
1) a way for coders to identify the necessary strings for the translation
2) a way for translators to add translated strings "the emacs way"
3) a way for users to have the localized strings displayed

We have also identified another requirement:

4) a way for other coders to read the code without having unrelated documentation strings coming in the way

This 4th requirement is a very valid one, but the implementation proposals (keep English there) seem to not be practical in the end.

In fact, I see the 4th requirement as a subset of the 3rd. After all coders are "only" a subgroup of "users".

Since the code comes in elisp, to meet the 4th requirement it would "only" be necessary to provide elisp-mode with a specialized "code folding" like function for localized strings, enabled by default. This function would take into account the user preferences (main languages, preferred languages, default language)

This suppose that the strings are all inside the code, but a language preference handling function would work just as well for coders if the strings were in a separate file.

Regarding the string data, as it is bound to be lisp lists, having them inside or outside the code is not a problem and as long as we find an elegant way to deal with the 4th requirement it is not even relevant to the discussion.

Managing the code/strings -wherever they are- would be handled by the 2nd requirement: offer a translation function that properly handles the string lists.

It looks like emacs primitives would have to be handled differently, but as is indicated i the manuals, the primitives are unlikely to change very much and it is generally not advised to extend emacs through such primitives.

So we can consider strings from primitives an exception to the above requirements and handle them with processes that fit better the C code structure.

As far as emacs extensions are concerned, and as long as we keep a strictly elisp perspective, the above requirements should be enough to satisfy any need.

Jean-Christophe Helary

reply via email to

[Prev in Thread] Current Thread [Next in Thread]