On Sunday 27 February 2011, you wrote:
>..
Again, you write a lot and don't read enough.. So, I will repeat the same
things for a THIRD time.
> ...Because this would probably
> imply changing the method API sometimes and this is not allowed (or should
> not be allowed) during the life of ""stable"" releases. .... Albert solution
might be a good workaround.
Albert's solution IS a change of API, and IMHO a significant one. Because, it
would introduce translation loops ( gettext is all over the place) where they
have never worked before.
> I would add:
> - xrg: when you don't want to translate: wouldn't that be possible to
> explicitly pass "en_US" in the context rather than nothing? Then no perf
> impact with uid.
Can you show me that part of the code? Because you seem to insist that en_US
would result in no translation.. I dare you.
> I know all this looks ugly. But IMHO this is "real politic", now 6.0 is
> supposed to be stable and changing methods API is no solution,
I'm talking about the same thing here. Changing the way the frameworks behaves
for a given set of input IS a change of API. Yes, sometimes the previous
behavior was not the best one (kept you seeing English strings that no Spanish
person understands, for example), but the rule is to improve things only "to
behave as expected". Getting translated strings from an empty context is not
what I would ever expect from the framework. (already gave you 2 examples
where this is the designed behavior).
On Sunday 27 February 2011, you wrote:
>..
Again, you write a lot and don't read enough.. So, I will repeat the same
things for a THIRD time.
> ...Because this would probably
> imply changing the method API sometimes and this is not allowed (or should
> not be allowed) during the life of ""stable"" releases. .... Albert solution
might be a good workaround.
Albert's solution IS a change of API, and IMHO a significant one. Because, it
would introduce translation loops ( gettext is all over the place) where they
have never worked before.
> I would add:
> - xrg: when you don't want to translate: wouldn't that be possible to
> explicitly pass "en_US" in the context rather than nothing? Then no perf
> impact with uid.
Can you show me that part of the code? Because you seem to insist that en_US
would result in no translation.. I dare you.
> I know all this looks ugly. But IMHO this is "real politic", now 6.0 is
> supposed to be stable and changing methods API is no solution,
I'm talking about the same thing here. Changing the way the frameworks behaves
for a given set of input IS a change of API. Yes, sometimes the previous
behavior was not the best one (kept you seeing English strings that no Spanish
person understands, for example), but the rule is to improve things only "to
behave as expected". Getting translated strings from an empty context is not
what I would ever expect from the framework. (already gave you 2 examples
where this is the designed behavior).