[wp-hackers] Internationalizing Plugins and Themes Solutions
wordpress at santosj.name
Thu Mar 6 13:24:42 GMT 2008
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>
* @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
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
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
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.
More information about the wp-hackers