I'd like to be a contributor!

David Bateman dbateman at dbateman.org
Tue Apr 7 18:00:14 CDT 2009


John W. Eaton wrote:
> | However, that doesn't address the manual itself. Ideally we should 
> | translate first all of the help strings of the functions in the manner 
> | above and then the *.txi files in Octave and so allow the creation of 
> | the translated manual with the same mechanism as the English manual 
> | itself...
>
> What would be the best way to handle updates to larger blocks of text?
> I guess we need to be able to generate diffs of the master (English)
> version of the manual from the point at which a given translation
> (say, pt_BR) was done and the current version, so you don't have to
> spend a lot of time comparing text by hand.  Does the Octave Forge
> framework make this easy?  Sorry, I haven't looked at Octave Forge to
> see what is actually done there for the docstrings.
>   
The octave-forge method is that someone regularly updates the SVN with 
the DOCSTRINGS of each function stored separately. The header of the 
translated string has the SVN revision number and the MD5SUM of the 
string used for the translation. The help function can then identify if 
the translation is out of date and signal the user and the developer can 
then re-update the DOCSTRINGS and then a simple diff between the 
revision used for the translation and the updated DOCSTRING identifies 
where the changes are needed..

I suppose this process could use the original files themselves, but the 
downside of that for the translator is that the diff will should not 
just the changes to the relevant DOCSTRING, but rather all changes to 
the file. Can we  live with that, or rather can the translator live with 
that?

D.






> jwe
>
>   


-- 
David Bateman                                dbateman at dbateman.org
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)



More information about the Octave-maintainers mailing list