[Etoys] Fwd: MO reader

[Takashi Yamamiya]

Hi Korakurider, Bert,

This is a great work! The source code helps a lot to understand the
structure of mo file. I'm glad that it is so simple (I was
questionable to support mo file before looking at the code).  I think
it is greater if you upload it as a ticket for someone who are
interested in mo file (or, I can do with your permission).

Anyway, I have an idea about fragmentation of po files. We have
divided translations because there are too many words in eToys. But if
we sort words into reasonable way as Bert's idea, "Sorting in pot
files" https://dev.laptop.org/ticket/3596, we don't need to divide
translations, do we? A translator can work any reasonable fragment in a
big PO file sorted by class category, class, and method.

My frustration of many PO files comes from:

- Some words will be placed in two or more po files, and conflict if
  those files have different translations. This will be solved by
  using thisContext technically, but a translator have no idea which
  textdomain is used for a word on the screen without looking into
  Smalltalk code.

- Now, there are 406 po and pot files. And it will increase. It is not
  difficult to manage it, but hard to keep my attention to avoid a
  small mistake. Honestly, boring...

I totally agree to support textdomain for eToys application. So my
proposal is only registered class categories are considered as other
textdomains, rest are in a big po file. I'm sorry if it confuses the
last agreed discussion.

Cheers,
- Takashi

>> 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.