[Etoys] Proposal on how to use Pootle for etoys

[Xavier Alvarez]

On Friday 30 November 2007 22:07, korakurider at yahoo.co.jp wrote:
ko> Xavier,
ko> First of all, I will sent the actual my proposal later to
ko> share with you. I think we will want to adjust setting for
ko> the TEST(etoys) project on Pootle to validate if it works
ko> for us actually and need your help, please.

Most happy to help :)


...snip...
ko> Xavier Alvarez <xavi.alvarez at gmail.com> wrote:
ko>
ko> > On Friday 30 November 2007 16:09, Bert Freudenberg wrote:
ko> > ...snip...
ko> > BF> Does pootle really force some directory structure onto
ko> > BF> projects?
ko> >
ko> > By default Pootle uses the following layout (xx_YY being
ko> > the language code):
ko> >  .../project/
ko> >  .../project/xx_YY/xyzzy.po
ko> >  .../project/templates/xyzzy.pot
ko> >
ko> > But it can also handle GNU's all-in-one structure:
ko> >  .../project/po/
ko> >  .../project/po/xyzzy.pot
ko> >  .../project/po/xx_YY.po
ko>  When I tested, I experienced such error on uploading that
ko> file name doesn't confrm to GNU style.  So I had to change
ko> etoys_test.po to ja_ZZ. po.  Was this because of Pootle's
ko> settings?  can the rule be relaxed even in GNU style
ko> setting?

As far as I've understood L10n stuff, GNU's style can only support 
a single POT and a set of language-coded PO files. Meaning that 
all the PO files are implicitely associated with the directory's 
POT file.

On the other hand, Pootle's structure allows you to have several 
POT files and a directory for each language holding the 
corresponding PO files. The association of POT2PO is maintained 
by the file name.  In Pootle, you can upload ad-hoc named files, 
but then they'll be totally disassociated from whatever POT file 
it was originally derived from.

In the end, the rule seems to be there in order to guarantee that 
Pootle can do it's job in keeping the PO files in-sync with its 
corresponding POT.

So my answer-question would be: why did you want to upload an 
etoys_test.po file in the first place? :)


BTW, another catch when uploading stuff is that the name of the 
file to be uploaded can't be modified, meaning that you can't 
upload foo.po as bar.po, forcing you to have the same local 
names. Also, you can't delete these files without access to the 
filesystem, so uploading 'stuff' is something to be considered 
carefully.


ko>
ko>  In the former style we can split huge etoys.po into smaller
ko> pieces or can register additional POs for addons without big
ko> change when we want. 
ko>  (I assume Bert want to split it... ) In the later style we
ko> can't. 
ko>  With the restriction I would choose the former even if we
ko> don't need to right now.

If we are going to include Etoys in Pootle using version control, 
we are not forced to replicate the version control directory 
hierarchy (as we would be symlinking the POT & PO files). This 
would allow us to have an Etoys project with multiple POT files, 
just like the 'assembled projects' xo_core & xo_bundled, or we 
could include the 'core' into xo_core, and put the other Etoys' 
files in either xo_bundled, (the future) xo_extras or an Etoys' 
specific project...

TamTam is a good example of the flexibility achieved, although a 
lousy one at standardization -- and a bit of a headache for our 
evolving scripts: there's one git with four sub-dirs and each 
sub-dir is an activity with its own /po directory & files. But 
within xo_core, they are presented as four distinct files that 
symlink to the real thing on an equal basis with other (more 
standard) activities.

ko>
ko> Cheers,
ko> /Korakurider


Cheers,
Xavier

-- 
XA
=========
Don't Panic!  The Answer is 42