[wp-hackers] Improvements to the WordPress l10n framework

[Liang Jin]

Hi, Jamie

I agree with you, that the current localization scheme is working as
expected. But we do need to educate the authors to properly set the
plugin domain correctly. I have spend many hours converting some
plugins or themes into domain based format. The fundamental reason is
that most authors use English on their blogs, and they would not test
the translation before releasing it. If the plugin author use
__("something"), it means he is making an effort in the right
direction, but may not know that it would be better to specify the
plugin domain.

Anyway, one area that DOES need improvement in the current WordPress
core is the way it searches and outputs the plugin names and
descriptions. Currently it is ENGLISH-ONLY. There is no way to
translate it.

I am thinking that we can probably do something like this:
1. to allow backwards compatibility, still search the strings in the
comment area for author and plugin information. (but this is English
only)

2. use a filter to replace the plugin or theme meta information.
Something like the following:


/*
Plugin Name: Anything
*/

add_filter('localization_plugin_meta', 'replace_plugin_name')

function replace_plugin_name() {
    plugins['Anything']['name'] = __('Anything','anything');
}


What are your opinions?

Best,

-Liang



On 5/11/07, Jamie Talbot <wphackers at jamietalbot.com> wrote:
> -----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-----
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>