On Oct 11, 2016 10:23, "Shaun McCance" <shaunm(a)gnome.org> 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.
Could we solve this by periodically pulling POs into the release branches
of our docs? I'm picturing a nightly script that checks out ie the f25
branch, pulls a language, does some tests, commits if the tests pass, and
moves to the next language. I read the suggestion as using a separate git
repo, which seems unnecessarily complex.
* 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.
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%.
Can you elaborate on what itstool does not do? Entities? I like the idea
of using an established tool vs partial fork, perhaps a little additional
processing will get us there.
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.
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.
Thoughts?
--
Shaun
OK, you did get to the separate repo question. Time spent fetching remote
refs seems to be the only downside to continuing our POs-in-release-branch
SOP. I don't see enough need for speed in the process to warrant the
increased procedural and architectural complexity. IMO publishing the
source lang and translated langs asynchronously would be fine.
That said, I have not personally done a multi-language build with pintail,
there may well be something I'm missing.
-- Pete