[wp-hackers] load_plugin_textdomain()

[Xavier Borderie]

> This has been discussed before, and rejected by a few, but I'd like to beat this dead horse again...

Oops, sorry, wasn't aware of that, joined only recently, intermittent
lurker before that.
I guess the important change between now and last time is that WP now
features a full-on plugin notification (and even update) process,
which could hopefully be piggy-backed on.

> But the end-user of that pluign has a different take on the topic, because the failure
> will happen right at the time they upgrade WordPress, not the plugin.
> So to them, it's WordPress's fault, not the plugin's or the plugin-author's.

Exactly. With the current path of deprecating "in the dark" (at least
to lambda users), the bucket stops at WordPress' developers, and we
can easily guess their thinking: "darn it, wordpress X.X breaks my
most useful plugin!", even though wp-devs spent 5 months warning
plugin-devs of the change.
With proper and timely warning, the bucket is passed onto either the
plugin author ("darn it, I must warn this lazy bum to update his
defective code before the next release") or the user himself ("darn
it, i should have been looking for a fix/alternative months ago").
Users would even KNOW which plugins might break with the next major
version, which is a feat in itself :)

I really hope this dead horse is not buried too deep ;-)

***

Expanding on this idea even further (hey, we can dream, right? :) )...
If this could be implemented on wp.org/ext/plugins, this could make
hand-made compatibility lists such as
http://codex.wordpress.org/Plugins/Plugin_Compatibility/2.6 completely
automatic. Same result for /themes (which is poised the central themes
repository, as is /pugins for plugins, yadda yadda...) and
http://codex.wordpress.org/Themes/Theme_Compatibility/2.6 .

Really, I think having such a functionality could only be a
win-win-win for wp-devs, plugin-devs and wp-users :)

-- 
Xavier Borderie