On Friday 30 November 2007 22:07, korakurider@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@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