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
_______________________________________________
docs mailing list -- docs@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to docs-leave@xxxxxxxxxxxxxxxxxxxxxxx
