I've been poking around on our 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?
-- brion vibber (brion @ status.net)
_______________________________________________
StatusNet-dev mailing list
StatusNet-dev@lists.status.net
http://lists.status.net/mailman/listinfo/statusnet-dev
