[wp-hackers] Improving Plugin (and Theme) metadata
peter.westwood at ftwr.co.uk
Fri Jan 25 08:44:40 GMT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Stephen Rider wrote:
| On Jan 24, 2008, at 4:17 PM, Peter Westwood wrote:
|> Example metadata.php file:
|> 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
| Look, we could leave the metadata exactly where and as it is, with one
| 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
| 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
http://blog.ftwr.co.uk | http://westi.wordpress.com
~ C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the wp-hackers