[wp-hackers] Internationalizing Plugins and Themes Solutions

[Jacob Santos]

My main focus on the discussion is the plugin part, while ignoring the 
theme part. I think the central issue, is not which method is the best, 
but which one is the easiest. If someone finds adding comments to a PHP 
or CSS file to get the plugin or theme up and running, I don't think 
that the PHP method and the WP-Tools method will help the developer.

Of course, if you are going to make the WP translation tools part of the 
plugin/theme repository, then good for you. However, I for one will say 
that is quite unfair. It is unfair to those of us who tried to fix the 
issue with the current working method and it is unfair to those of us 
who would very much like the new method.

I think you could also use the phpDoc method:

/**
 * @plugin-name Something
 * @plugin-author Jacob Santos <wordpress at santosj dotname> 
http://www.example.com
 * @plugin-url http://wordpress.org/extend/plugin/
 * @plugin-description whatever
 */

I'm kidding of course.

What issue is with the metadata now?

Problem: You can't translate something in comments.
Solution: Either move the metadata out of the comments or allow what is 
in the comment to be translated.

Solution #1: Extend the current metadata comment to add a couple more 
properties to control translating and have a hack which forces __() 
usage in a function which does nothing.

Advantages: Uses current method, which is unlikely to be deprecated any 
time soon or at least will not be removed in any foreseeable future.

Disadvantages: Relies on a hack to get gettext solution to see 
translatable text.


Solution #2: Use Westi's proposal, to create function + optional file, 
which moves the metadata out of the PHP comment into a function which 
can be translated. This removes the comment metadata problem and the 
hack is no more. This is a more clean solution, than the first.

Advantages: Cleaner PHP code, removes untranslatable metadata comment, 
creates another file which if it exists will allow including that for 
just the metadata (and for other features if and when they are also added).

Disadvantages: Security precautions need to be made, but including the 
entire optional file may cause allow for malicious code to run without 
activating the plugin code. PHP code would have to be cut out of the 
file regardless of which file it is in and run through eval(). eval() 
might be disabled (for known security problems) on some hosts meaning 
that all plugins relying on this method will not work or run the risk of 
executing code which the user does not wish to run before activation.

Solution #3: Use WP based tool for translating the plugin metadata while 
in the comment and create a .pot file from that.

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?

-----------

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.

So basically out of the three, only one has a finished solution. Out of 
the three, the second would work best for plugins, while the third would 
work best for themes unless you start checking for the register_theme() 
in the functions.php file. I think, that is a good solution for themes, 
but it would mean that every theme would have to have a functions.php 
file along with index.php and style.css (for backwards compatibility).

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.

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

I know for a fact, that a lot of the cheaper hosts disable eval() along 
with shell() and friends. If you wanted to do it securely, then you 
would have to only execute that code. The speed doesn't so much matter 
since it is only one page on the administration.

The point I'm trying to make is that sometimes, you don't want to have 
to use a tool you don't need or always have access to. I want to just 
code register_plugin() with the __(). Also, from what I interpreted of 
the February Nikolay post is that it would also depend on translating 
the English text and would only add the English to a .pot file, which 
would require the modifications in #1 anyway.

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.

-- 

Jacob Santos

http://www.santosj.name - blog
http://funcdoc.wordpress.com - WordPress Documentation Blog/Guide Licensed under GPLv2

Also known as darkdragon and santosj on WP trac.