octave-maintainers
[Top][All Lists]
Advanced

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

Re: i18n


From: David Bateman
Subject: Re: i18n
Date: Wed, 16 Jun 2004 13:38:24 +0200
User-agent: Mutt/1.4.1i

The version I supplied was a proof of concept that required minimal
changes to octave itself. Storing the docs seperately would require
larger changes, but would address the issue in the previous code,
with the in-built functions and variables. In this case I believe it
would be better to completely remove the help strings for all code and
create a seperate hierarchy for the documentation. This includes the
english documentation, currently embedded in the functions. This implies
a maintenance issue of the default documentation.

Also we would need to replace all of the warning and error messages
with an enum that is used to look up the correct message in a
language. There are also hardcoded messages in macros such as
OCTAVE_COPYING_STATEMENT that would need to undergo a similar
treatment. Also what about the texinfo manual, that takes the
documentation currently in the files themselves.

I think there are too many things to change in too many places to
make this effort worthwhile. But hey, I'm an english native speaker :-)

Cheers
David


According to Paul Kienzle <address@hidden> (on 06/16/04):
> 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
> >

-- 
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]