[Etoys] Fwd: MO reader
tak at metatoys.org
Fri Sep 21 16:44:52 EDT 2007
Bert Freudenberg wrote:
> On Sep 21, 2007, at 10:51 , korakurider wrote:
>> The lookup decides
>> translation context (i.e. textdomain) by class category
>> of sender of #translated. (#translatedNoop is just for
>> extraction of original phrase, and isn't directly related
>> to lookup)
>> But when exporting receiver literal of #translatedNoop to
>> PO, that category is based on not #translated but
>> Then what if senders of #translated and #translatedNoop
>> are diffrent class with different class category?
> Ah, I see. How about having "#translatedNoopFor: 'classcategory'"
> which would be used by the exporter to place the translations in a
> different category?
I prefer too simple way at least for First Deployment (next month). My
thought is not doing any dynamic resolution like using thisContext. An
eToys application programmer should keep using #translated and
#translatedNoop in same class category, or designate a text domain
explicitly. Yes, this is poor idea. And especially it cause a problem
in certain place like the parts bin (#descriptionForPartsBin). But I
don't think is fatal issue in short term.
> > I agree it is needed to tweak SecurityPlugin. But
> > > SecurityPlugin doesn't differentiate access modes (read
> > > only or read/write), just allow/disallow file access. So
> > > It would need major work on plugin/VM of each architecture
> > > to support that exception.
> > > (Just arrowing file access under imagePath should be
> > > dangerous).
> That is true unfortunately.
> Maybe building a gettext plugin linking to libintl.a is indeed the
> best solution. Other ideas?
Using libintl.a is good (although, this way is not so easy because we
still have to convert UTF-8 to inner character representation in
But placing user's .mo files into the untrusted directory is not a bad
idea. When startup, we can still access imagePath, so we can read
default mo file in the imagePath. If a user want to modify
translation, new mo file is saved into untrusted directory, and it
overrides original mo at imagePath. Is it reasonable?
A defect of this idea is that you can not change to other language
once eToys loads a project and becomes secure mode.
More information about the etoys-dev