[etoys-dev] Still working on translation support :)

[Ricardo Moran]

Great! I moved all the translation stuff into a GetText package.

I also tried to do the translation checking all domains if the translation
wasn't found in the correct domain. But it seems there are a some places
where the translation is happening twice so the second one is never found
because the phrase is already translated. This is the case of the world menu
for example. I fixed it by chaging most of the #traslated sends to
#translatedNoop, I could make it a lot easier by removing the #translated
send in #fillIn:from: but when I did that the menu icons disappeared, I
don't know why. Anyway, sending #translatedNoop is the way to go in that
case if I understood correctly.

Richo

On Thu, May 20, 2010 at 3:12 AM, Korakurider <korakurider at gmail.com> wrote:

> On Tue, May 18, 2010 at 11:41 PM, Ricardo Moran <richi.moran at gmail.com>
> wrote:
> > Sorry, I should have checked that the upload was correct.
> > The load order should be the following (actually, I think the only
> > requirement is to load System before Collections, but this particular
> order
> > worked for me):
> > System-Richo.14
> > Etoys-Richo.9
> > Multilingual-Richo.4
> > Protocols-Richo.2
> > Collections-Richo.5
>
>    This worked, thanks!
>
>   Now I could migrate legacy translation for Japanese(ja) to seprated
> formart and run Etoys with migrated translations.
>   For record here is steps of migration.
>
>    "1. There is no instance of InternalTranslator in fresh developer image,
>      so make one for loading legacy PO"
>     InternalTranslator newLocaleID: (LocaleID isoLanguage: 'ja').
>
>    "2. Start LanguageEditor for locale 'ja'.
>     3.  With menu "gettext import", load legacy PO of one big domain
>     into InternalTranslator. "
>
>    "4. Export splitted PO with translation"
>     GetTextExporter2
>              new
>                 exportTranslator:
>                     InternalTranslator newLocaleID: (LocaleID
> isoLanguage: 'ja').
>
>    "5. compile POs and install MOs"
>
>    In course of migration I found a few problems that I will report lator.
>
> > Best regards,
> > Richo
> > P.S.: I see that Hilaire made a GetText package for Pharo. Can we do the
> > same here? It's getting annoying to be modifying so many packages.
>      I can live with that :-)
>     But the gettext package could be reused in squeak trunk image.
>     (We could even reuse artifact by Pharo folks).
>
> /Korakurider
>
> > On Tue, May 18, 2010 at 7:42 AM, Korakurider <korakurider at gmail.com>
> wrote:
> >>
> >> Hi Ricardo.
> >>
> >> On Tue, May 18, 2010 at 12:14 PM, Ricardo Moran <richi.moran at gmail.com>
> >> wrote:
> >> > Hi guys, today I uploaded a bunch of entries to the inbox. Most of
> them
> >> > are
> >> > little hacks and experiments, but it works somehow and it can be
> tested.
> >> > If
> >> > you're interested replace your current locale folder with this
> >> > one http://tecnodacta.com.ar/gira/gsoc/locale.zip. I made these mo
> files
> >> > using the existing translations from Etoys 4.0 and they contain only
> the
> >> > following languages: english, spanish, german, french, portuguese.
> >>
> >> I want to review your stuff.  But I can't properly load your snapshot
> >> into fresh dev image from inbox and emergency evaluator was showed.  I
> >> suspect order of loading was wrong.  Could you show the correct order
> >> of loading packages?
> >>
> >> > I still have a lot of strings I can't translate because the correct
> >> > domain
> >> > sometimes is not easy to find (and there are so many #translated sends
> I
> >> > don't know where to look). Anyway, I managed to translate most of the
> >> > tiles
> >> > by hacking ObjectWithDocumentation>>#wording but I don't think this is
> a
> >> > nice solution. I'm not really sure how this object is used elsewhere
> but
> >> > maybe in Etoys we could use the #untranslatedWording and translate the
> >> > string later (I'm kinda thinking out loud so please correct me if I'm
> >> > wrong).
> >> > Korakurider fix to SQ-139 helped me a lot to understand some things
> but
> >> > I
> >> > haven't included it yet because I want to fully understand this before
> I
> >> > can
> >> > jump on managing different contexts.
> >>    I pointed SQ-139 because changes interesting to you have been
> >> distilled in the change set.  But I think context support would be
> >> nice-to-have feature with low priority that we might want to work on
> >> after work of splitting translation will be completed.
> >>
> >> /Korakurider
> >>
> >> > Regarding method properties to store text domains, I tried that
> approach
> >> > and
> >> > implemented it in a lazy way. It seems to work well (I thought it
> would
> >> > be
> >> > worst). I also tried to preconfigure all the compiled methods but I
> ran
> >> > into
> >> > a "Space is low" warning, I might be doing something terribly wrong
> >> > here. If
> >> > you want to take a look, the code is
> >> > TextDomainManager>>#updateDomainOfAllMethodsWithTranslations.
> >> > Best regards
> >> > Richo
> >> > _______________________________________________
> >> > 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/20100520/ef3c16ee/attachment.html