[wp-hackers] Internationalizing Plugins and Themes Solutions
skeltoac at gmail.com
Fri Mar 7 00:24:17 GMT 2008
On Thu, Mar 6, 2008 at 7:24 AM, Jacob Santos <wordpress at santosj.name> wrote:
> Solution #3: Use WP based tool for translating the plugin metadata while
> in the comment and create a .pot file from that.
I like this one.
> Advantages: Any plugin that is added to the WordPress Plugin Repository,
> will immediately have translated metadata for which any number of
> translators can upload translations for. Will also allow for users to
> download plugin in their language.
> Disadvantages: While those Plugins on the WordPress Repository will be
> helped out a great deal, those that exist outside will not. The tool is
> not something that a novice will be able to wrap their mind around.
> Creating a web interface will be an advantage, but getting the word out
> about the tool might not reach everyone. Also, they will still have to
> set up a system like what the WordPress Extend has anyway to support
> multiple languages. How many will do that?
Getting the word out is not a problem. We have many places to document
its existence and make it findable via Google.
Any plugin or theme not hosted on Extend will likewise not have its
translations hosted on Extend.
> I think Solution #3 is very cool for the WordPress extend. However, I
> have no idea where it is in that set of tools that you have what you
> propose. It is very clean code, but I can't see where it is taking the
> metadata and translating it. If the assumption was that it would be
> written, if more people liked the idea, then I'll have to say that for
> WordPress extend it would be cool.
It would be written.
> So one person pointed out the obvious, the old style isn't going away. I
> think that Solution #3 also has other disadvantages which would need to
> be applied to the code.
That's right, it's not going away. What other disadvantages?
> The first two are very quick and dirty methods requiring only gettext.
> What is fascinating about the first two, is that if someone was to code
> for both, it would allow for the first to work (if and only if the
> metadata was copied exactly). I think the problem then is checking every
> file for register_plugin() / register_theme() in order to see which file
> holds the function, extract that out, along with the
> load_plugin_textdomain() (if it exists) and run those both through
> eval(). I suppose, if metadata.php does exist and it only has those two
> in the file, that it can just be included and ran, but if it had any
> other arbitrary code, that it would have to be dismissed and run through
Faced with such complexity, one should look upon the third option with
> I'm willing to put forth the effort, hopefully if I can find time, this
> weekend to retest the #1 solution and implement the #2 solution. In
> which case, it would be either up in the air whether to support both
> solutions or to support one or the other. As well, both would answer the
> question of translating the metadata without the required use of an 3rd
> party tool.
I hope you will see that the solution requiring the least effort and
providing the most utility is the third option. I hope that you will
write the few lines of shell script to extract metadata lines from
plugins and stylesheets and add them to a .pot file. I hope that you
will wrap this in a PHP script and make it available to the public.
A bounty for the person who completes this meager task: you write it,
you host it, you get a ton of backlinks.
More information about the wp-hackers