zope.18n:translate() keyword arguments versus MessageID attributes
Hi, I've fiddled a bit with https://bugs.edge.launchpad.net/zope.i18n/+bug/592753 and ended up with an unclear situation: The ``translate'' methods of both zope.i18n and ITranslationDomain have optional parameters for the domain/default/mapping attributes of a message ID. The message ID attributes always override the parameters but it is not said why. (I probed the tests and they at least verify that this is the case but don't state motivation.) As I had to chase this down for quite a while when I originally tried to call zope.i18n.translate() directly (for providing translated emails) it took me quite a while to understand what's going on. I see two possibilities for improving the situation: - don't implicitly ignore the parameters, but raise an exception if both a message id and at least one of the parameters (domain/default /mapping) is given and write some documentation that explains the situation (what is happening and why) or - make the parameters take precendence over the message id attributes So - why not do the latter? Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/26/2010 09:36 AM, Christian Theune wrote:
Hi,
I've fiddled a bit with https://bugs.edge.launchpad.net/zope.i18n/+bug/592753 and ended up with an unclear situation:
The ``translate'' methods of both zope.i18n and ITranslationDomain have optional parameters for the domain/default/mapping attributes of a message ID.
The message ID attributes always override the parameters but it is not said why. (I probed the tests and they at least verify that this is the case but don't state motivation.)
As I had to chase this down for quite a while when I originally tried to call zope.i18n.translate() directly (for providing translated emails) it took me quite a while to understand what's going on.
I see two possibilities for improving the situation:
- don't implicitly ignore the parameters, but raise an exception if both a message id and at least one of the parameters (domain/default /mapping) is given and write some documentation that explains the situation (what is happening and why)
or
- make the parameters take precendence over the message id attributes
So - why not do the latter?
I prefer the latter, and don't think we need a deprecation cycle for it: if the call site is passing in a mapping, that is presumably more specific than anything stored in the catalog. I can't see how we would break anything here, as nobody is likely to have actually used the feature (since it is effectively a no-op). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzG4hgACgkQ+gerLs4ltQ5d0wCgmalGkBVV+TJmXCk4KqiXlM7c 2LQAoNn6oKRQnCACRxzqitdAYnEoUro9 =Kn2D -----END PGP SIGNATURE-----
Am 26.10.2010, 16:13 Uhr, schrieb Tres Seaver <tseaver@palladion.com>:
I prefer the latter, and don't think we need a deprecation cycle for it: if the call site is passing in a mapping, that is presumably more specific than anything stored in the catalog. I can't see how we would break anything here, as nobody is likely to have actually used the feature (since it is effectively a no-op).
+1 Some additional justification - it's inconsistent to have different behaviour for message id's and local strings plus it basically defeats the purpose of domains if you can't override the system values in the application. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
Am 26.10.2010 um 16:13 schrieb Tres Seaver:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/26/2010 09:36 AM, Christian Theune wrote:
Hi,
I've fiddled a bit with https://bugs.edge.launchpad.net/zope.i18n/+bug/592753 and ended up with an unclear situation:
The ``translate'' methods of both zope.i18n and ITranslationDomain have optional parameters for the domain/default/mapping attributes of a message ID.
The message ID attributes always override the parameters but it is not said why. (I probed the tests and they at least verify that this is the case but don't state motivation.)
As I had to chase this down for quite a while when I originally tried to call zope.i18n.translate() directly (for providing translated emails) it took me quite a while to understand what's going on.
I see two possibilities for improving the situation:
- don't implicitly ignore the parameters, but raise an exception if both a message id and at least one of the parameters (domain/default /mapping) is given and write some documentation that explains the situation (what is happening and why)
or
- make the parameters take precedence over the message id attributes
So - why not do the latter?
I prefer the latter, and don't think we need a deprecation cycle for it: if the call site is passing in a mapping, that is presumably more specific than anything stored in the catalog. I can't see how we would break anything here, as nobody is likely to have actually used the feature (since it is effectively a no-op).
+1 But the `mapping` attribute should update the existing mapping of the message ID as this would allow to have a partial mapping stored on the message ID and add the other part when translating. Creating new message IDs from existing message IDs should behave the same way: police_and_dog = _('${a} + ${b} = ${c}', mapping=dict(a='police', c='police dog')) police_dog = _(police_and_dog, mapping=dict(b='dog')) Currently the mapping for `police_dog` is ignored but I think it should update the mapping of `police_and_dog` in the new message ID. Currently you have to do the following to achieve the same: mapping = police_and_dog.mapping.copy() mapping.update(dict(b='dog')) police_dog = _(unicode(police_and_dog), mapping=mapping) Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
On 10/27/2010 08:44 AM, Michael Howitz wrote:
Am 26.10.2010 um 16:13 schrieb Tres Seaver:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/26/2010 09:36 AM, Christian Theune wrote:
Hi,
I've fiddled a bit with https://bugs.edge.launchpad.net/zope.i18n/+bug/592753 and ended up with an unclear situation:
The ``translate'' methods of both zope.i18n and ITranslationDomain have optional parameters for the domain/default/mapping attributes of a message ID.
The message ID attributes always override the parameters but it is not said why. (I probed the tests and they at least verify that this is the case but don't state motivation.)
As I had to chase this down for quite a while when I originally tried to call zope.i18n.translate() directly (for providing translated emails) it took me quite a while to understand what's going on.
I see two possibilities for improving the situation:
- don't implicitly ignore the parameters, but raise an exception if both a message id and at least one of the parameters (domain/default /mapping) is given and write some documentation that explains the situation (what is happening and why)
or
- make the parameters take precedence over the message id attributes
So - why not do the latter?
I prefer the latter, and don't think we need a deprecation cycle for it: if the call site is passing in a mapping, that is presumably more specific than anything stored in the catalog. I can't see how we would break anything here, as nobody is likely to have actually used the feature (since it is effectively a no-op).
+1 But the `mapping` attribute should update the existing mapping of the message ID as this would allow to have a partial mapping stored on the message ID and add the other part when translating.
Does this use case really appear that often? I see that there isn't much danger to doing that as the mappings shouldn't be too large anyway and the code that processes them doesn't allow for control structures based on their values so having superfluous values wouldn't hurt and this behaviour would keep old code working. OTOH can you make a feature request for this so I can deal with it separately? Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Am 27.10.2010 um 08:52 schrieb Christian Theune:
On 10/27/2010 08:44 AM, Michael Howitz wrote: [...]
+1 But the `mapping` attribute should update the existing mapping of the message ID as this would allow to have a partial mapping stored on the message ID and add the other part when translating.
Does this use case really appear that often?
I think of it as low hanging fruit.
I see that there isn't much danger to doing that as the mappings shouldn't be too large anyway and the code that processes them doesn't allow for control structures based on their values so having superfluous values wouldn't hurt and this behaviour would keep old code working.
OTOH can you make a feature request for this so I can deal with it separately?
https://bugs.launchpad.net/zope.i18n/+bug/668189 (Did not find out how to make a feature request, so filed it as bug.) Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
On 10/29/2010 08:26 AM, Michael Howitz wrote:
Am 27.10.2010 um 08:52 schrieb Christian Theune:
On 10/27/2010 08:44 AM, Michael Howitz wrote: [...]
+1 But the `mapping` attribute should update the existing mapping of the message ID as this would allow to have a partial mapping stored on the message ID and add the other part when translating.
Does this use case really appear that often?
I think of it as low hanging fruit.
You're probably right.
I see that there isn't much danger to doing that as the mappings shouldn't be too large anyway and the code that processes them doesn't allow for control structures based on their values so having superfluous values wouldn't hurt and this behaviour would keep old code working.
OTOH can you make a feature request for this so I can deal with it separately?
https://bugs.launchpad.net/zope.i18n/+bug/668189 (Did not find out how to make a feature request, so filed it as bug.)
Make a bug and mark it wishlist. I've done that for your. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Am 29.10.2010 um 08:36 schrieb Christian Theune: [...]
OTOH can you make a feature request for this so I can deal with it separately?
https://bugs.launchpad.net/zope.i18n/+bug/668189 (Did not find out how to make a feature request, so filed it as bug.)
Make a bug and mark it wishlist. I've done that for your.
Huh, I'm not allowed to change the "importance" of this ticket. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
participants (4)
-
Charlie Clark -
Christian Theune -
Michael Howitz -
Tres Seaver