octave-maintainers
[Top][All Lists]
Advanced

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

Re: i18n


From: Paul Kienzle
Subject: Re: i18n
Date: Wed, 16 Jun 2004 07:24:03 -0400

There are two reasons I prefer to have each language in its
own directory tree.   For the user, if the number of supported
languages is large, we don't need to install all of them.  For
the developer, we don't need to coordinate with anybody to
support a new language.  The usual advantage of keeping
docs and tests with code (that the developer can more
easily keep them all in sync) doesn't apply to i18n since it
is not the developer who is doing the translation.

BTW, an MD5 check sum or other secure hash can be
stored with each translation, so it is easy to identify which
docstrings have changed.  Identifying how they changed
is going to require actual version comparisons, with the
choice of comparison version based on the date.

Paul Kienzle
address@hidden

On Jun 16, 2004, at 4:09 AM, David Bateman wrote:

Check the message

http://www.octave.org/mailing-lists/octave-maintainers/2003/195

where I started trying to address this issue...

D.

Daprès Paul Kienzle <address@hidden> (le 16/06/2004):
On Jun 15, 2004, at 2:27 PM, Tomasv wrote:

- Translate software and documentation to spanish and portugues

There is no work done on i18n for octave.

Many tutorials exist already on the net.  Finding a good set and
linking to them from http://wiki.octave.org would be useful.

If you wanted to maintain a portuguese or spanish version of the
documentation, you could store it in octave-forge.   Or you could
store it at http://wiki.octave.org so that users can add to it when
they need to.

For the function descriptions, it is easy to replace help() so that it
first looks for language specific help in a separate set of directories,
or looks for help in the usual way if no translation exists.

Making error messages to appear in your own language is harder.
All messages go through error() and warning().  You can add
a hash table loaded at runtime (Map lang<string,string>) depending
on the environment variable LANG.  error and warning can look up
each message and use a language specific replacement if it exists.

You will need tools to find all the message strings in C++.
Maybe you could look for the first argument after error and warning.
That won't work if they are variables, so you might need a macro to
mark them.  E.g.,

        #define _(A) A
         ...
        char *msg = _("text");

Then we can look for _("msg"), error("msg") and warning("msg"),
returning anything which is a string.

We can provide a _() command for use in m-files too. This would return
the
translated string for things like plot labels and output strings which
are not
warnings or errors.  Warnings and error messages will use the lookup
table
in the warning() and error() functions.

Translation strings need to be associated with the toolbox rather than
stored in a central database.  I suggest a local file (e.g., i18n.xx)
which
stores the table for each directory.  When that directory is added to
the
search path octave can add the strings in i18n.xx for the particular
LANG=xx to its master table.  I'm ignoring the problem of removing a
directory from a path.

We need tools listing which strings have changed since they were last
translated.

Paul Kienzle
address@hidden

--
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary




reply via email to

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