My suggestion to improve osclass and avoid a lot of bugs and increase its popularity is to rewrite the translation related class so that there are no more .po and .mo files.
There is a ready-made solution on elggsite, it is multilingual and easily translated using an array.
return array(
'item:object:blog' => 'Blog',
'collection:object:blog' => 'Blogs',
'collection:object:blog:all' => 'All site blogs',
'collection:object:blog:owner' => '%s\'s blogs',
'collection:object:blog:group' => 'Group blogs',
'collection:object:blog:friends' => 'Friends\' blogs',
'add:object:blog' => 'Add blog post',
'edit:object:blog' => 'Edit blog post',
'notification:object:blog:publish' => "Send a notification when a blog is published",
'notifications:mute:object:blog' => "about the blog '%s'",
);
Server-side API
elgg_echo($key, $args, $language)
Output the translation of the key in the current language.
Example:
echo elgg_echo('example:text');
It also supports variable replacement using vsprintf syntax:
// 'welcome' => 'Welcome to %s, %s!'
echo elgg_echo('welcome', [
elgg_get_config('sitename'),
elgg_get_logged_in_user_entity()->getDisplayName(),
]);
To force which language should be used for translation, set the third parameter:
echo elgg_echo('welcome', [], $user->language);
To first test whether elgg_echo() can find a translation:
$key = 'key:that:might:not:exist';
if (!elgg_language_key_exists($key)) {
$key = 'fallback:key';
}
echo elgg_echo($key);
Note
Some APIs allow creating translations for new keys. Translators should always include an English translation as a fallback. This makes elgg_language_key_exists($key) a reliable way to predict whether elgg_echo($key) will succeed.
Javascript API
i18n.echo(key, args)
This function is like elgg_echo in PHP.
Client-side translations are loaded asynchronously. Ensure translations are available by requiring the “elgg” AMD module:
define(['elgg/i18n'], function(i18n) {
alert(i18n.echo('my_key'));
});