[wp-hackers] i18n of plugin description

[Ryan Boren]

On Jan 24, 2008 9:27 AM, Ryan Boren <ryan at boren.nu> wrote:
> On Jan 24, 2008 9:09 AM, Stefano Aglietti <steagl4ml at gmail.com> wrote:
> > On Thu, 24 Jan 2008 08:04:25 -0800 (PST), wordpress at santosj.name
> > wrote:
> >
> >
> > >The commit team does not seem keen on that solution or any solution which
> > >involves hooks, and reloading of the plugin description. It will also have
> > >to not have any major refactoring of how the plugin system functions.
> >
> > Ryan proposed some solution time ago, if he could explain it again
> > here would be nice. Would be nice how they can immagine to solve this
> > problem...
>
> The proposals were pretty similar to what is being discussed here. One
> proposal leveraged gettext:
>
> Introduce a new file called plugin_name-header.php.  Contents are
> something like this:
>
> $description = __('blah blah blah', 'plugin_name');
> ... for other fields
>
> Or we would introduce some API methods instead of setting variables.
> Doesn't really matter.  The plugin_name part of plugin_name-header.php
> will be used as the textdomain.  WP loads the catalog for plugin_name
> and then loads plugin_name-header.php.
>
> Another proposal was to load plugin_name-lc_CC.txt files.  The file
> would contain the plugin header translated for lc_CC.
>
> The gettext method requires loading php files that might be broken,
> thus allowing a plugin to break the manage plugins page even if it
> isn't activated.  lc_CC.txt means lots of little files laying around
> in addition to the .mo files.  Either way, we will need to figure out
> how automatic upgrade of plugins will deal will locales.

Another proposal was to do it in the style of GNOME and KDE desktop files:

Description: In English
Description[es]: En Español

That can get pretty unwieldy though.