[wp-hackers] Improvements to the WordPress l10n framework
plastish at ultinet.org
Fri May 11 10:32:06 GMT 2007
First of all, let me open by saying that I'm pretty new to WP
development and I don't really know the internals very well (This is why
I'm consulting this list), so I might have mistakes among my
assumptions. Please correct me if I do!
The current situation of WP l10n for plugins is that they may use
load_plugin_textdomain("mydomain") and then use
__("mystring","mydomain"), or _e() with the same syntax, for every
interface string (Strings that are shown to the user, need to be
translated). From what I've seen, many (Most?) plugins don't use this
option, or use it erroneously.
For example, in the Sidebar Widgets plugin, you see many instances of
these functions being used without specifying a textdomain. This mistake
also repeats itself in a few other plugins I saw, not to mention the
ones that don't use l10n at all.
The thing I want to avoid here is the "disease" that I see now, in the
Hebrew WP community, where plugins that are otherwise perfectly fine get
"Hebrew versions" that are just translations, and not other
locale-specific fixes, things that can be avoided if plugin authors
would properly support l10n, and the way I see it, that would only
happen if the framework would support it better. The situation now
creates unneeded branches in the code, and that's bad, especially when
it comes to updates and upgrades.
>From what I've seen in other systems, and from my own development
experience, I got to the conclusion that the process of making your
plugin l10n-enabled should be simplified for developers. Wrapping your
strings with __() is easy, but if you need to start specifying your
domain every line, you're not going to do it. So this is where I ask
you: How can this be done? Omry Yadan suggested this process (roughly):
Plugin init loop:
1. When each plugin is initialized, its directory is searched for a
translation file for the current locale. If it exists, it is loaded
under the plugin name's textdomain. A global variable (Say,
$pluginDomain) for the current plugin's domain is set.
2. The plugin is initialized.
3. $pluginDomain is unset.
When __() or _e() are called, if a string is not found in the default
textdomain, they try to match the string to the textdomain named in
$pluginDomain. That will also be backwards-compatible if current plugins
intentionally don't name a domain to get the default.
The problem with this mode of operation is that it also requires
$pluginDomain to be set before calling any of the plugins functions,
either by hooks, by user code (In a template) or whatever, and that's
something I'm not sure how to do, or if it's even possible with the way
The other option I considered, and is really patchy, is using PHP's
debug_backtrace() to find the file that called __() or _e() and choosing
a textdomain using that (Again, only if the string isn't found, etc.),
but as I said, it's really patchy and ugly and probably bad for
performance (Not that I checked it or anything - but debug functions are
usually bad for production code).
So, what do you say?
More information about the wp-hackers