Bert Freudenberg wrote:
On Nov 30, 2007, at 12:33 , korakurider wrote:
Hi all.
As we have some enthusiastic community folks to contribute translations to Pootle where we call as test many times :-), I want to make it to production real soon. So I wrote down a proposal attached.
As this contains too many "up to etoys team", I would like to hear from you before sending to list for wider audience...
Thanks in advance.
I would take out tinlizzie - both our master git and svn repositories are at laptop.org. tinlizzie is only for internal use and backup.
We can make pootle check into git directly, creating whatever directory it wants. The "real" po would be created in svn, as we currently do. E.g.:
git: etoys/pootle/ja.po svn: etoys/Content/lang/ja.po
Looks good.
In other project of OLPC, community can directly commit to git from Pootle. Why should we split repository? Because version and quality management will be easier; community can work easily.
I wonder if "quality management" actually works because we don't understand all language. But it is worth to try.
Pootle's file name / hierarchy is different from what we choose for etoys svn For instance: Pootle: Japanese/ Update1-core / chat-activity.po. etoys svn: po/etoys/ja.po lang/ja/.../etoys.mo So we need to fill the gap.
I think the simplest way is to use Pootle's file structure. But I would write a shell script to adapt file names at first. I doubt if we will change the translation scheme in near future again ;) I'll test whole thing after my current task, maybe this weekend.
Cheers, - Takashi
On Nov 30, 2007, at 19:38 , Takashi Yamamiya wrote:
Bert Freudenberg wrote:
On Nov 30, 2007, at 12:33 , korakurider wrote:
Hi all.
As we have some enthusiastic community folks to contribute translations to Pootle where we call as test many times :-), I want to make it to production real soon. So I wrote down a proposal attached.
As this contains too many "up to etoys team", I would like to hear from you before sending to list for wider audience...
Thanks in advance.
I would take out tinlizzie - both our master git and svn repositories are at laptop.org. tinlizzie is only for internal use and backup. We can make pootle check into git directly, creating whatever directory it wants. The "real" po would be created in svn, as we currently do. E.g.: git: etoys/pootle/ja.po svn: etoys/Content/lang/ja.po
Looks good.
In other project of OLPC, community can directly commit to git from Pootle. Why should we split repository? Because version and quality management will be easier; community can work easily.
I wonder if "quality management" actually works because we don't understand all language. But it is worth to try.
Pootle's file name / hierarchy is different from what we choose for etoys svn For instance: Pootle: Japanese/ Update1-core / chat-activity.po. etoys svn: po/etoys/ja.po lang/ja/.../etoys.mo So we need to fill the gap.
I think the simplest way is to use Pootle's file structure. But I would write a shell script to adapt file names at first. I doubt if we will change the translation scheme in near future again ;) I'll test whole thing after my current task, maybe this weekend.
Does pootle really force some directory structure onto projects?
- Bert -
On Friday 30 November 2007 16:09, Bert Freudenberg wrote: ...snip... BF> >>> Pootle's file name / hierarchy is different from what we BF> >>> choose for etoys svn BF> >>> For instance: BF> >>> Pootle: Japanese/ Update1-core / chat-activity.po. BF> >>> etoys svn: po/etoys/ja.po BF> >>> lang/ja/.../etoys.mo BF> >>> So we need to fill the gap. BF> > BF> > I think the simplest way is to use Pootle's file structure. BF> > But I would write a shell script to adapt file names at BF> > first. I doubt if we will change the translation scheme in BF> > near future again ;) I'll test whole thing after my current BF> > task, maybe this weekend. BF> BF> Does pootle really force some directory structure onto BF> projects?
By default Pootle uses the following layout (xx_YY being the language code): .../project/ .../project/xx_YY/xyzzy.po .../project/templates/xyzzy.pot
But it can also handle GNU's all-in-one structure: .../project/po/ .../project/po/xyzzy.pot .../project/po/xx_YY.po
Currently all 'assembled projects' (xo_core, xo_bundled & update1_core) use Pootle's default and Etoys test project uses GNU's layout. And so far, so good :)
Another thing to note is that for 'version controlled' .po & .pot files we have symlinks going from Pootle's hierarchy into the version control directory. Not only is the sane way (according to the Pootle people) but it is also what allows us to have those 'assembled projects', all of which have a GNU layout in their git repository.
BF> BF> - Bert - BF>
Cheers, Xavier
Xavier, First of all, I will sent the actual my proposal later to share with you. I think we will want to adjust setting for the TEST(etoys) project on Pootle to validate if it works for us actually and need your help, please.
Bert Freudenberg wrote:
I would take out tinlizzie - both our master git and svn repositories are at laptop.org. tinlizzie is only for internal use and backup.
This was just my misunderstanding and I will revise it.
Takashi Yamamiya tak@metatoys.org wrote:
Why should we split repository? Because version and quality management will be easier; community
can work easily.
I wonder if "quality management" actually works because we don't
understand
all language. But it is worth to try.
Yep. At least release we as developers can verify PO by comparing, compiling, that is what I meant as QA. I suspect many people of translation community have even gettext tools.
Xavier Alvarez xavi.alvarez@gmail.com wrote:
On Friday 30 November 2007 16:09, Bert Freudenberg wrote: ...snip... BF> Does pootle really force some directory structure onto BF> projects?
By default Pootle uses the following layout (xx_YY being the language code): .../project/ .../project/xx_YY/xyzzy.po .../project/templates/xyzzy.pot
But it can also handle GNU's all-in-one structure: .../project/po/ .../project/po/xyzzy.pot .../project/po/xx_YY.po
When I tested, I experienced such error on uploading that file name doesn't confrm to GNU style. So I had to change etoys_test.po to ja_ZZ. po. Was this because of Pootle's settings? can the rule be relaxed even in GNU style setting?
In the former style we can split huge etoys.po into smaller pieces or can register additional POs for addons without big change when we want. (I assume Bert want to split it... ) In the later style we can't. With the restriction I would choose the former even if we don't need to right now.
Cheers, /Korakurider -------------------------------------- New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/
On Dec 1, 2007, at 2:07 , korakurider@yahoo.co.jp wrote:
In the former style we can split huge etoys.po into smaller pieces or can register additional POs for addons without big change when we want. (I assume Bert want to split it... ) In the later style we can't. With the restriction I would choose the former even if we don't need to right now.
We don't need to split I think (unless translators want us to), but we will have additional pots (for projects, quickguides, add-on apps like BotsInc, DrGeo2 etc).
- Bert -
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
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
korakuriderļ¼ yahoo.co.jp -
Takashi Yamamiya -
Xavier Alvarez