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: Thu, 17 Jun 2004 00:54:40 -0400

On Jun 16, 2004, at 7:38 AM, David Bateman wrote:

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.

I see very little advantage to pulling out the English docs.  We need
to support embedded docstrings anyway for compatibility, so they may
as well contain the docs in the default language.   I guess there is a
slight advantage in reduced memory use, but that's a separate issue.

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.

I'm suggesting an ``enum'' which is a hash of the English text
string.  It would be implemented as a table lookup from:

        Map<English text, LANG text>

That will require minimal changes to Octave and will
give a result about as good as a central registry of all
error messages.  Speed isn't a concern for errors and
warnings.  Certain other strings displayed via printf
or disp in m-files will need a special lookup function
such as:

        printf(translate('Printing results from function %s\n'), name)

There are also hardcoded messages in macros such as
OCTAVE_COPYING_STATEMENT that would need to undergo a similar
treatment.

These would be handled automatically in my scheme, at least
if they go through error or warning.

Also what about the texinfo manual, that takes the
documentation currently in the files themselves.

The texinfo manual works as usual.  Translated documentation
would have to know to work from DOCSTRINGS collected from
the translation hierarchy, filled in with English docstrings for
functions which have not yet been translated.

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 :-)

I think the biggest effort will be in the translation.  The next biggest
effort will be keeping the translations up to date.  The rest is trivial
by comparison.

It will require a motivated foreign language speaker to scratch this
itch --- problem is that anyone with the skills to do it already knows
enough English not to need it, so they will have to appeal to their
nationalist instincts for motivation.

Do we make a alternative manual with all instances of color
replaced by colour for the non-American English speakers 8-)



reply via email to

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