[wp-hackers] Improving Plugin (and Theme) metadata

Peter Westwood peter.westwood at ftwr.co.uk
Fri Jan 25 08:44:40 GMT 2008

Hash: SHA1

Stephen Rider wrote:
| On Jan 24, 2008, at 4:17 PM, Peter Westwood wrote:
|> Example metadata.php file:
|> <?php
|> load_plugin_textdomain();
|> register_plugin( plugin_filename.php,
|> ~                 __('Description'),
|> ~                 __('Plugin Name'),
|> ~                'http://example.com',
|> ~                'Joe Bloggs',
|> ~                 'http://joe.bloggs.name'),);
|> //The End
|> ?>
|> What do people think?
| I don't think it's necessary to put all this complexity into the plugins
| themselves!
| Look, we could leave the metadata exactly where and as it is, with one
| addition:
| Text Domain: myplugin
| The additional functionality should be added _once_, in core, instead of
| in each plugin.  Doing this will avoid issues of having to "upgrade"
| plugins.  In the core function that parses the Metadata, it would look
| for the presence of the "Text Domain" string.  If present, it would load
| that text domain, and then pass each meta string through __() with that
| domain.
| A few lines of code in core, one line added to plugins following the new
| system, and NO incompatibilities with older plugins.
| What's not to like?

The main issue here is that the strings will not make it into the
plugins catalogue file automatically - the php file is parsed looking
for the __() calls and the string passed in makes it to the catalogue file.

It would also mean without adding a new translation function in the core
for these strings the variable names will end up in the WordPress
catalogue file.

- --
Peter Westwood
http://blog.ftwr.co.uk | http://westi.wordpress.com
~ C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the wp-hackers mailing list