Extension talk:LanguageSelector/LQT Archive 1

LANGUAGE_SELECTOR_AS_PORTLET

2011-01-02: for w3c xhtml 1.0 validation, replace in LanguageSelector.php:

'id' => 'n-languageselector',

with:

'id' => 'n-languageselector-' . $ln,

---

Hello,

I have install this very interresting extension on my Wiki. And I wanted to use the value "LANGUAGE_SELECTOR_AS_PORTLET" for "$wgLanguageSelectorLocation" but it doesn't run. I use a Skin based on Monbook. Only values LANGUAGE_SELECTOR_AT_TOP_OF_TEXT and LANGUAGE_SELECTOR_IN_TOOLBOX can run on my Wiki. I don't know if I have to change some values on LanguageSelector.php?

(I'm sorry for my english, but I'm a french student!) Sébastien 14:22, 6 April 2007 (UTC)

The other options only work with MediaWiki 1.10 and newer. You can add support for this by hacking the SkinTemplate.php file: near the end of the outputPage function, before // execute template, add this:

		// original version by hansm
		if( !wfRunHooks( 'SkinTemplateOutputPageBeforeExec', array( &$this, &$tpl ) ) ) {
			wfDebug( __METHOD__ . ': Hook SkinTemplateOutputPageBeforeExec broke outputPage execution!' );
		}

well, just this would probably do:

                wfRunHooks( 'SkinTemplateOutputPageBeforeExec', array( $this, $tpl );

No guarantee, though. Perhaps just wait a few days for MW 1.10 to come out officially. -- Duesentrieb ⇌ 21:04, 6 April 2007 (UTC)

Thank you for your quick help, now I can use this attribute on my Wiki v1.8.3. Sébastien 07:07, 10 April 2007 (UTC)

Bug with LANGUAGE_SELECTOR_INTO_TITLE

LANGUAGE_SELECTOR_INTO_TITLE does not work with MediaWiki 1.10alpha (r19865). It just displays the raw HTML data instead of the box itself. The source code of the page contains things like:

<span id="languageselector-box-1" class="languageselector " style="">

instead of

<span id="languageselector-box-1" class="languageselector " style="">

Please look into the page source in order to see the difference. ;-) I couldn't find out what is going wrong in the extensions. :-( Arnomane 18:06, 27 May 2007 (UTC)

Same problem happens with 1.11alpha (r22507) too (SVN checkout from today). So I guess it is not an incompatibility in an older MediaWiki version but a bug in the extension. Arnomane 14:18, 28 May 2007 (UTC)

MediaWiki: 1.11alpha

Extension is broken, at least since r23511.

Invalid NULL return from broken hook wfLanguageSelectorSkinTemplateOutputPageBeforeExec

Backtrace:

1. 0 /home2/web/w/includes/SkinTemplate.php(457): wfRunHooks('SkinTemplateOut...', Array)
2. 1 /home2/web/w/includes/OutputPage.php(695): SkinTemplate->outputPage(Object(OutputPage))
3. 2 /home2/web/w/includes/Wiki.php(307): OutputPage->output()
4. 3 /home2/web/index.php(90): MediaWiki->finalCleanup(Array, Object(LoadBalancer), Object(OutputPage))
5. 4 {main}

LanguageSelector.php, line 215:

-        return;
+        return true;

fixs this.

Done. Aaron 17:04, 26 July 2007 (UTC)

How can make it works?

Hello, I think this extension is really good for my wiki. but, It doesn't work.

Here is the way i was installed.

1. copied languageselector.php to extentions/LanguageSelector/

2. add require_once( "$IP/extensions/LanguageSelector/LanguageSelector.php" ); to my localsetting.php

and I have some error messages above the wiki like,

Warning: array_keys() [function.array-keys]: The first argument should be an array in /home/webhost/hansco/public_html/wiki-en/extensions/LanguageSelector/LanguageSelector.php on line 82

Warning: Invalid argument supplied for foreach() in /home/webhost/hansco/public_html/wiki-en/extensions/LanguageSelector/LanguageSelector.php on line 290

Warning: Invalid argument supplied for foreach() in /home/webhost/hansco/public_html/wiki-en/extensions/LanguageSelector/LanguageSelector.php on line 339

is there anyawy to make it work correctly?

