Forum OpenACS Development: Making the translation server database available

We want everybody to do as much translation work as possible on the public translation server, because this avoids duplicate work and provides a technical and procedural focus for resolving wording conflicts. However, getting the translations from the server to CVS is mildly complicated and not currently automated. So people to do translations have to wait months for the next OpenACS release.

We could give package developers access to the translation server so that they can export translations themselves, but this introduces many risks.

So it occurred to me that we could simply publish the nightly database backup on the web. Package developers then have access to all the translations and can export only the ones they want, verify, and commit to CVS. Problems:

  • Privacy issues - there are 200+ user accounts, and we would have to strip them all in the export, but still leave some way to log in.
  • Efficiency. This means that many developers will have to learn how to work with translations, instead of just Collaboraid. This is the documentation. (on the upside, this means that we're not the bottleneck, and it means that other people may see obvious process simplifications or bugs)
Collapse
Posted by xx xx on
That would be great! It does make translating or revising more rewarding and I also hope it will encourage translators.

The commit to CVS sounds great too, but tricky. Do we need language maintainers? Does one need to do an import on the translation server after a commit? Is import less risky than export?

Collapse
Posted by Matthias Melcher on
I think import is more risky, even if it is only en_US because of the "ripple effect" Carl mentions in https://openacs.org/forums/message-view?message_id=163456 (see his proposal B and my answer).
For import of other languages, Aldert's idea of language maintainers sounds good to me.