[Etoys] work around layout checking of msgfmt

[Takashi Yamamiya]

Hi Bert, Korakurider,

I think using just one domain is reasonable compromise for First Deployment.
I don't think we can test enough text domain support in #translated for this limited time.
Because String is a essential system class.

But still we can cheat as if text domain is supported. Instead of changing text
domain dynamically, other domain can be override. For example, when you load BotsInc,
MO file for BotsInc overrides original one.

Although a number of PO files can be independent to MO file, I am working about
one big PO file. Actually original GetTextExporter generates just a PO file. But
I want to merge it with Korakurider's GetTextExporter2 because there are a lot of
common code.

Cheers,
- Takashi

korakurider wrote:
> Hi, Bert.
> 
> --- Bert Freudenberg <bert at freudenbergs.de> wrote:
>> Are you aware of our discussions regarding reducing
>> the number of  
>> translation files? While modularity is valuable, it
>> makes live harder  
>> for translators and maintainers. Not sure who is
>> going to work on  
>> this - you or Takashi? I filed a ticket anyway:
>>
>> https://dev.laptop.org/ticket/3816
>     I know, but...
>     As in the previous discussion thread, I think more
> important questions would be 
>     a) for the lookup of #translated, how to know correct
> domain of the receiver of #translated. without this b)
> can't be executed in real.
>     b) how MOs/textdomains are packaged
> 
>     After determing them we can formulate how to package
> POs, I think.  
>     (We have been discussing about PO first.  But I think
> we need to think about textdomain first)
> 
>     My current understanding is right now we don't have
> good strategy for a).  I come to deadlock around there...
>     Possible workaround Takashi proposed recently is that
> we use just only one domain for whole etoys system.  I
> think that is not bad, especially for FRS.  How do you
> think?