Ticket #3089 (new enhancement)

Opened 2 years ago

Last modified 4 weeks ago

Localized values for plugin metadata

Reported by: nbachiyski Assigned to: ryan
Priority: normal Milestone: 2.6
Component: i18n Version:
Severity: normal Keywords: has-patch needs-testing phpdoc
Cc:

Description

As Ryan suggested the way in a mail to wp-polyglots here is an impelmentation of the freedesktop.org standard for wordpress plugins.

Unfortunately the same system for themes is not ready yet. The moment I find some time it will be shipped also.

NOTE: the functions contain phpdoc, which could be removed if not needed.

Attachments

localized-keys-in-plugins.diff (6.2 kB) - added by nbachiyski on 09/01/06 01:23:38.
localized-headers-in-exts.diff (9.3 kB) - added by nbachiyski on 09/01/06 12:00:36.
The revised patch
3089.patch1.diff (1.6 kB) - added by darkdragon on 01/24/08 18:35:13.
Implements gettext method for plugin metadata
plugin_new.diff (1.8 kB) - added by jhodgdon on 01/24/08 22:01:25.
Alternate (I think better) patch that implements gettext method
3089.patch2.diff (1.1 kB) - added by darkdragon on 01/26/08 05:13:47.
Uses translate() instead and combines patch from jhodgdon
3089.5651.patch.diff (5.4 kB) - added by darkdragon on 01/26/08 05:55:09.
Combined #3089 completed patch, along with #5651 optimizations, with phpdoc and based off of r6666

Change History

09/01/06 01:23:38 changed by nbachiyski

  • attachment localized-keys-in-plugins.diff added.

09/01/06 11:57:31 changed by majelbstoat

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.

09/01/06 11:59:40 changed by nbachiyski

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.

09/01/06 12:00:36 changed by nbachiyski

  • attachment localized-headers-in-exts.diff added.

The revised patch

09/01/06 12:05:32 changed by nbachiyski

@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 */

09/01/06 12:13:12 changed by nbachiyski

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
*/

09/02/06 21:49:33 changed by ryan

  • owner changed from anonymous to ryan.

09/21/06 13:23:23 changed by SteveAgl

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 ?

12/01/06 03:31:01 changed by matt

  • milestone changed from 2.1 to 2.2.

01/07/07 05:35:01 changed by majelbstoat

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?

01/07/07 05:37:22 changed by majelbstoat

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.

03/27/07 22:34:21 changed by foolswisdom

  • keywords changed from bg|commit bg|needs-testing to has-patch needs-testing.
  • milestone changed from 2.2 to 2.3.

09/12/07 01:04:53 changed by ryan

  • milestone changed from 2.3 to 2.4 (next).

12/20/07 06:41:01 changed by darkdragon

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.

12/27/07 21:55:44 changed by santosj

  • component changed from General to i18n.

01/03/08 10:54:02 changed by nbachiyski

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.

01/24/08 18:35:13 changed by darkdragon

  • attachment 3089.patch1.diff added.

Implements gettext method for plugin metadata

01/24/08 18:36:26 changed by darkdragon

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

Second method will be implemented later.

01/24/08 18:37:34 changed by darkdragon

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

01/24/08 20:21:43 changed by ryan

__($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.

01/24/08 20:38:12 changed by ryan

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.

01/24/08 22:00:40 changed by jhodgdon

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.

01/24/08 22:01:25 changed by jhodgdon

  • attachment plugin_new.diff added.

Alternate (I think better) patch that implements gettext method

01/24/08 22:59:05 changed by ryan

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

01/26/08 05:13:47 changed by darkdragon

  • attachment 3089.patch2.diff added.

Uses translate() instead and combines patch from jhodgdon

01/26/08 05:15:37 changed by darkdragon

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.

01/26/08 05:15:56 changed by darkdragon

Patch is based off r6666.

01/26/08 05:55:09 changed by darkdragon

  • attachment 3089.5651.patch.diff added.

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

01/26/08 05:55:37 changed by darkdragon

  • keywords changed from has-patch needs-testing to has-patch needs-testing phpdoc.

01/26/08 05:56:07 changed by darkdragon

Added patch which combines both #3089 and #5651.

02/08/08 07:31:43 changed by nbachiyski

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

02/08/08 18:18:55 changed by jhodgdon

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 )

02/16/08 15:36:03 changed by westi

  • milestone changed from 2.5 to 2.6.

Moving to 2.6.

Feature freeze has arrived.

04/22/08 19:11:49 changed by nbachiyski

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.