Re: [Zope-dev] zope.18n:translate() keyword arguments versus MessageID attributes
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 · m...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.18n:translate() keyword arguments versus MessageID attributes
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 · 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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.18n:translate() keyword arguments versus MessageID attributes
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 · m...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.18n:translate() keyword arguments versus MessageID attributes
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 · 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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.18n:translate() keyword arguments versus MessageID attributes
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 · m...@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
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.18n:translate() keyword arguments versus MessageID attributes
Am 26.10.2010, 16:13 Uhr, schrieb Tres Seaver : > 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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.18n:translate() keyword arguments versus MessageID attributes
-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 tsea...@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- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
