Strange problem building a language switch in a module

[thomas]

Hello,

I built a bilingual site with a little language switcher in a module. problem is, it works *most of the time* ... and the solution was to add a simple message line in the module. Here's the code:

$this->addHookBefore('Page::render', $this, 'changeLanguage');

public function changeLanguage (HookEvent $event) {

        $lang = wire('session')->language;
        if(!$lang) {
            if(strstr($_SERVER['HTTP_ACCEPT_LANGUAGE'],'de')) $lang = 'de';
            else $lang = "eng";
        }
        $lang = wire('input')->get->lang?wire('input')->get->lang:$lang;
        if($lang != wire('session')->language) {
            $this->message(__('Sprache geändert zu')." ".$lang); # IMPORTANT!!!
            $l = ($lang == 'de') ? 'deutsch' : 'default';
            wire('user')->language = wire('languages')->get($l);
            wire('user')->save('language');
            wire('session')->language = $lang;
            wire('session')->redirect($event->object->url);
        }
    }

if I leave the $this->message() bit out, i get everything from working, via "Trying to get property of a non-object in LanguageSupportFields line 131", to simply not working at all.

Can anyone explain??

Thanks,

thomas

[ryan]

Thomas, I'm finding this block of code really difficult to follow. There may be issues here that we can't be certain of without stepping through it live. I think there might be benefit in refactoring it. Beyond that, I suggest doing a wire('sanitizer')->entities('text'); on the output you are sending through $this->message(), as that seems to be vulnerable to XSS injection (though maybe you are just using that for debugging). I also have some concerns about this method of presenting different language content on a site because it uses the http_accept_language header rather than a defined URL. That could create some potential SEO issues. Though if search indexing is not a concern here, then it should be ok. But the other disadvantage is that it's relying on session variables to determine output, preventing it from being cachable (whether with the built in template cache or ProCache). Regardless of which direction you go, you may want to use the dev branch just because it has better multi language support. 

[thomas]

Hello Ryan,

thanks for your answer. I completely changed the code and now it works. The idea was, to automatically send the user to the appropriate language but HTTP_ACCEPT_LANGUAGE didn't even work consistently in my two browsers.

[Martijn Geerts]

As a side note:

I use English for my system and all my programs, no exception. But when I visit a site I'll read dutch. A turkish developer in Germany with a turkish system, would he want to use English, German or Turkush ?

Making assumptions from collected language info is in my opinion not the way to go. The only way you can play nice using the domain name, as the user has 'chosen' for the language. ( sort of )

[thomas]

You are probably right Martijn. I now default to german, since that's where the company is based. English speaking customers can easily change the language, that shouldn't be too much to ask.

Still impressed by the multi-language capabilities of PW! It's the first time I used the module.

Thanks,

thomas