> I don’t thinks this solves the underlying problem. I think the
> problem here stems from having individual independent documentation
> files, which induces a massive workload to contributors and
> translators for keeping up with changes and sync them to
> translations.
Mhmm. I don't think that the number of files is really a problem.
> It would rather be thinkable have the english documentation as a
> master document and use automated tooling to create the
> localizations from diffs — recognizing outdated blocks on the fly
> and potentially falling back to the original English text, as is
> done in pretty much any concept of software localization out there.
This sounds useful.
> And this would be fairly easy: [...]
The most complicated part is to provide the necessary infrastructure.
> So now a script would take the node “Text” in the original, find the
> translation node “Text”, would check if the hash matches, and if so
> replace the original node by the translation node.
However, changing a single character changes the ID. Is it really
justified to reject a translation in such a case?
Werner