Migrating Docs to new Transifex server
Paul W. Frields
stickster at gmail.com
Tue Feb 22 18:51:09 UTC 2011
On Tue, Feb 22, 2011 at 10:19:12AM -0500, Ricky Zhou wrote:
> On 2011-02-22 09:46:06 AM, Eric "Sparks" Christensen wrote:
> > That's going to be a problem... It was seamless before. Things just
> > happened without a lot of user interaction which is good because people
> > just don't have time for a lot of extra steps. I know John scripted
> > many steps to keep his sanity dealing with the Release Notes. Is there
> > a way to script this on the backend?
> If you want seamless transifex pushing/pulling, we can look at
> integrating the transifex steps into the docs build process, or if
> desired, a git hook.
Ricky et al.,
Dimitris and I were talking about language mappings earlier, which I
think will need to figure into the tooling to achieve something like
The point being that, AFAICT, Docs is going to need some help with the
tooling so they can continue doing their actual documentation work for
* * *
<stickster> glezos: How are languages mapped between Publican <--> Tx?
<glezos> stickster: Tx has a large list of canonical languages:
stickster: languages are mapped to *local files* using the client
<stickster> glezos: So in the case of a Publican doc, let's take for
example a translation into Greek -- the translations are stored in a
"el-GR" directory as multiple PO files.
glezos: Do we need to add some sort of config information in
.tx/config since that's not el_GR but rather el-GR?
<glezos> stickster: Tx does its best when you push a file to it, to
map it to a canonical language name (in this case, el_GR). But when
you PULL the file, it can't know where you want to put it, really.
<stickster> glezos: So it would pull that content into something like
or maybe 'el_GR/'
<glezos> stickster: You'll need to add this support to
transifex-client.. ie. in .tx/config have some kind of mapping between
canonical language names (el_GR) and your custom ones (el_-_**_-_GR or
<stickster> glezos: So let me make sure I understand correctly
We have a couple options:
1. Don't bother storing the PO locally at all, and grab it on demand
from Tx when we need to build or publish
"locally" == "in the git repo" (sorry)
<glezos> stickster: correct.
<stickster> 2. If we have to store the PO in the git repo for some
reason, we have to get someone who can add code to the
transifex-client package to make the mapping possible
In the case of 1, someone's got to write a set of e.g. Makefile rules
to wrap around publican commands for building and publishing.
In the case of 2, someone's got to write some Python code in
transifex-client to do language mapping.
<glezos> stickster: 3. Instead of pushing this customization upstream
to transifex-client like you mentioned, you can also just create your
own scripts to mass-move codes (el_GR → el-GR) to make publican happy.
<stickster> Yes, good point
<glezos> stickster: I think that also in the case of 1, Publican won't
be happy with underscores.
* * *
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
Where open source multiplies: http://opensource.com
More information about the docs