Den 6/16/2020 9:52 PM, skrev Christophe JAILLET:
Hi,
What I consider the biggest drawback of our current doc translation
process is that you have to keep it updated all the time in order to
be able to follow the updates from the English version.
For a new comer, or someone who has just a few hours a week or month
for it, I think that it is quite hard.
Not that docs updates happen so often, but when it gets out of synch,
getting it back to a good shape looks hard to me.
You have to diff the English version so see what has changed. Then to
find the impact in the translated files, then update it, then propose
it via ML or BZ, then wait for someone to take it and apply it.
The few that have seen in the past years look rapidly discouraged and
stop updating the doc rapidly.
One special mention to Lucien for the GREAT work he does for the
French translation.
I've been looking for a tool that could do some xml --> po files
updates. The files to translate would then be only some small pieces
of text that could be handled by poedit or equivalent software.
The main advantages I see are:
- ease to spot changes
- same sentences in different files (or even branch) are translated
only once
- ease to merge work of different contributors
- some translation web sites have a translation process that ease
access to contributor, with the possibility for the translation
community to validate others translation (Some years ago, I've been
using https://translatewiki.net for that)
The drawbacks are the one of po files:
- the context is missing when translating
- this requires some additional scripting to generate and update
the po files, and to convert them back to XML for our XSL based toolchain
Using something like po files for the translation would also lead to
only partly localized files. Little by little, the not-updated part of
the doc would get replaced by the more up-to-date English version. I
don't think it is an issue. I prefer a mixed language document than
having something that I can not trust because I don't know what is
up-to-date or not.
itstool [1] is the most promising tool I found so far.
The main advantages it has is that it can easily be configured to tell
what must not be translated. It also have a kind of placeholder
mechanism. This fits perfectly well with our current XML based master
documents.
I'm close to have a working PoC but I wanted to have your feedback on
this approach to doc translation.
Attached is an example of all the mod/*/xml files processed and the
rules file I've written so far.
Do you think that such an approach is viable ?
Hi,
I'm just a lurker who once did some Norwegian translation, but I am from
time to time involved in translations in other projects.
The process you describe is consistent with what we do in other
projects, and is in my opinion the prefered method. The drawback of
missing context can to a large degree be ameliorated by build automation.
What I do in some projects I am responsible for is that I set a limit,
at least X % of the project must be translated in order for it to be
published. In my personal opinion, at about 95% a translation becomes
useful, anything less leaves the whole thing as a mess. It's better to
concede defeat and either publish outdated docs, clearly marked or
redirect to an actually completed translation in another language. Eg.
English as a default.
I'm a big believer in using Weblate as it enables the whole translation
to be somewhat democratized. Anyone can suggest a new translation if
enabled, and someone authorized can choose to accept or reject it. This
is separated from the actual repository access.
So in short, I think this is the way forward.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
For additional commands, e-mail: docs-h...@httpd.apache.org
