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:
>>> 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)
>>> - 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
Christian Theune · c...@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
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -