Hello,
(First, sorry if this question has been already answered: I didn't find the answer in this mailing-list)
I'm working on the SqueakBot project, which is getting closer and closer to the Physical Etoys project.
We have a fair amount of strings that are specific to this project, and we try to currently support 3 languages (English, Spanish and French). Most (but not all) of these strings are in tiles.
My current approach, consisting in exporting all the EToys .pot and completing the missing SqueakBot/Physical Etoys strings in the relevant .po files.
As you can imagine, it's painful to maintain it synchronized with the official translations, and it forces us to redistribute the whole .po.
So, I'm wondering if there's a better way to manage it, like a project specific .po file?
I must say I've not yet dug into the translation system, but if an 'official' way to deal with it exist...
Cheers, Severin
On 12.12.2011, at 18:30, Séverin Lemaignan wrote:
Hello,
(First, sorry if this question has been already answered: I didn't find the answer in this mailing-list)
I'm working on the SqueakBot project, which is getting closer and closer to the Physical Etoys project.
We have a fair amount of strings that are specific to this project, and we try to currently support 3 languages (English, Spanish and French).
Great!
Most (but not all) of these strings are in tiles.
Ah. Tile translations are looked up in the "Etoys-Tiles" domain. However, if a translation is not found in a domain, it is looked up in all domains.
My current approach, consisting in exporting all the EToys .pot and completing the missing SqueakBot/Physical Etoys strings in the relevant .po files.
As you can imagine, it's painful to maintain it synchronized with the official translations, and it forces us to redistribute the whole .po.
So, I'm wondering if there's a better way to manage it, like a project specific .po file?
I must say I've not yet dug into the translation system, but if an 'official' way to deal with it exist...
If you put all your code in a separate package, then adding a YourPackage.mo file should let you keep your translations separate from the default translations.
And you can add the tile translations to that file, too. The fallback translation mechanism should find it there.
- Bert -
On Mon, Dec 12, 2011 at 2:48 PM, Bert Freudenberg bert@freudenbergs.dewrote:
If you put all your code in a separate package, then adding a YourPackage.mo file should let you keep your translations separate from the default translations.
And you can add the tile translations to that file, too. The fallback translation mechanism should find it there.
But wouldn't that be much slower? IIRC the fallback translation mechanism was made for exceptional situations, we shouldn't rely on it.
Cheers, Richo
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On 13.12.2011, at 16:53, Ricardo Moran wrote:
On Mon, Dec 12, 2011 at 2:48 PM, Bert Freudenberg bert@freudenbergs.de wrote:
If you put all your code in a separate package, then adding a YourPackage.mo file should let you keep your translations separate from the default translations.
And you can add the tile translations to that file, too. The fallback translation mechanism should find it there.
But wouldn't that be much slower? IIRC the fallback translation mechanism was made for exceptional situations, we shouldn't rely on it.
Cheers, Richo
IMHO it's a very simple solution. If it turns out to be too slow (I doubt that, but still) then caching the lookup would be rather easy to do.
Better ideas welcome of course :)
- Bert -
Cool. Thanks for the answers.
I'll definitely try the "fallback" solution and see how it behaves.
Severin
2011/12/13 Bert Freudenberg bert@freudenbergs.de:
On 13.12.2011, at 16:53, Ricardo Moran wrote:
On Mon, Dec 12, 2011 at 2:48 PM, Bert Freudenberg bert@freudenbergs.de wrote:
If you put all your code in a separate package, then adding a YourPackage.mo file should let you keep your translations separate from the default translations.
And you can add the tile translations to that file, too. The fallback translation mechanism should find it there.
But wouldn't that be much slower? IIRC the fallback translation mechanism was made for exceptional situations, we shouldn't rely on it.
Cheers, Richo
IMHO it's a very simple solution. If it turns out to be too slow (I doubt that, but still) then caching the lookup would be rather easy to do.
Better ideas welcome of course :)
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Ricardo Moran -
Séverin Lemaignan