I’ve been poking around on StatusNet’s i18n to see if we can get localizations working with less fidgeting; all languages should “just work” when you drop in your StatusNet install.
We’re loading translations using gettext, which unfortunately can only load translations for languages which are set up as locales system-wide. This is massively problematic and has lead to localization just plain not working for most people — it’s even broken on identi.ca!
The good news is that we already have a compatibility layer that doesn’t have this limitation: php-gettext, which provides source-compatible drop-in gettext interface in pure PHP.
The bad news is that if the native gettext module *is* present, there doesn’t seem to be any way to override calls to _() — PHP has no facility for monkeypatching to replace existing functions. So, to force use of the compat functions for unsupported locales we’d need to change all calls to a new name.
Any preferences between something short and cryptic like __() or something clearer and StatusNet-y like common_msg()?
This is also a good time to think about handling localization for plugins; currently the plugins that ship with StatusNet’s source just have their localizations lumped into StatusNet’s main file — that obviously won’t do for plugins that are maintained and distributed separately.
In the gettext model it looks like the way to handle this is to use multiple “domains”; StatusNet’s core domain is “statusnet” (duh) and set as the default domain for gettext calls. A plugin can bind its own locale subdirectory to another domain (say “ldapplugin”) and instead of calling _(“Some text”) can call dgettext(“ldapplugin”, “Some text”).
This could perhaps be simplified by adding helper methods onto the Plugin base class…
$this->_("blah")
Thoughts?
Updated 2009-10-16: I seem to be able to work around the locale setup problem by setting a valid locale before setting the invalid one. :P That should hold us for a while before we try larger changes.
Cross-posted w/ StatusNet-Dev mailing list.
Do what WordPress does – that way, an existing extremely large developer community can easily adapt their skills and habits to work on StatusNet-related projects. So, go with
__(). Also, handle the domains like WordPress does too –__( 'some text', 'my-domain' ).wfMsg(), duh :)
Can do something like …
namespace Foo
{
function _()
{
echo ‘Hello World!’, “\n”;
}
class T
{
function run()
{
_();
}
}
}
in 5.3, also $_(“blah”), of course, to get rid of the $this-> clutter.