[wp-hackers] Internationalizing Plugins and Themes Solutions

[Andy Skelton]

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.

Yes.

>  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
>  eval().

Faced with such complexity, one should look upon the third option with
great relief.

>  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.

Cheers,
Andy