[wp-hackers] Improvements to the WordPress l10n framework
wphackers at jamietalbot.com
Sun May 13 05:02:34 GMT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Omry Yadan wrote:
> Nikolay Bachiyski wrote:
>> 2007/5/12, Omry Yadan <omry at yadan.net>:
>>> the idea is the code that initializes the plugins initialize a global
>>> called $plugin_id before calling the plugin init code.
>>> when the plugin adds an action, it will pass that global to the
>>> add_action function, that will use it to re-obtain context when calling
>>> the actions.
>> We cannot do this. What happens if the plugin function calls a core
>> function and then it calls other plugin function? It is possible that
>> either core strings are being searched for in the plugin domain or,
>> worse, one plugin\s string is being looked for in other plugin's
> Good point.
> it can be solved (I think) by using a stack.
> instead of setting and unsetting the current plugin_id, push it and pop
> it from a global stack.
Now that I've seen some code and understand how context will be retained, this isn't necessarily a
bad idea. You are of course, swapping the need to specify a domain on each string to specifying a
domain on each filter/action, but in the majority of cases there will be a lot fewer. If a
stack-based implementation can be worked out, this might work well - I suspect this will be more
difficult than it sounds, however. And, instead of using a speculative plugin domain, why not let
plugin authors decide their own? The suggestion I made on Trac for specifying a plugin domain in
the plugin header would be ideal for this.
Your mechanism of adding domains to filters would also incidentally allow improvements to did_action
which I'd really like to see, but which we have no current way of doing. In fact, it's exactly what
I wished we already had!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the wp-hackers