|
From: | David Bateman |
Subject: | Re: I'd like to be a contributor! |
Date: | Wed, 08 Apr 2009 01:00:14 +0200 |
User-agent: | Mozilla-Thunderbird 2.0.0.17 (X11/20081018) |
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...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..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.
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 address@hidden 35 rue Gambetta +33 1 46 04 02 18 (Home) 92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob)
[Prev in Thread] | Current Thread | [Next in Thread] |