[wp-hackers] Improvements to the WordPress l10n framework

[Jamie Talbot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Liron Newman wrote:
> 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!

Hi and welcome :)

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

Why not?  A simple macro in your favourite code editor (assuming it's not notepad) can insert this
automatically.  At worst it's just copy and paste.

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

What is this pluginDomain determined from?

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

I'm a bit confused with how this will work.  How will you determine what $pluginDomain to check if
it has been unset?  How will you know which $pluginDomain to look in if there are multiple localised
plugins?  This also seems pretty slow because it means first checking the default domain, then
checking another domain (or lots of other domains).


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

It could probably be made to work, but like you say, it's a bit prone to failure, is pretty slow and
in any case is only available for PHP 4.3+, while WordPress requirements state 4.2.

> So, what do you say?

I'm not convinced that the current system needs any changing.  It's not too much of a stretch to
require a domain for each string.  It allows a single, simple lookup when outputting.  It helps
group translations from one theme or plugin logically.  All in all, theme and plugin authors should
just code properly.  If they don't localise properly, it won't work.  That doesn't seem unfair.  In
my opinion, we just need to educate authors better.

Cheers,

Jamie.

- --
http://jamietalbot.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGRGOrrovxfShShFARAieiAJ9J12OpbuZhrtWXFg0UH+4yeEgMpACcDOM4
H5/nj8kgDJjLggGo6K2ATGI=
=SI4N
-----END PGP SIGNATURE-----