Localized values for plugin metadata

As the author of Gengo, I'm interested in this. If this was committed, how would plugin authors use it effectively? A short example plugin definition would be good.

Here is the new patch :) Theme headers now also support localizations. In addition some the code is cleaner and some common functions for parsing the theme/plugin headers are introduced.

The revised patch

@majelbstoat:

Just append [locale] after the header name and voilla, it is localized :)

Here is an example plugin header: /* Plugin Name: Bender, bender, where are you? Plugin Name[bg_BG]: Бендър, бендър, къде си? Plugin URI: http://bender.wow/ Plugin URI[bg_BG]: http://bg.bender.wow/ ... and so on */

Oops, I forgot the formatting ;) Here are the sampe headers again:

/*
Plugin Name: Bender, bender, where are you?
Plugin Name[bg_BG]: Бендър, бендър, къде си?
Plugin URI: http://bender.wow/
Plugin URI[bg_BG]: http://bg.bender.wow/
... and so on
*/

Even fo I agree on the ML discussion about this method now I think its a bit a mess, till now all localization was made (except for a couple of files like license.html and the distro themes) using language files, so localizing team didn't have to touch directly code of plugins etc.

This way we will have to touch code, and distribute locale versione of plugin distrubuted with WP, for other plugins if i do the italian version i ghave to send back tto author not only the language files but the plugin code too and he have to merge the header with my new additions and redistribute the files.. that sound a bit a mess :)

Actually i don't have any idea about an alternative method. A contorted one should be having a series of constant declaration at the top of the plugin code that will be gettexted so they will be included into the .pot file anc can be easily localized. Other Idea ?

All these plugins will have there own plugin localisation domain defined right? So how about something like this:

/* Plugin Name: Bender, bender, where are you? Plugin Name[bg_BG]: Бендър, бендър, къде си? Plugin Domain: testdomain */

$plugin_domain = 'testdomain'; // Or a constant, or however the plugin defines it. $plugin_meta[$plugin_domain][name] = ('Bender, bender, where are you?', $plugin_domain); $plugin_meta[$plugin_domain][uri] = ('http://bender.wow', $plugin_domain);

Then in the parsing code, if 'Plugin Domain:' is found, try to load $plugin_meta[$parsed_domain] name and uri, or fallback to the defaults parsed from the comments.

It does require a little bit of duplication on the plugin author's part, but it's backwards compatible and will still work if it's not supplied... And this way, the name and uri can just become part of the POT file...

I'd argue that a Plugin Domain would be a useful thing for a plugin to define anyway, something that uniquely references it... (or perhaps it could be autogenerated from a sanitised form of the plugin name?)

I'm not too keen on the proposed method, because it doesn't scale too well, as well as all the points raised by SteveAgl?.

Thoughts on this?

Forgot the code tags, d'oh. In the above example, the name and uri assignment statements should be double-underscored in case it isn't clear.

Holy crap, yo.

I think #4048 would suit well, since it would allow the plugin author to distribute the plugin themselves. The only problem with this method is that the plugin will appear in whatever language is in the top comments, then when the plugin is loaded, it will change.

If plugin is disabled, whatever appears in comments will be shown in that language. If plugin is enabled, plugin can overwrite display and display localized version of the text.

However, the activate text should still be in the admin's language, so that shouldn't be an issue.

Keeping the translations in the plugin/theme file doesn't sounds very reasonable to me now.

However, we can try and use the functions, which eliminate and structure the parsing code.

Implements gettext method for plugin metadata

As discussed on wp-hackers, the patch implements gettext method, but needs testing with plugin .mo file.

Second method will be implemented later.

Patch also has work on second method, which will only be displayed by calling the function directly.

__($description[1], $text_domain); 

You can't pass variables to (). Only literal strings. The plugin has to call () with literal strings for those strings to show up in the po file and thus end up in the mo file. With this method, we're loading a mo file that won't have the necessary strings in it.

We could make this work by having plugins call __() with the exact same string used in the header. This would get the string in the catalog. Within WP, we could use a new function in place of __() that does not result in the string ending up in the catalog. This will avoid having $description[1] in the po file.

Do we need Domain Path? In most plugins this is set dynamically based on the directory the plugin is in. We can derive the path from the location of the plugin.

I tested the patch submitted by darkdragon. It sort of worked. I fixed it up so that it worked for me.

Issues:

• Name, description, etc. needed to be trimmed before translation

• I got errors from the l10n.php file, because even if the plugin did not provide a text domain, and preg_replace returned false, the match array $text_domain was being set (at least on my test server, running PHP 5). So instead of checking to see if the $text_domain array has been set, I thought it was better to use the return value of preg_replace to see if translation should be done.

I'll attach the patch... this one works for me.

Alternate (I think better) patch that implements gettext method

The patch pollutes the WP catalog and doesn't address getting strings into the plugin catalog.

Let's see how this thread pans out:

http://comox.textdrive.com/pipermail/wp-hackers/2008-January/017409.html

Uses translate() instead and combines patch from jhodgdon

I believe this will be a nice addition to 2.5, since the other discussion won't be accepted in WordPress 2.5. In which case, the patch still needs to be tested and should not pollute the WP catalog like the other patch did.

The strings do still have to match exactly, which is an okay requirement.

Patch is based off r6666.

Combined #3089 completed patch, along with #5651 optimizations, with phpdoc and based off of r6666

Added patch which combines both #3089 and #5651.

IMHO, the get_ext_header() function from my second patch and the parsing abstraction could be useful even out of the i18n context.

There's more discussion on the hackers list this month:

http://comox.textdrive.com/pipermail/wp-hackers/2008-February/017642.html

(see also previous month mentioned above: http://comox.textdrive.com/pipermail/wp-hackers/2008-January/017409.html )

Moving to 2.6.

Feature freeze has arrived.

Here is a script, which adds the appropriate headers to the extension POT file:

http://svn.automattic.com/wordpress-i18n/tools/trunk/pot-ext-meta.php

I will work towards integration with the plugins infrastructure.