[Etoys] Fwd: MO reader
korakurider at yahoo.co.jp
Fri Sep 21 00:19:16 EDT 2007
--- Bert Freudenberg <bert at freudenbergs.de> wrote:
> On Sep 20, 2007, at 16:00 , korakurider at yahoo.co.jp
> > 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
> > 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:
> | 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
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
> > 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
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
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
More information about the Etoys