Another method for front end multi-language support

As a multilanguage user myself, I was interested to read this and eager to see the Biber Ltd. Language Switcher Extension, but I think your download link takes us to an error page. Since I don’t speak the language there, I can’t be sure.

What language is that, anyway? I’m going to take a guess and say Turkish. Am I right?

iiiuuuu…. Thanks Brendon. The system is off for testing. I totally forgot about that. I’ve moved the download into a sub-domain and updated the links above.

Just incase the new link is this.

Oh, and yes it is in Turkish, and basically saying that the system is off for maintenance. We haven’t prepared all the English translations & all the site templates yet, sorry :)

By the way the code in extension is open to a lot of improvements. We’re still in process of understanding EE way of thing things so there may be some unvital lines of code there.

The other thing that I forgot, kind of the last step missing:

In your site’s root folder you have to create an .htaccess file as also told in Alternative Method. To our experience, the best practice right now is to remove both index.php and template group name from URLs. I’m not talking about security issues etc. It’s mainly important to achive correct auto created links in EE after the above mentione modifications.

Our .httaccess file looks like this:

#Handle removal of index.php and template group from EE URLs
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php/template_group_name/?$1 [L]

Lastly, you still may need to use Find & Replace plugin to fix pagination URLs.

Nicely done Can, it works very well on your site.

Added this one to the wiki here

Cem thank you for the comment & Lisa thank you for adding it into wiki.

We have made couple changes. Now the extension has a settings page where the user can define a default language and a list of site-wide available languages.

Some parts of the extension needed a manual code editing - therefore required more coding experience. Now vital stuff can be set using the control panel.

The site owner still needs to follow all the steps above and in addition to those steps he/she should define site default language and all languages used by the site. These settings used to be manual entries in extension code and they were required by the extension during decision making logic. And there was no way to change them without editing the code. Now, there is a chance for that.

On the settings there are two fields named respectively

1. Available Languages Available languages are those languages that the site is using. For each language there should have been a folder defined as stated in the above instructions.

On the extension’s setting page site admin needs to enter all the site-wide used language details according to this format:

i.e. deutsch,de|turkish,tr|english,en

Language names and their respective codes are sepereated by a comma. Each language and language code pair is seperated with | character.

The order is not important; however, language names and codes must match to those language names and codes as defined in path.php

2. Default Language Default language defines the default language that site will be shown if there is no cookie set for the visitor.

There must be only one language, language code pair. Similar to above format this language and language code pair must be seperated with comma and language name must be written first following by the code.

Once again the language name and code must match to those stated in path.php.

Here is the v1.1.0 of extension.

one more note thanks to Ross Curry. For this extension only replace all occurences of country_code with language_code.

This method is somewhat the evolved version of alernative method and some of the variable names may have been renamed. The above mentionet country_code is one of them. Although I doubt there may be few others.

Figured out a bug-like problem. The extension was conflicting with Brandon Kelly’s FieldFrame module. I was debugging and then I realized that the problem was with the addition of the hook. Since I am still learning the core of EE, such things unfortunately may happen. Anyhow, if the language switcher causes any conflicts with other extensions here is a possible fix: You need to use the blow updated step 7 during installation of this extension:

7. Add a new hook in fetch_language:

Right after above mentioned line, add this code:

/* -------------------------------------------
         * 'language_fetch_start' hook.
         *  - Do all you want before language fetch routine
         *  - Added to EE 1.6.7 core | Modified by Can Berkol - biber Ltd.
         */
        if ($EXT->active_hook('language_fetch_start') === TRUE)
        {
            $edata = $EXT->call_extension('language_fetch_start');
            if ($EXT->end_script === TRUE) return;
        }
        /*
        /* -------------------------------------------*/

Notice the if statment! Before - the extension was called every time regardless which hook was called. Not it is fixed.

oops and I forgot to include the updated extension… here is v1.1.1

It should be possible to do this without a core hack.

Add a hook for sessions_start, and call extend_language_class.

function extend_language_class()
{
        global $LANG;
        $LANG = new My_Language;
}

In your extension file, add a new class, and add your own copy of fetch_language_file.

class My_Language extends Language
{
function fetch_language_file($which = '', $package = '')
    {
        global $IN, $OUT, $LANG, $SESS, $PREFS, $FNS, $EXT;

// more code

// add your hook here

This is the same method I used for Custom System Messages. It’s just extending the main Language file, replacing fetch_language_file with your version and updating the global $LANG variable.

Hmmm nice 😊 I still find that hook useful but as you say there is no need for hack.

Thanks, Can Berkol