Jump to:

17452 Posts in 4473 Topics by 1971 members

Archive

SilverStripe Forums » Archive » i18n and 2.2.0-rc3 weirdness

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

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

Page: 1
Go to End
Author Topic: 1086 Views
  • rbarreiros
    Avatar
    Community Member
    21 Posts

    i18n and 2.2.0-rc3 weirdness Link to this post

    Hello,

    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 translate.silverstripe.com, 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

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

    pt_PT.php
    $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,

    p.s.
    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]['LeftAndMain.ss']['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;

    by:

    $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,

  • Ingo
    Avatar
    Forum Moderator
    801 Posts

    Re: i18n and 2.2.0-rc3 weirdness Link to this post

    hey there,

    thanks for your research and detailed bug report! we are aware of this problem and filed a ticket for it last week (http://open.silverstripe.com/ticket/1666#comment:3). 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: http://open.silverstripe.com/ticket/1895

    cheers for your contribution (portugues translation)!

  • rbarreiros
    Avatar
    Community Member
    21 Posts

    Re: i18n and 2.2.0-rc3 weirdness Link to this post

    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,

  • rbarreiros
    Avatar
    Community Member
    21 Posts

    Re: i18n and 2.2.0-rc3 weirdness Link to this post

    Hello,

    Found the bug, posted the bug and an eventual temporary solution in the trac
    http://open.silverstripe.com/ticket/1666#comment:4

    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,

    1086 Views
Page: 1
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.