[Etoys] Fwd: MO reader
tak at metatoys.org
Thu Sep 20 16:45:28 EDT 2007
Before I change the structure of gettext files (maybe nothing happens
for a while though,) I will notice about it to this email list,
then merge all translation files in launchpad and trac, and export
them again. I think we don't lose any translation,
so please continue to translate whatever this discussion goes.
Bert Freudenberg wrote:
> Yes that sounds good. Let's try.
> - Bert -
> On Sep 20, 2007, at 21:34 , Takashi Yamamiya wrote:
>> 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.
>> - 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
>>> 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.
More information about the Etoys