Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
LanguageSelector: a new extension for versatile user language selection
Max_B
New
There were already ChooseLanguage by Jonas John.
But I wanted something more versatile. This one add two main features:
- The language is automatically selected from the browser HTTP_ACCEPT_LANGUAGE information.
- Registered users can save their setting from a new panel in the account section.
There is also, as in ChooseLanguage, a select in the control panel for unregistered users.
It save the selected language value in a server side SESSION variable rather than in a cookie.
Remember this while testing, you should close the Vanilla session or the browser to reset the variable and test automatic selection.
*********
NOTES
*********
1 - The language setting for registerd user is stored accros session in the standard Vanilla Attributes column of the Users table. Thus, the setting is visible, and editable from the Identitity from. If the label of this attribute is changed, the setting becomes inoperant. The extension then fallback to browser language selection, or else default to global forum language setting.
2 - A side effect of this extension can be confusing: any user able to change the global forum language, when opening the standard form, will be presented a default selection of his own personal language setting, even if this is not the current setting.
Example: the forum is set up to English, the administrative user set its own preference to Spanish. When he displays the form, he'll see Spanish selected forum-wide, even if English is currently in use.
This is only when administrator saves the form that the language will be changed application-wide.
Ultimately, look at conf/settings.php to check the global setting.
3 - This is not a "pure" extension. Due to the order of execution we need to insert some processing before the language files inclusion.
Edit:
4 - Any languages/definitions.php dictionary file MUST include a line defining the 'XMLLang' entry: $Context->Dictionary['XMLLang'] = 'en-ca';
This line is used to correlate the language codes used by browser and the name of the language directorie which are not standard in Vanilla installation. If a file does not contain this line, the language is still selectable with form selects but is not automatically choosen.
But I wanted something more versatile. This one add two main features:
- The language is automatically selected from the browser HTTP_ACCEPT_LANGUAGE information.
- Registered users can save their setting from a new panel in the account section.
There is also, as in ChooseLanguage, a select in the control panel for unregistered users.
It save the selected language value in a server side SESSION variable rather than in a cookie.
Remember this while testing, you should close the Vanilla session or the browser to reset the variable and test automatic selection.
*********
NOTES
*********
1 - The language setting for registerd user is stored accros session in the standard Vanilla Attributes column of the Users table. Thus, the setting is visible, and editable from the Identitity from. If the label of this attribute is changed, the setting becomes inoperant. The extension then fallback to browser language selection, or else default to global forum language setting.
2 - A side effect of this extension can be confusing: any user able to change the global forum language, when opening the standard form, will be presented a default selection of his own personal language setting, even if this is not the current setting.
Example: the forum is set up to English, the administrative user set its own preference to Spanish. When he displays the form, he'll see Spanish selected forum-wide, even if English is currently in use.
This is only when administrator saves the form that the language will be changed application-wide.
Ultimately, look at conf/settings.php to check the global setting.
3 - This is not a "pure" extension. Due to the order of execution we need to insert some processing before the language files inclusion.
Edit:
4 - Any languages/definitions.php dictionary file MUST include a line defining the 'XMLLang' entry: $Context->Dictionary['XMLLang'] = 'en-ca';
This line is used to correlate the language codes used by browser and the name of the language directorie which are not standard in Vanilla installation. If a file does not contain this line, the language is still selectable with form selects but is not automatically choosen.
0
This discussion has been closed.
Comments
@kari: yeah, I didn't check well for version compat. I'll do it tomorrow.
You can bet that if I had to add this line in some core files, this is because I see no way at the moment to do it otherwise.
I guess Mark will give us a hook someday, but I'm not sure he got this point that some of us really need multi-lingual capability on the same server. Not only global application change. Besause, after all, it's not big deal to do. One more configuration variable and a line here and there.
IF
- you don't use conf/language.php for translation, and you shouldn't if you want to be multilingual, rather keeping extensions translation in languages/*/definitions.php.
- you accept a less efficient dictionnary loading because you will do it twice for each page
THEN
- copy the content of the LanguageSelector.php file of the extension into conf/language.php (or move/rename)
- add, at the end of this file the following line :
include($Configuration['LANGUAGES_PATH'].$Configuration['LANGUAGE'].'/definitions.php');
This last line is a copy of the original include, so it is done a second time, overloading the default language.I do not promote this solution because this is not the intended purpose of conf/language.php, but it might fulfill your requirement.