Problem with browser codes selecting user interface language

[syseyes]

Hello, I am trying your plugin in your environement, and I think I have found a bug in the language selection when the browser send language preferences. Our aplications are multiligual. We use mainly two languages: es: Spanish ca_ES: Catalan (Catalan language, Territorial settings I have discover that language selection from the browser fails with the ca_ES character code.

I believe the root cause come from that the browser send the language code without the territorial setting. The browser sends: " Accept-Language:ca,en;q=0.8,es;q=0.6" and the script /plugins/MultilanguagePlugin.php fails to associate the right locale page.

I suspect the the failing code is these

 if (! $userPrefLanguageCode) {
            $codes = unserialize( get_option('multilanguage_language_codes') );
            //dump the site's default code to the end as a fallback
            $codes[] = $defaultCode;
            $browserCodes = array_keys(Zend_Locale::getBrowser());
            foreach ($browserCodes as $browserCode) {
                if (in_array($browserCode, $codes)) { //Fails comparing two caracter with 5 characer code**
                    $this->locale_code = $browserCode;
                    break;
                }
            }

I solved my case getting only the to first characters of the multilanguage_language_codes in order two compare

 if (! $userPrefLanguageCode) {
            $codes = unserialize( get_option('multilanguage_language_codes') );
            //dump the site's default code to the end as a fallback
            $codes[] = $defaultCode;

 //Reduce to two character code in order two compare
            for ($temp = 0; $temp < count($codes); $temp++) {
                $codes[$temp]=substr($codes[$temp], 0, 2);
            }

Thank you for your work.

Joan

[syseyes]

I tried to create a pull request on github to solve that problem. Is my first time on Gihub so I dont know if I have done right or violated any netetiquete.

Bye

[zploskey]

This change (merged in 1c7b373, pull request #5 ) breaks the case where the browser sends a 4 character locale code first and the site uses a 4 character locale code for translations. It sets $this->locale_code to the two character version, and then fails to find the translations which use the 4 character code. This results in nothing but dates being translated by Omeka. I would think that this would be a very common occurrence. Reverting this change fixes translations for our site in this case.