[Etoys] Proposal on how to use Pootle for etoys
xavi.alvarez at gmail.com
Sat Dec 1 08:32:58 EST 2007
On Friday 30 November 2007 22:07, korakurider at yahoo.co.jp wrote:
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 :)
ko> Xavier Alvarez <xavi.alvarez at gmail.com> wrote:
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> > 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> > 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
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
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
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
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> 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'
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
Don't Panic! The Answer is 42
More information about the etoys-dev