Re: manual translation

[David Bateman]

Paul Kienzle wrote:

> On Jul 4, 2005, at 5:17 AM, David Bateman wrote:
>
> > Jorge Barros de Abreu wrote:
> >
> > > How I make this patch????
> > > I am not a professional programmer but if one say to me I make it.
> > I would be a large programming effort as the internationalization of 
> > octave is a non trivial task... Otherwise, you can of course go the 
> > route of translating the existing manual with the understanding that 
> > it would be for a particular version of octave... If you choose that 
> > route I'd suggest waiting till octave 3.0 is released as the manual 
> > is likely to undergo a large number of changes prior to the 3.0 
> > release which should happen in the next few months..
>
>
> I agree with David.  The current manual is so out of date that 
> translation at this point would be a wasted effort, and a complete 
> solution to internationalization would be a large programming effort.
>
> However, the documentation for the individual functions is up to date 
> and any translation effort would require the translation of the 
> individual functions so you could start with those. With a little 
> programming effort someone could extend the help function to search 
> for the translated text and display that if it is available, otherwise 
> default to the usual help text.  That would make your translation 
> efforts immediately useful.
>
> Each translation should start with the md5 hash of the doc string 
> being translated as the first line of the file so that the help system 
> can warn the user that the translation is out of date and show the new 
> English text in addition to the translated text.  Use the text in 
> octave/src/DOCSTRINGS and octave/scripts/DOCSTRINGS to calculate the 
> md5 hash for the individual functions. The md5 hash can also be used 
> to generate a list of functions which are out of date or not yet 
> translated for a particular language.
>
> There are some details to work out about where to store the 
> translations.  For now I would put them ./lang/pt/fn.pt where fn is 
> defined in the directory .
>
> - Paul
Here is a patch for a simple solution I worked on and suggested two 
years ago that didn't get applied. The idea was that all of the 
helpstrings were stored together with a special flag to seperate them, 
and the one to use selected by the octave_language variable, if no 
translation was available default to english... This would have worked 
except that the size of the oct-files would get significantly larger as 
more translations were added. It also didn't address the warning/error 
messages etc...

The patch I believe is against 2.1.50... Note this was just a proof of 
concept, and had a few missing features. See

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

for the original message.

Regards
David

--
David Bateman                                address@hidden
Motorola Labs - Paris                        +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

patch.foriegn.gz
Description: GNU Zip compressed data