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

[Ricardo Moran]

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.

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

I don't know if this will work, but if you think it's a good idea I'll give
it a try tomorrow.

Cheers,
Richo


On Mon, Apr 18, 2011 at 10:40 PM, Korakurider <korakurider at gmail.com> wrote:

> > * Exporting a GetTextTranslator was giving a DNU because
> GetTextExporter>>translationFor:in: was asking "translator translations".
>       Do we still need GetTextExporter class?
>      I think the class became obsolete at least in Etoys image (and
> Pharo maybe). Its only use would be migrating old in-image
> translations to PO format.
>
> /Korakurider
>
>
> On Tue, Apr 19, 2011 at 1:35 AM,  <commits at source.squeak.org> wrote:
> > Ricardo Moran uploaded a new version of GetText to project Etoys:
> > http://source.squeak.org/etoys/GetText-Richo.14.mcz
> >
> > ==================== Summary ====================
> >
> > Name: GetText-Richo.14
> > Author: Richo
> > Time: 18 April 2011, 1:35:48 pm
> > UUID: fe80068b-c439-cb4e-b5bb-a659673f623b
> > Ancestors: GetText-Richo.13
> >
> > * Exporting a GetTextTranslator was giving a DNU because
> GetTextExporter>>translationFor:in: was asking "translator translations".
> > * TextDomainManager class>>allKnownDomains was ignoring the special
> domain "Etoys-Tiles"
> >
> > =============== Diff against GetText-Richo.13 ===============
> >
> > Item was changed:
> >  ----- Method: GetTextExporter>>translationFor:in: (in category
> 'private') -----
> >  translationFor: aKey in: translator
> > +       | translation |
> > +       translator ifNil: [^ ''].
> > +       TextDomainManager allKnownDomains do: [:domain |
> > +               translation := translator translate: aKey inDomain:
> domain.
> > +               aKey = translation ifFalse: [^translation]
> > +       ].
> > +       ^ aKey!
> > -       translator ifNil: [^''].
> > -       translator translations at: aKey ifPresent: [:s | ^s].
> > -       "If we have old camelCase translations, make space-separated
> words"
> > -       translator translations at: aKey toCamelCase ifPresent: [:s |
> > -               (s includes: Character space) ifTrue: [^s].
> > -               ^s fromCamelCase].
> > -       ^''!
> >
> > Item was changed:
> >  ----- Method: TextDomainManager class>>allKnownDomains (in category
> 'accessing') -----
> >  allKnownDomains
> >  "Every package has it's own text domain now so it's not necessary to
> keep a registry of all domains, we can simply return all the packages in the
> image.
> >  PROBLEM: If a package doesn't contain translations, it won't have a mo
> file but the GetTextTranslator will try to load it anyway. This happens when
> we switch languages. So far I tested it briefly and it seems to work..."
> > + ^PackageOrganizer default packageNames , {'Etoys-Tiles'}!
> > - ^PackageOrganizer default packageNames!
> >
> > _______________________________________________
> > etoys-dev mailing list
> > etoys-dev at squeakland.org
> > http://lists.squeakland.org/mailman/listinfo/etoys-dev
> >
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20110419/8a8d2665/attachment.html>