On Fri, Apr 6, 2012 at 09:18, Thomas Petazzoni
<address@hidden> wrote:
Le Thu, 5 Apr 2012 23:32:30 +0200,
> Wouldn't mocking _() work? I'm thinking this:
> - The function doesn't actually need to work to build the .po files.
> It just looks for _().
> - At the point where OCitySMap actually needs the translation,
> gettext will have been imported and overwritten the mocked _()
> - If in the former step the mocked _() persists in the instantiated
> class, some meta programming could replace the class's pointer to the
> mock _() with a pointer to the real function.
Yerk. I don't like this a lot, sounds really hackish to me and
complicated to understand. If you want to give a try at a
proof-of-concept, why not.
It's not the most clean solution, indeed. I was reminded of it by the way jQuery stores the $ object if it already exists and knowing Python allows for meta-programming as well.
As I said, I will be offline this week-end, and we would like to put
MapOSMatic in production next week. So unless someone steps up with a
reasonable and acceptable alternate solution during the week-end (and
by solution, I mean working patches, not some code skeleton in an
e-mail), I'm going to commit my proposal (of course in the future, we
can always revert it and implement a better solution).
That is, I think, the best course of action.
Given that your suggestion will definitely work, I'll put this idea on
the back burner. I'm not particularly attached to the idea as it is,
just came up with it because of the symmetry of keeping the gettext
objects where they're defined.
I am definitely not going to delay the production deployment of
MapOSMatic because of this. The features in the new version of
MapOSMatic have been implemented initially in August 2010, it's more
than time to deploy them in production.
Am looking forward to it, as well as the LWN announcement, which is how I found the project back then.
Best regards,
Jeroen