[Etoys] Fwd: MO reader

[korakurider]

Hi Bert,

--- Bert Freudenberg <bert at freudenbergs.de> wrote:


> On Sep 20, 2007, at 16:00 , korakurider at yahoo.co.jp
> wrote:
> 
> > Hi.
> > I am writing a simple MO reader. First cut is
> attached: I
> > don't care performance for now.
> > I tested it with japanese MOs bundled with
> Ruby-gettext
> > package, as I don't have gettext runtime to
> compile POs
> > for EToys right now.
> >
> > I think we need to decide for some design issues
> to go
> > forward:
> >
> > a) How to package MO from those highly fragmented
> POs: how
> > many MOs will we have?  what is assigned to
> textdomain ?
> > I am not certain whether current packaging scheme
> for POs
> > will be also good for MO/textdomain.
> >
> > In typical usage textdomain represents
> "application" and
> > translation is provided for each app.
> >
> > Also note that this decision will affect design
> for good
> > performance and resource usage.
> 
> The idea was to have one MO per class category,
> because the best  
> equivalent to "applications" in Squeak are class
> categories. This way  
> an MO file corresponds roughly to a Monticello
> Package, for example.
> 
> One problem is that the classes in the etoys image
> are not very  
> nicely categorized - I think that was done in 3.8.1
> but not 3.8. For  
> example, there is a stray OLPC category which would
> better be merged  
> with the Sugar category.
> 
> > b) how to decide textdomain on #translated?
> 
> Based on the category of the sender of #translated:
> 
> 	translated
> 		| classAndSelector category |
> 		classAndSelector := thisContext sender who.
> 		category := classAndSelector first category.
> 
> This is rather inefficient, when loading an MO file
> we might want to  
> create a cache for looking up the category from the
> CompiledMethod  
> directly.
  I think it would be safe to implement like this if
receiver of #translated is literal.
  But how about #translatedNoop?  I am not sure if senders
of #translated and #translatedNoop have same category.  

> > c) Where will MO reside in runtime environment?
> 
> In a subdirectory of "Smalltalk imagePath".
> 
> > I am thinking about squeakland-OLPC with
> SecurityPlugin
> > enabled.
> > (Is security plugin enabled on XO ?)
> 
> We might need to add an exception to the
> SecurityPlugin allowing to  
> read from the po path. On the XO we don't really
> have to enable it,  
> but the same translations should work on the regular
> etoys.
   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).


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/