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