Smalltalk › Frameworks & Tools › eToys Development

Etoys: GetText-Richo.14.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

commits-2

Etoys: GetText-Richo.14.mcz

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
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Korakurider-2

Re: Etoys: GetText-Richo.14.mcz

> * 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, <[hidden email]> 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
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: Etoys: GetText-Richo.14.mcz

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 <[hidden email]> 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, <[hidden email]> 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
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Korakurider-2

Re: Etoys: GetText-Richo.14.mcz

Hi.

On Tue, Apr 19, 2011 at 12:22 PM, Ricardo Moran <[hidden email]> 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.

/Korakurider
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: Etoys: GetText-Richo.14.mcz

On Tue, Apr 19, 2011 at 1:20 AM, Korakurider <[hidden email]> wrote:

Hi.

On Tue, Apr 19, 2011 at 12:22 PM, Ricardo Moran <[hidden email]> 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

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Bert Freudenberg

Re: Etoys: GetText-Richo.14.mcz

On 19.04.2011, at 14:50, Ricardo Moran wrote:

On Tue, Apr 19, 2011 at 1:20 AM, Korakurider <[hidden email]> wrote:
Hi.

On Tue, Apr 19, 2011 at 12:22 PM, Ricardo Moran <[hidden email]> 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?

It works pretty well, and we could fix it for the cases where it does not, if needed, me thinks. So I would not call it "worthless".

Having one .mo per .po seems most straight-forward for everyone to understand. The translatedInAllDomains "hack" is almost invisible. So we would need a very good reason to abandon that.

- Bert -

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: Etoys: GetText-Richo.14.mcz

On Tue, Apr 19, 2011 at 11:22 AM, Bert Freudenberg <[hidden email]> wrote:

On 19.04.2011, at 14:50, Ricardo Moran wrote:

On Tue, Apr 19, 2011 at 1:20 AM, Korakurider <[hidden email]> wrote:

Hi.

On Tue, Apr 19, 2011 at 12:22 PM, Ricardo Moran <[hidden email]> 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?

It works pretty well, and we could fix it for the cases where it does not, if needed, me thinks. So I would not call it "worthless".

Having one .mo per .po seems most straight-forward for everyone to understand. The translatedInAllDomains "hack" is almost invisible. So we would need a very good reason to abandon that.

Yes, it's true. It works and it's very easy to understand. I still think it's pretty ugly, though :)

- Bert -

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev