Nowadays, when we have a fully egg-based setup, the translations in the zope.app.locales package make no sense anymore as it's very hard to maintain them and it just wrong (to me at least) to have a separate centralized translations package for a hundred of eggs. The zope.i18n >= 3.5.0 have a feature of merging multiple message catalogs registered for the same domain. So we have two options here: a) Continue use the "zope" translation domain for all packages and make each package provide own message catalog to be merged into "zope" domain. b) Make every package provide its own translation domain. So say zope.container will have and register its own domain named "zope.container". Either option is fine with me, however b) helps to avoid msgid clashes, whle a) allows us to reuse msgids. I'd like to hear community opinion on that and after we decide which option to choose I volunteer to migrate current zope.app.locales translations to every egg that have msgids, previously translated by zope.app.locales. However, that's kinda pain in the ass and I'll gladly accept any help on that. :-) -- WBR, Dan Korostelev
On Monday 09 February 2009, Dan Korostelev wrote:
Nowadays, when we have a fully egg-based setup, the translations in the zope.app.locales package make no sense anymore as it's very hard to maintain them and it just wrong (to me at least) to have a separate centralized translations package for a hundred of eggs.
I think that while having a centralized translations package make no sense anymore, I think we should still maintain a canonical translation memory that serves as the authoritative translation for all packages. This provides consistency across packages and is the way it is done in the professional localization business. So basically, option (b) with option (a) as translation memory. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
2009/2/10 Stephan Richter <srichter@cosmos.phy.tufts.edu>:
On Monday 09 February 2009, Dan Korostelev wrote:
Nowadays, when we have a fully egg-based setup, the translations in the zope.app.locales package make no sense anymore as it's very hard to maintain them and it just wrong (to me at least) to have a separate centralized translations package for a hundred of eggs.
I think that while having a centralized translations package make no sense anymore, I think we should still maintain a canonical translation memory that serves as the authoritative translation for all packages. This provides consistency across packages and is the way it is done in the professional localization business.
So basically, option (b) with option (a) as translation memory.
Can you explain that once more? Do you mean that we translate each package in its own translation domain and then collect messages from all packages to a global translation domain that is used only as a translation memory and not for actual i18n of components? -- WBR, Dan Korostelev
Hello Dan, In short, a good translation is consistent. That means the same sentences are translated to the same foreign sentence. A so-called translation memory is used for that. Also terms (specific words or expressions of the domain) are translated to the same foreign term. I think that's the idea of Stephan. There are proprietary tools to enforce this. I think launchpad translation is somehow also a translation memory as it pulls in previous translations. Though no idea how the above could be solved with FOSS tools. Tuesday, February 10, 2009, 2:36:28 AM, you wrote: DK> 2009/2/10 Stephan Richter <srichter@cosmos.phy.tufts.edu>:
On Monday 09 February 2009, Dan Korostelev wrote:
Nowadays, when we have a fully egg-based setup, the translations in the zope.app.locales package make no sense anymore as it's very hard to maintain them and it just wrong (to me at least) to have a separate centralized translations package for a hundred of eggs.
I think that while having a centralized translations package make no sense anymore, I think we should still maintain a canonical translation memory that serves as the authoritative translation for all packages. This provides consistency across packages and is the way it is done in the professional localization business.
So basically, option (b) with option (a) as translation memory.
DK> Can you explain that once more? Do you mean that we translate each DK> package in its own translation domain and then collect messages from DK> all packages to a global translation domain that is used only as a DK> translation memory and not for actual i18n of components? -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: She is descended from a long line that her mother listened to. - Gypsy Rose Lee
On Monday 09 February 2009, Adam GROSZER wrote:
There are proprietary tools to enforce this. I think launchpad translation is somehow also a translation memory as it pulls in previous translations. Though no idea how the above could be solved with FOSS tools.
KDE's KBabel has support for PO-based translation memories. Basically, you dedicate a PO as the master file (translation memory) and then all POs that you translate use that master file to make suggestions. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hello, Yeah, after a quick check it's superseeded by Lokalize which in turn seems to have also Translation memory and Glossary, where glossary looks like the termbase support. http://docs.kde.org/development/en/kdesdk/lokalize/glossary.html Tuesday, February 10, 2009, 9:01:49 AM, you wrote: SR> On Monday 09 February 2009, Adam GROSZER wrote:
There are proprietary tools to enforce this. I think launchpad translation is somehow also a translation memory as it pulls in previous translations. Though no idea how the above could be solved with FOSS tools.
SR> KDE's KBabel has support for PO-based translation memories. Basically, you SR> dedicate a PO as the master file (translation memory) and then all POs that SR> you translate use that master file to make suggestions. SR> Regards, SR> Stephan -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Do not make friends who are comfortable to be with. Make friends who will force you to lever yourself up. - Thomas J. Watson, Sr.
2009/2/10 Adam GROSZER <agroszer@gmail.com>:
In short, a good translation is consistent. That means the same sentences are translated to the same foreign sentence. A so-called translation memory is used for that. Also terms (specific words or expressions of the domain) are translated to the same foreign term.
Well, I have a general idea about what translation memory is. I just wanted to clarify how we are going to implement that for zope eggs. So, as far as I understand now, our localization migration process should be like that: 1) create a separate translation domain for every package (so, the "zope.container" domain for the "zope.container" package) 2) merge catalogs provided by current zope.app.locales with every package's translations into the package's own domain (so we get all packages somehow translated). 3) write a tool (probably a buildout recipe) that collects translations from multiple packages into one PO/TMX/whatever file for using it as a translation memory file for translation tools. 4) call for translators 5) ... 6) PROFIT! :-) Correct me if I'm wrong. It would also cool to integrate it with launchpad translation system, but I didn't look at that yet. -- WBR, Dan Korostelev
Hey, +1 for getting rid of zope.app.locales as a centralized point for translations. +1 also to have a way to *see* the translations as a single whole, with the possibility to define a message id that is used by many packages. I'm not sure I get all the details. One question is whether packages that don't have any ZMI (such as zope.container) actually need translations at all? Should it define message ids at all? And if it does, wouldn't it be the job of the application that exposes these message ids to actually offer translations? In my mind, the Zope framework should offer facilities to support translating applications. These applications can be composed out of more than a single package, and we want to support the translation memory usecase for that. If the Zope framework defines messages itself itself, it should offer a way for an application that exposes them to have translations as well. The ZMI is simply a particular application on top of the Zope framework, and in my mind not actually the most important one to many of the users of the Zope framework. So let's not get caught up in a solution that really only focuses on the ZMI. Instead, let's consider the ZMI as a particular example of our problem. Oh, and once we get a policy fleshed out we should document it in our documentation section. :) Regards, Martijn
On Tue, Feb 10, 2009 at 01:54:54PM +0100, Martijn Faassen wrote:
In my mind, the Zope framework should offer facilities to support translating applications. These applications can be composed out of more than a single package, and we want to support the translation memory usecase for that. If the Zope framework defines messages itself itself, it should offer a way for an application that exposes them to have translations as well.
IMO it must also be possible for an application integrator to install a package that selectively overrides the default translations. How can that be done? At TOPP, when we used Plone 2 and PTS, we had a hack that allowed us to do this, see eg. https://svn.openplans.org/svn/sputnik/branches/0.9.8/sputnik/zinit.py This allowed us to provide some different (english) translations for the same message ids on two websites (openplans.org and livablestreets.com), just by having the sputnik package installed on one site. So far, I've been unable to find a way to accomplish the same thing with the zope 3 i18n infrastructure, which is blocking us from moving to plone 3 on the site that needs the overrides. Is this even possible? -- Paul Winkler http://www.slinkp.com
2009/2/10 Paul Winkler <slinkp@gmail.com>:
On Tue, Feb 10, 2009 at 01:54:54PM +0100, Martijn Faassen wrote:
In my mind, the Zope framework should offer facilities to support translating applications. These applications can be composed out of more than a single package, and we want to support the translation memory usecase for that. If the Zope framework defines messages itself itself, it should offer a way for an application that exposes them to have translations as well.
IMO it must also be possible for an application integrator to install a package that selectively overrides the default translations. How can that be done?
At TOPP, when we used Plone 2 and PTS, we had a hack that allowed us to do this, see eg. https://svn.openplans.org/svn/sputnik/branches/0.9.8/sputnik/zinit.py This allowed us to provide some different (english) translations for the same message ids on two websites (openplans.org and livablestreets.com), just by having the sputnik package installed on one site.
So far, I've been unable to find a way to accomplish the same thing with the zope 3 i18n infrastructure, which is blocking us from moving to plone 3 on the site that needs the overrides. Is this even possible?
Well, I didn't dig that too deeply, but I guess newer zope.i18n allows us to merge translation catalogs for one domain and they have predictable priority over each other, based on registration order (though that could be developed to give user more control over catalog priorities). So I think it's possible to override some msgids if you do that carefully. :-) -- WBR, Dan Korostelev
2009/2/10 Martijn Faassen <faassen@startifact.com>:
+1 also to have a way to *see* the translations as a single whole, with the possibility to define a message id that is used by many packages.
I'm not sure about the last thing. Message objects are bound to one translation domain, so the translation will be looked up only for that domain. However, we could provide some fallback translation domain as well.
I'm not sure I get all the details. One question is whether packages that don't have any ZMI (such as zope.container) actually need translations at all? Should it define message ids at all? And if it does, wouldn't it be the job of the application that exposes these message ids to actually offer translations?
I believe that it's often useful to have standard translations that can be used out of the box and not making application developers have to translate them every time. But it should be really easy for applications to override them, so we'll have to work on that. -- WBR, Dan Korostelev
Adam GROSZER wrote:
Though no idea how the above could be solved with FOSS tools.
You know Launchpad is being open sourced, right? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (6)
-
Adam GROSZER -
Chris Withers -
Dan Korostelev -
Martijn Faassen -
Paul Winkler -
Stephan Richter