[wp-hackers] Improvements to the WordPress l10n framework

[Liron Newman]

Hi everyone,


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


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?