[wp-hackers] Improvements to the WordPress l10n framework

[Omry Yadan]

>
> Using a stack we can only reassure we are not in the wrong plugin.
> However we cannot intercept the switch between a plugin and the core.
> Here is an example:
> wp-content/plugins/our.php:
>    function f() {
>        ....
>        $x = comments_number();
>        ....
>    }
>
> In the comments_number function there are some i18n-ed strings and we
> expect their translations to be taken from the default domain. However
> the current context will point us to our plugin and the translation
> will be searched for in its domain, not in the default.
>
> In most of the cases we can solve this problem by searching not only
> in the plugin namespace, but on failure -- also in the default one. Of
> course, this will work only if we are sure that one string has the
> same translation everywhere.


Well, I can claim this is a feature that allow plugins to override core 
translations in while their context. :)
in any case, I fully agree that the search should fallback to the core 
on failure, something like:

function __($s)
{
    global $plugin_id;
    if (isset($plugin_id))
    {
       $t = old__($s, $plugin_id);
       if (empty($t)) $t = old__($s);
       return $t;
    }
    else
    {
       return old__($s);
    }
}