Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo

i18n and 2.2.0-rc3 weirdness

Go to End

4 Posts   1365 Views


Community Member, 21 Posts

25 November 2007 at 2:42pm

Edited: 25/11/2007 3:34pm


I've stumbled into something very weird.

I've translated the SS in my site (local), and, ofc, i made some mistakes around it (like Ingo already stated in another post) like translating the help strings used to inform the translator about the context etc, but, the thing is, everything as far as i've seen when testing it, was working correctly.

Then, the language was imported into, i revised, making some minor changes, but all was going ok. Time to test the translate site generated files, i cleaned my instalation made a fresh install (deleted the dir, untared the 2.2.0-rc3, ran install), downloaded the 3 pt_PT.php files from translate site, copied them to the correct place, changed sapphire/_config.php to set the language to pt_PT then logged in into the CMS, to see that several things weren't translated, basically i hade pt_PT mixed with english, so, i went to figure out what's going on.

I've checked in the source several situations where the string is i18n (was using _t() ) and it was present in the language file, example: 'LeftAndMain.VIEWPAGEIN', still in the CMS the text was in english.

I've tried everything, rebuild the DB, always flush=1 on the CMS reloads, if i change the en_US string, it works, the pt_PT string is completely ignored.

I tried to poke around a bit more, and added a few more translations that were missing in the source, like in the NewsletterAdmin.php, and here's what happened (it's a bit hard to explain so i'll just try to illustrate all with code snippets and be very thorough as possible)

I tried to translate the tab names of the Mailing List on a new Newsletter, the strings are:
Recipients, Import, Unsubscribers, Bounced

I found the strings in the function getMailingListEditForm() on NewsletterAdmin.php in the constructions of a new Tabset, so i proceeded to the change, resulting on the following code (note, i've not included all irrelevant and unchanged text)

new Tabset("Root",
    new Tab(_t('NewsletterAdmin.RECIPIENTSTAB', 'Recipients'), ...),
    new Tab(_t('NewsletterAdmin.IMPORTTAB', 'Import'), ...),
    new Tab(_t('NewsletterAdmin.UNSUBSCRIBERSTAB', 'Unsubscribers'), ...),
    new Tab(_t('NewsletterAdmin.BOUNCEDTAB', 'Bounced'), ...)

Then, i added the correspondent string to both en_US.php and pt_PT.php files

$lang['en_US']['NewsletterAdmin']['RECIPIENTSTAB'] = 'Recipients';
$lang['en_US']['NewsletterAdmin']['IMPORTTAB'] = 'Import';
$lang['en_US']['NewsletterAdmin']['UNSUBSCRIBERSTAB'] = 'Unsubscribers';
$lang['en_US']['NewsletterAdmin']['BOUNCEDTAB'] = 'Bounced';

$lang['pt_PT']['NewsletterAdmin']['RECIPIENTSTAB'] = 'Destinatários';
$lang['pt_PT']['NewsletterAdmin']['IMPORTTAB'] = 'Importar';
$lang['pt_PT']['NewsletterAdmin']['UNSUBSCRIBERSTAB'] = 'Assinaturas Removidas';
$lang['pt_PT']['NewsletterAdmin']['BOUNCEDTAB'] = 'Devolvidos';

Just to be sure, did a db/build, reloaded interface with flush=1 and to my surprise only the Recipients text was translated.

Then, just to make sure it was nothing i screwed up, i changed NewsletterAdmin.php to:

new Tabset("Root",
    new Tab('Recipients', ...),
    new Tab(_t('NewsletterAdmin.IMPORTTAB', 'Import'), ...),
    new Tab(_t('NewsletterAdmin.UNSUBSCRIBERSTAB', 'Unsubscribers'), ...),
    new Tab(_t('NewsletterAdmin.BOUNCEDTAB', 'Bounced'), ...)

Did again the usual stuff, db/build, reload with flush set, surprise, the remaining tabs were translated, except the obvious one which i removed the translation (Recipients).

Everytime i changed the Recipients text to _t(...) the other tabs returned to english.

I don't know enough of SS to debug this properly without loosing alot of time which unfortunately i can't at the given time.

Is this a known bug ? new ? anything i can do to help ?

Btw, my instalation is the most permissive of all, debian etch default install with apache2/php5/mysql all latest and updated etc. not installed as a virtual host.

Best regards,

After a bit more of testing, it seems this happens to every language.
Did some debug on the _t function in Core.php and the translated string are being overlapped by en_US

just adding a syslog(ERR_LOG, $lang[$locale]['']['VIEWPAGEIN']); in function _t() showed:

... ... apache2: Vista da Página:
... ... last message repeated 52 times
... ... apache2: Page View:
... ... last message repeated 145 times

It seems along the way the translated text get's overriden by en_US, haven't found nothing more yet.

BTW, there is no readon at all to use i18n:get_locale() so much in _t() and specially when there is already a var set with it right on the start ($locale), changing:

$transEntity = isset($lang[i18n.:get_locale()][$class][$realEntity]) ? $lang[i18n::get_locale()][$class][$realEntity] : $string;


$transEntity = isset($lang[$locale][$class][$realEntity]) ? $lang[$locale][$class][$realEntity] : $string;

spares 2 useless function calls, this alone will not make a major speed increase noticeable but if we get alot of this in the code am sure the CMS will be quite slow when it could be faster.

Another example is the usage of " " in every text that does not require to parse any variable, using ' ' instead also increases slightly the speed of the string handling in PHP as it won't even try to search for a variable in it's content to parse.

Best regards,


Forum Moderator, 801 Posts

26 November 2007 at 8:05am

hey there,

thanks for your research and detailed bug report! we are aware of this problem and filed a ticket for it last week ( unfortunately we didn't have ressources to fix this problem for the 2.2.0rc3 release - it might need to wait until 2.2.1.

i've made a ticket for your performance improvement suggestion as well:

cheers for your contribution (portugues translation)!


Community Member, 21 Posts

26 November 2007 at 8:39am

Hello Ingo,

Always glad to help, i'll try to investigate a little bit further on my spare time, i'd really like to have tis fixed on 2.2.0 release, of course as i have personal interest in it (personal work, deploying a client site) and there are still alot of strings that need to be translated (Newsletter for example) and i'd really love to see 2.2.0 if not completely at least the most important translated (the string we often see un the UI).

I'll keep you posted,

Best regards,


Community Member, 21 Posts

26 November 2007 at 10:18am


Found the bug, posted the bug and an eventual temporary solution in the trac

Forgive me the crappy formatting in the post, i assumed trac would make a line break on returns, if possible can you fix it Ingo.

Best regards,