[Mma] Re: documentation: are the .txi files the ones to edit?

John W. Eaton jwe at bevo.che.wisc.edu
Tue May 27 21:32:13 CEST 2003


On 27-May-2003, David Bateman <David.Bateman at motorola.com> wrote:

| Daprès Boud Roukema <boud at astro.uni.torun.pl> (le 27/05/2003):
| > hi again,
| > 
| > To start off with, I think having a mix of some bits in Polish and
| > some bits in English will already be a great help to Polish users,
| > and encourage them to do the translations of the untranslated bits
| > if they want to contribute.
| 
| The point is to translate those untranslated bits means you need to
| edit the octave source code to convert the help into Polish... Somehow
| I thing this will be a difficult patch to get into the CVS :-)

For error, warning, and other messages, I think we could use something
like gettext.  The messages in the sources would remain in English and
there would be files with translations for other languages.

For doc strings, we could do something similar.

| Sort of... The fact is that teh .txi is an internal octave format. The real
| texinfo files are the .texi files built by munging the .txi and the help
| messages together. So what I suggested is that you take a COPY of the .texi
| files from a particular release, that will include all of the help message
| and translate these, as you say ignoring the "DO NOT EDIT" message. These
| Polish files would then have a life of their own independent from the octave
| help files. So it would be upto you to keep it upto date with changes in
| octave.

I think it would better to translate the .txi files separately from
the doc strings, and have them merged together to create a complete
translation, same as is currently done for the English version.  Then
with a little bit of support in the Octave sources, you could get
translated doc strings from the help command as well as a translated
manual.

| > (2b) do some general programming work on the whole structure of
| > documentation extraction, preferably in an i18n context allowing for
| > unicode, and then add translated (unicoded) documentation either inside of
| > the program/function source files with the DEFUN directive, or as
| > external files
| 
| Also ugly, as the help message is currently sorted as data block of the
| function. So multiple translations of help message will blow out the size
| of this data block.
| 
| Better to rewrite the help system so that the help is sort else where. This
| might mean that it is still in the source code, but only seperated at compile
| time though.

I would want the English help text to remain in the source files.
Translations would go in separate files.

| > (2c) translate src/DOCSTRINGS to, e.g.,  src/DOCSTRINGS-pl and
| > accept that this is only a hacked solution requiring an extra script
| > in order that it can be updated with English updates to at least
| > remain up-to-date in at least one language.
| 
| DOCSTRINGS files are derived from the source code. So any new functions
| added, will mean you'll need to update this file as well.

I see this as the main problem with any effort to translate the manual
or doc strings.  It will probably require significant effort to keep
up to date.

jwe



More information about the Mma mailing list