[wp-hackers] load_plugin_textdomain()

[Jacob Santos]

It should be pointed out that users already have the power to check 
whether or not plugins and themes use deprecated code with WordPress 
2.5+. All they have to do is add

define('WP_DEBUG', true);

to their wp-config.php file and they are done. If a plugin or theme uses 
deprecated functions, then an unfriendly message will appear telling the 
user that something is using a deprecated function. The usefulness of it 
ends there, but you could build a plugin, which goes down further and 
checks which file the deprecated function is being called in.

Also, a simple search through all of the plugin and theme files should 
also turn up where it is, if a plugin is not a viable solution.

Developers also have this same capability. It is hidden, but it exists 
well within WordPress. The best part is that it exists already and can 
be used now.

Jacob Santos

Xavier Borderie wrote:
>> 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 :)
>
>