[etoys-dev] Still working on translation support :)
korakurider at gmail.com
Thu May 20 02:12:58 EDT 2010
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):
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"
InternalTranslator newLocaleID: (LocaleID
"5. compile POs and install MOs"
In course of migration I found a few problems that I will report lator.
> Best regards,
> 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).
> 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>
>> > 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.
>> > 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
More information about the etoys-dev