- 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@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@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
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@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@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-separatedwords"
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@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Hi.
On Tue, Apr 19, 2011 at 12:22 PM, Ricardo Moran richi.moran@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.
/Korakurider
On Tue, Apr 19, 2011 at 1:20 AM, Korakurider korakurider@gmail.com wrote:
Hi.
On Tue, Apr 19, 2011 at 12:22 PM, Ricardo Moran richi.moran@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 uniqueproblems 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
On 19.04.2011, at 14:50, Ricardo Moran wrote:
On Tue, Apr 19, 2011 at 1:20 AM, Korakurider korakurider@gmail.com wrote: Hi.
On Tue, Apr 19, 2011 at 12:22 PM, Ricardo Moran richi.moran@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?
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 -
On Tue, Apr 19, 2011 at 11:22 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 19.04.2011, at 14:50, Ricardo Moran wrote:
On Tue, Apr 19, 2011 at 1:20 AM, Korakurider korakurider@gmail.comwrote:
Hi.
On Tue, Apr 19, 2011 at 12:22 PM, Ricardo Moran richi.moran@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 uniqueproblems 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 etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Korakurider -
Ricardo Moran