On Oct 11, 2016 10:23, "Shaun McCance" <shaunm@xxxxxxxxx> 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
_______________________________________________ docs mailing list -- docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to docs-leave@xxxxxxxxxxxxxxxxxxxxxxx
