[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-docs-list
Subject: Re: Legacy document translations
From: Pete Travis <me () petetravis ! com>
Date: 2016-10-11 15:42:41
Message-ID: CAPDshLsWN+EuKcFwX8-JpM+FCh6StabcJo8=ALOzjwjXuL4Fkw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Oct 11, 2016 10:23, "Shaun McCance" <shaunm@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
[Attachment #5 (text/html)]
<p dir="ltr"></p>
<p dir="ltr">On Oct 11, 2016 10:23, "Shaun McCance" <<a \
href="mailto:shaunm@gnome.org">shaunm@gnome.org</a>> wrote:<br> ><br>
> Hi all,<br>
><br>
> I've been working on getting translations from Zanata and merging them<br>
> into DocBook. There are two big issues, and I'd like to propose an<br>
> alternative for legacy documents. Here are the issues:<br>
><br>
> * Pulling from Zanata is slow. It's basically just a bunch of HTTP<br>
> calls, at least one per language per XML file. I don't see any way to<br>
> use etags or similar to avoid redownloading the same content. I had a<br>
> brief chat with bex on IRC about possibly having a git mirror of the PO<br>
> files. That would be faster.<br>
></p>
<p dir="ltr">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.</p> <p dir="ltr">> * Merging requires Publican, because the \
merge code lives there. There<br> > are two possible ways around this:<br>
><br>
> 1) We pull Publican's Translate.pm into a standalone module and have a<br>
> tool ("publican-po"?) that just does PO extraction and merging \
exactly<br> > the way Publican does. We'd have to maintain this, but it would \
be a<br> > lower maintenance burden than all of Publican.<br>
><br>
> 2) We merge with itstool instead. itstool's PO files don't exactly<br>
> match Publican's. So a 100% translated document might drop to 90% or<br>
> so. I could probably write custom ITS rules that would make it match<br>
> better. I don't know if I could get it to match 100%.<br>
><br>
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.</p> <p dir="ltr">> So, an alternative: For any documents that are no \
longer edited in any<br> > way, we could do a one time merge of all translations \
and just put it<br> > in git on that branch. That way there's no downloading \
(aside from the<br> > git clone we do anyway), no merging, and no maintaining a \
legacy merge<br> > tool going forward.<br>
><br>
> The downside is that we'd be putting a lot more content in git, which<br>
> could slow down git clones. Alternatively, we could put them all in a<br>
> separate repo. For example, all release-notes translations could go<br>
> into a new repo called release-notes-translations.<br>
><br>
> Thoughts?<br>
><br>
> --<br>
> Shaun<br>
></p>
<p dir="ltr">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.</p> <p dir="ltr">That said, I have \
not personally done a multi-language build with pintail, there may well be something \
I'm missing.</p> <p dir="ltr">-- Pete</p>
[Attachment #6 (text/plain)]
_______________________________________________
docs mailing list -- docs@lists.fedoraproject.org
To unsubscribe send an email to docs-leave@lists.fedoraproject.org
[prev in list] [next in list] [prev in thread] [next in thread]