On Tue, Oct 11, 2016, at 05:23 PM, Shaun McCance wrote:
Hi all,
I've been working on getting translations from Zanata and merging them
into DocBook. There are two big issues, and I'd like to propose an
alternative for legacy documents. Here are the issues:
* Pulling from Zanata is slow. It's basically just a bunch of HTTP
calls, at least one per language per XML file. I don't see any way to
use etags or similar to avoid redownloading the same content. I had a
brief chat with bex on IRC about possibly having a git mirror of the PO
files. That would be faster.
I suggest we talk to the translation team about having a git repo that
is just PO files. We would put a webhook on it to trigger rebuilds of
translations. This way they can signal that an update is ready by just
pushing files to that git repo.
I also think we need to talk to the Zanata team about their future plans
for git support and if there is anything they can do to make downloads
faster.
* Merging requires Publican, because the merge code lives there.
There
are two possible ways around this:
1) We pull Publican's Translate.pm into a standalone module and have a
tool ("publican-po"?) that just does PO extraction and merging exactly
the way Publican does. We'd have to maintain this, but it would be a
lower maintenance burden than all of Publican.
I believe that relying on publican is not a good plan. I do not believe
it is worth trying to use it for something that other tools can do
better.
2) We merge with itstool instead. itstool's PO files don't
exactly
match Publican's. So a 100% translated document might drop to 90% or
so. I could probably write custom ITS rules that would make it match
better. I don't know if I could get it to match 100%.
3) We can use po4a instead as well. I really believe we need to get
away from XML formatted documentation, even for translations.
So, an alternative: For any documents that are no longer edited in
any
way, we could do a one time merge of all translations and just put it
in git on that branch. That way there's no downloading (aside from the
git clone we do anyway), no merging, and no maintaining a legacy merge
tool going forward.
I believe we should do something like this. Anything that is legacy we
should commit final copies to in a repo, including their HTML forms and
just publish that and forget.
The downside is that we'd be putting a lot more content in git,
which
could slow down git clones. Alternatively, we could put them all in a
separate repo. For example, all release-notes translations could go
into a new repo called release-notes-translations.
I believe we should have the translation team overwrite history in the
translation PO caching git repo, if it is required. That history should
be duplicating what Zanata is already tracking. When we build a
translation in the build bot we should always do a new clone, therefore
we won't care about overwritten history.
regards,
bex