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-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
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev