[etoys-dev] Etoys: GetText-Richo.14.mcz

[Ricardo Moran]

On Tue, Apr 19, 2011 at 1:20 AM, Korakurider <korakurider at gmail.com> wrote:

> Hi.
>
> On Tue, Apr 19, 2011 at 12:22 PM, Ricardo Moran <richi.moran at gmail.com>
> wrote:
> > I think it's still useful. I used it to export all translatable strings
> for
> > Physical Etoys (including the Etoys translations). But maybe there is a
> > better way that I ignore.
>    Ah, I see.
>
> > Also, I was thinking about the translation support and I came to the
> > conclusion that I really hate the String>>#translatedInAllDomains hack.
> The
> > problem is that I don't know how to fix it so it would find the right
> domain
> > in *all* cases.
>     I think translation support in Squeak/Etoys have introduced unique
> problems and
>    the hack is reasonable workaround at this time.
>
> > So, here is my idea: what if instead of having a bunch of .mo files, we
> come
> > back to the big etoys.mo file but keeping the .po files divided in
> domains?
> > I mean, the translators would be happy because they'll have all the files
> > splitted by domain. And, at the time of compiling, we merge all the po
> files
> > into one huge etoys.po file and just compile that, thus simplifying the
> > #translated stuff a lot.
>    Once split domains, there could be the case that a phrase have
> multiple translations.
>   (Note: ability to have multiple translations might be opportunity )
>   So I suspect merging translations isn't good change.
>
>
Yes, there might be multiple translations but they'll depend on the domain
being detected properly. Currently, with the #translatedInAllDomains
workaround we can't rely on the domain detection so it's kinda worthless,
don't you think?



>
> /Korakurider
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20110419/a8d9a2ef/attachment-0001.html>