I saw the way to configure the detail option about it. but I don't know exactly how...

I thought I can use default setting (without any edit except add "require_once" line into Localsetting.php) ...

Is there any simple way to use this extension??

Sorry about my poor English..

make sure you include the extension near the end of your LocalSettings.php - do not put custom settings at the top.

If that doesn't fix it, i don't know what is wrong - basically, it complains about wgLanguageNames being null - which can't happen, really. At least i don't know how it could. -- Duesentrieb ⇌ 11:04, 22 July 2007 (UTC)

I have exactly the same problem :-( SPQRobin 19:27, 7 August 2007 (UTC)

I have put it at the last line, just before ?>, and now it works. Strange :-S SPQRobin 20:32, 7 August 2007 (UTC)

Shorter list & how to call it only when needed in certain pages

Hi, great extension! It works fine for my wiki with the default settings (all languages, and at top of text) but when I try to make a shorter list (English and Spanish only) it says:

Warning: Invalid argument supplied for foreach() in /home/.munchie/mansalva/estigmergia.net/w/extensions/LanguageSelector.php on line 290

And the same for line 339

This happens when I've tried $wgLanguageSelectorLanguages = 'English','Spanish'; (and 'en','es';) but it doesn't work :(

Also, I wonder how to call the menu only when needed in the wiki: is it with LANGUAGE_SELECTOR_MANUAL ? What code would I have to write in the content of the page where I need it to appear? --Esenabre 23:39, 22 July 2007 (UTC)

Hello, with regards to the shorter list, I've managed to make it work by adding the following at the end of my LocalSettings.php. (Everything else is default installation - Only worked using monobook skin.)

$wgLanguageSelectorLocation = LANGUAGE_SELECTOR_IN_TOOLBOX;

$wgLanguageSelectorLanguages = array("en", "es", "fr");

--200.89.181.5 04:12, 2 August 2007 (UTC)

Well, I have the same problem, so I have reported that as a bug. It work even in Gumaxcc skin, but just a list of all languages, not just selected lanugages.--Juan de Vojníkov 13:26, 4 July 2011 (UTC)

LANGUAGE_SELECTOR_AS_PORTLET for one page

Is it possible to set "LANGUAGE_SELECTOR_AS_PORTLET" only for one page? Thank you, SPQRobin 13:21, 27 September 2007 (UTC)

Reload?

I've got two problems with the LanguageSelector. It's a great extension, but I'm not sure what I'm doing wrong...

First I get the Error "Fatal error: Call to undefined function wfLoadExtensionMessages() in ...\extensions\LanguageSelector\LanguageSelector.php on line 82

I've downloaded the file "ExtensionFunctions.php" and copied it in my extensions-folder. Still the error. So I tried just to comment this line 82 out. Now the extension works pretty fine. Now I've got another problem, I has to click twice on the language to change it, oder reload after choosing a language. Is this the problem of the cache you indicated or is this because I uncommented line 82 or another problem? How can I make it working correctly?

Thanks for help, would be a great extension!

bluerouse

You should upgrade to MediaWiki 1.11. Lower versions do not have the method wfLoadExtensionMessages. Siebrand 23:21, 21 February 2008 (UTC)

Bug on parsing languages

It seems that I have found a bug on LanguageSelector

When used with this browser settings: Accept-Language es,es-es;q=0.8,en;q=0.6,en-us;q=0.4,de;q=0.2 the webpage is shown in german instead of Spanish.

All the languages are enabled.

I was using a LanguageSelector downloaded from the bundle directory with this data: 03-Mar-2008 03:21 8.5K

adrian15

Bug with localization of LanguageSelector itself

My problem is that the actual LanguageSelector does not translate its own interface.

For example, in portlet mode, the title above the portlet stays as "language", regardless of what language you set. And in dropdown-box mode, the set button still says "set".

The only time the LanguageSelector interface translates is if you use the "uselang=XX" in the address bar, or you are logged in.

So, apparently, MediaWiki hardcodes locales which do not have a value in MediaWiki: namespace.

Is there any fix for this? Perhaps making this into a MediaWiki: namespace page? Or maybe having this extension run before the hook is added?

I will experiment with this. If I find a fix I will post it here.

Thanks, Harold.

Ok, after making many modifications, I fixed it.

The fix was to move wfLoadExtensionMessages( 'LanguageSelector' ); to the bottom of the main extension function.

I also made some other modifications that made it better, if anyone is interested.

Thanks, Harold.

European languages

$wgLanguageSelectorLanguages=explode(" ", "de en fr be bs bg ca cy cs da es et eu el ga gd hr hu is it lv lt mk mo nl nn no pl pt ro ru sk fi sv tr uk");

LanguageSelector in Personal_Urls bar

well i want to inject this selector in personal bar on monobook skin.

simpliest way for it - set

$wgLanguageSelectorLocation = LANGUAGE_SELECTOR_MANUAL;

and after this text in monobook.php

	<div class="portlet" id="p-personal">
		<h5><?php $this->msg('personaltools') ?></h5>
		<div class="pBody">
			<ul>

add

<?php echo wfLanguageSelectorHTML(); ?>

--Schthaxe 00:15, 7 February 2009 (UTC)

Way to have Language menu ABOVE search?

Pretty self explanatory, is there a way to inject the portlet above the search bar in the sidebar?

That would be awesome, because some of our users are... special.

And what about to move search menu below something?--Juan de Vojníkov 13:41, 4 July 2011 (UTC)

Multi language sidebar patch

This is a simple idea to get a custom translated sidebar. I don't know how to do it in another way, so I thinked to put a patch in includes/Skin.php.

With this patch, the sidebar source pages with translations are accessible at Mediawiki:Sidebar-LANG, where LANG=en,de,it,etc. The patch is tested in 1.15.1.

Apply patch: add the code in includes/Skin.php as shown below.

	function buildSidebar() {
		global $parserMemc, $wgEnableSidebarCache, $wgSidebarCacheExpiry;
		global $wgLang;
		wfProfileIn( __METHOD__ );

		$key = wfMemcKey( 'sidebar', $wgLang->getCode() );

		if ( $wgEnableSidebarCache ) {
			$cachedsidebar = $parserMemc->get( $key );
			if ( $cachedsidebar ) {
				wfProfileOut( __METHOD__ );
				return $cachedsidebar;
			}
		}

		$bar = array();

//Insert patch here -->
		$sidebar_name='sidebar' . '-' . $wgLang->getCode();

		$sidebar_content = wfMsgForContent( $sidebar_name );
		if ( wfEmptyMsg ( $sidebar_name,  $sidebar_content) ) {
			$sidebar_name='sidebar';
		}
//End patch <--

		$lines = explode( "\n", wfMsgForContent( $sidebar_name ) );

Custom translated sidebar? How it should perform? I havent figured out it.--Juan de Vojníkov 13:59, 4 July 2011 (UTC)

Don 't work with 1.18

I've download the last version of this extension but it don't work with 1.18 in my wiki. I choose the language but it don't brings me to the pages with this language, only changes the interface texts. The wiki [1] is in catalan (base language and /ca) and spanish (/es). I use also the last version of Plyglot, and the Vector skin. --Dvdgmz 12:27, 7 February 2012 (UTC)

I think it is rather a problem with Polyglot. I had the exact same problem, and now it works after I did an "svn update" of Polyglot. (see http://www.omegawiki.org/Help:Expression to check that it is what you expect)

But you say that you have the last version of Polyglot, so... --Kipmaster 12:50, 7 February 2012 (UTC)

oh! Was that! The last snapshot it isn't the same of the last version in SVN. Now it works. Thanks a lot. --Dvdgmz 14:32, 7 February 2012 (UTC)

I still have some bug with Monobook theme at least.

From line 237 of LanguageSelector.php there is an error

$html = wfLanguageSelectorHTML( $skin->getTitle() );

Now if I change the code like this:

$html = ""; //wfLanguageSelectorHTML( $skin->getTitle() );

The error is gone.

Error text says:

Fatal error: Call to undefined method MonoBookTemplate::getTitle() in /home/iocellco/public_html/iocellnetworks.com/manuals/extensions/LanguageSelector/LanguageSelector.php on line 237

I downloaded and overwrote both Polyglot and LanguageSelector version 18x from the extensions pages.

Product Version MediaWiki 1.18.0 PHP 5.2.17 (litespeed) MySQL 5.1.52-cll

I have made a change on my local version. I think it's not the recommended way to do it (so I don't commit it), but it works:

You can replace

$html = wfLanguageSelectorHTML( $skin->getTitle() );

with

global $wgTitle;

$html = wfLanguageSelectorHTML( $wgTitle );

it should work. --Kipmaster (talk) 07:22, 23 March 2012 (UTC)

Now, I think the correct solution should be

$html = wfLanguageSelectorHTML( $skin->getSkin()->getTitle() );

in fact, the "$skin" variable should not be called "$skin" anymore to avoid ambiguity. --Kipmaster (talk) 23:36, 19 December 2012 (UTC)

Can not run it on 1.19 version of mediawiki

I've copied files in extensions/LanguageSelector and included require_once( "$IP/extensions/LanguageSelector/LanguageSelector.php" ); in LocaleSettings.php, but it doesn't work. I got message Fatal error: Call to undefined method Language::fetchLanguageNames() in /var/www/wiki/extensions/LanguageSelector/LanguageSelector.php on line 127 Help please, I really need this extension!

Try this http://www.mediawiki.org/wiki/Special:ExtensionDistributor/LanguageSelector and select MW 1.19.

If this does not work, you can either upgrade your mediawiki or get this old version of LanguageSelector.php and copy it.

Or install the new and pretty Extension:UniversalLanguageSelector :-) --Kip (talk) 14:52, 4 June 2013 (UTC)

Problem with Personal_URL Bar in with Vector Skin (SOLVED)

How can I insert Language Selector into Personal_URL Bar? I tried this:

$wgLanguageSelectorLocation = LANGUAGE_SELECTOR_MANUAL; 
and after this text in vector.php

	<div class="portlet" id="p-personal">
		<h5><?php $this->msg('personaltools') ?></h5>
		<div class="pBody">
			<ul>

add

 <?php echo wfLanguageSelectorHTML(); ?>

But doesn't work. It said: Catchable fatal error: Argument 1 passed to wfLanguageSelectorHTML() must be an instance of Title, none given,

any suggestion?

thx!

You can get the title like this :-)

 <?php echo wfLanguageSelectorHTML( $this->getSkin()->getTitle() ); ?>

Personal opinion: it does not look too good on my server to have it in the url bar. The UniversalLanguageSelector integrates better with the interface. --Kipcool (talk) 18:50, 13 June 2013 (UTC)

[SOLVED] Thx!! ULS is better, but annoymous user cannot change language yet.. :-(

It should work for anon if you set

$wgULSAnonCanChangeLanguage = true;

Problem with Capital Letter (SOLVED)

I have two languages (en and es) in Language Selector. 'en' appears as English but 'es' appears as español (without first capital letter). Where I can change it?

Thx!!

The names come from MediaWiki proper (languages/Names.php). It uses the names of languages in the local languages. In English, language names are capitalized, but in most languages it is not...

I have not tried it, but I believe you can override the language names with Manual:$wgExtraLanguageNames , so $wgExtraLanguageNames['es'] = 'Español'; or 'Spanish' according to what you want to do. It might be a bit tedious to write it for all languages.

If you just want to capitalize the names - but keep the same names - you can also use the 'ucfirst' function of php, and put it in the LanguageSelector code where the list is generated. --Kipcool (talk) 18:58, 20 June 2013 (UTC)

[SOLVED] Perfect!! I just rewrite the name in Names.php. Thx!!

What is the relationship between this extension and ULS?

The thing I most want to do is to permit anonymous users to see a different language (more below). The ULS documentation says that this isn't possible. However, documentation on this page (a couple of topics up) says explicitly that it is possible with ULS, and also with LanguageSelector. This is very confusing. Is one of these extensions preferred over the other?

My actual goal, which may not be possible, is to have the interface language for anonymous users depend on the domain of the URL used to access the wiki, at least for the home page. I'm hoping to do this via appropriate mod_rewrite rules once I know how to set the interface language for anonymous users. But even if this doesn't work out I'd like anonymous users to be able to set the language! Which extension should I use?

This extension is not ULS. It's also not true that ULS doesn't work for unregistered users: it doesn't just on Wikimedia Foundation wikis due to their cache system. --Nemo 06:00, 31 October 2013 (UTC)