[wp-hackers] i18n of plugin description

[wordpress at santosj.name]

Hmm, your explanation makes a lot of sense. Seems awfully hackish though
(but I can get over it), but I'll see about implementing your idea. I will
also see about implementing the others, so that people can see which idea
is the "best" and choose for theirselves. I don't want to shun the other
ideas, because sometimes it is easier to just add the locale information
in a non-mo file.

In my experience, it seems very difficult to create .mo files and the
steps required are quite painful.

There will still need to be an optional extra header, for the directory of
the plugin text domain. Another issue is that you would have to add a
function which plugins can call to see if their plugin textdomain has
already been included. It could be assumed that the plugin textdomain is
the base plugin folder, however, the plugin_textdomain allows for choosing
the folder, so it will have to be supported in the plugin data also.

I think of the ideas, for those plugins that have translated (.mo) files,
it makes sense for them to use your method. For a simple plugin, it might
make more sense to use the other methods.

Your idea is a lot more simple, so I'm going to implement it first. Are
you willing to test the implementation?

Jacob Santos

> One thing to consider is that locales are very very specific and there
> are a zillion of them. For instance, if you specify you have a
> description for en_EN, someone who uses locale en_US or en_CA could
> certainly read that description. Then again, for some languages, maybe
> the locale is important for understanding. The plugin author should
> not have to make a list of all possible locales for matching.
>
> Given that, I don't like any of the suggestions so far proposed for
> providing descriptions in different languages. In my opinion, the
> matching scheme should somehow tie in to the POT/PO/MO/gettext
> internationalization scheme, not rely on matching the person's exact
> locale setting with a locale the plugin author decided to include a
> description for.
>
> One possibility that could possibly be made to work is to put
> something like this into the plugin header:
>
> /* Plugin Name: ...
>     Description: Plugin to save the world
>     (rest of header)
> */
>
> $myplugin_desc = __( "Plugin to save the world" );
>
> Now, the plugin description (as long as it is typed carefully the same
> in two spots) is part of the gettext scheme, and will be translated
> whenever the plugin is translated. The plugin listing page in the
> admin screen could try running the description through gettext before
> displaying it, and if that string has been translated in the MO file,
> it would get displayed in the user's preferred language.
>
> How about that? The main pitfall would be that you have to remember,
> if you edit the description in the header, to put the same description
> into the $desc variable, so they stay in sync.
>
>      --Jennifer
>
> --
> Jennifer Hodgdon
>
> Poplar ProductivityWare * www.poplarware.com
> Web Databases/Scripts * Modeling/Analysis/Palm OS Software
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>