[Etoys] Fwd: MO reader

[Takashi Yamamiya]

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
>> #translatedNoop.
>> 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
Squeak).

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.

Cheers,
- Takashi