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: correct.
<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 mailing list