MediaWiki talk:Gadget-AnonymousI18N.js

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 7 days.

This script causes an endless reload loop[edit]

As pointed out in the village pump this script sometimes causes an endless reload loop. Multiple users confirmed this. I was able to reproduce the bug in the current Opera 11.51. To reproduce I did the following:

  1. Delete all cookies on Commons and my German Wikipedia (DE).
  2. Login at DE with both "globally" and "remember" disabled.
  3. At DE I go to an image description page (example).
  4. I click on the "to Commons" link. This calls a link with ?uselang=de added and sends a referrer from DE the same time (example, but clicking the link here does send an other referrer).
  5. Now the endless loop happens. I'm able to look at the code using Opera Dragonfly. Here is what happens:
    1. init() is called.
    2. wgAnonUserLanguage is set to de.
    3. The next if succeeds because AnonymousI18N_suggestlang is de and wpAvailableLanguages["de"] is a string.
    4. redirectCurrentPageToLanguage("de") is called.
    5. if ( location.search === '' ) fails because it contains ?uselang=de.
    6. if ( location.search.indexOf('uselang=') !== -1 ) succeeds.
    7. The next line sets search to ?uselang=de.
    8. Then location.href = is called and redirects the page to the same location. This is where the endless loop happens.

I'm not sure what is supposed to happen here. There is a big comment in the code I don't understand. I think the redirection code depends on location.href being set to the same value should do nothing. But it reloads the page over and over again if set to the same value. At least this is what happens in Opera. --TMg 11:42, 16 September 2011 (UTC)[reply]

The erroneous code was added in January 2011. As I said I don't understand why it is there. For me it does not make any sense. Let's say somebody is working in the FR Wikipedia but set it's user interface to NL. Then he is following a link to Commons with uselang=nl added. Commons starts loading in NL but in the same second it is redirected to FR. What the ...? This sounds totally wrong. I would suggest to remove all redirection code because it ignores what the user wanted when he clicked the link, it causes traffic for no good reason and is erroneous as reported. If the user wants to switch the language he can do this by using the select field on the left. That's what this script is about. It should not "guess" something it does not know. What it can do is to use the guess to preselect a language in the select field. Should I report this as a bug? --TMg 14:03, 16 September 2011 (UTC)[reply]

In other words: Don't try to "fix" something that have to be fixed on the other side, where the link was placed. From this side it's impossible to tell the difference between incoming links that contain an uselang attribute by purpose and links that contain the same attribute by accident.

In short: Never redirect if location.query already contains uselang=. --TMg 14:14, 16 September 2011 (UTC)[reply]

I can't reproduce this bug in Chrome, but I guess the cause is that the browser you're using preserves the document.referrer even after refreshing, making the script think that you're still on the entry point. I'll try to find a workaround for this. Also, cookie and url-'uselang' value have precedence over referrer, so if you've been on Commons before and chosen a language, it won't (at least shouldn't) redirect you to the language of the referral url. –Krinkletalk 00:30, 18 September 2011 (UTC)[reply]
This fixes the problem with the endless loop. Thank you. But it does not fix the other issue I described above. If you are for example in the DE Wikipedia and you click a link to Commons with ?uselang=nl added it starts loading Commons in NL but redirects to DE in the same second. The ?uselang=nl is ignored no matter if it's there for a reason or not. As I said, never redirect if location.query already contains uselang=, no matter what language it is. --TMg 11:16, 18 September 2011 (UTC)[reply]

Logical error in the code[edit]

By the way, this code looks completely wrong:

if ( AnonymousI18N_suggestlang && typeof wpAvailableLanguages[AnonymousI18N_suggestlang] === 'string' ) {
    AnonymousI18N.redirectCurrentPageToLanguage( wgAnonUserLanguage );
}

The if checks a variable that is not used if the check succeeds. Instead an other variable is used. It checks if AnonymousI18N_suggestlang is set and valid but uses wgAnonUserLanguage inside the if. This does not make any sense. --TMg 11:23, 18 September 2011 (UTC)[reply]

Indeed, I pointed this out in the IRC conversation the other day. wgAnonUserLanguage is defined earlier in the code and set to the value of AnonymousI18N_suggestlang when it's available. However that is wrong. Simply redirecting to AnonymousI18N_suggestlang here is wrong too. I'll need to rethink this part, I've commented it out for now. –Krinkletalk 16:25, 22 September 2011 (UTC)[reply]

View... in...[edit]

The script offers users the suggestion "View Wikimedia Commons in language X", and wikilinks X. It's confusing to link the language, as it feels like it might be a definition of the term... The action part of the sentence ("View") should be linked - and the easiest way to do that without running into translation complications is to link the whole thing. Rd232 (talk) 19:55, 25 April 2012 (UTC)[reply]

Form submission[edit]

Can we apply &uselang= on form submissions too? Liangent (talk) 12:54, 29 September 2013 (UTC)[reply]

Something like that is done at $('form').submit(function(e) {. Where does it not work? -- Rillke(q?) 13:45, 29 September 2013 (UTC)[reply]
Hmm but it works nowhere on Wikidata (they're hotlinking to this script on commons), including the forms on d:Special:RecentChanges and d:Special:Whatlinkshere. Liangent (talk) 10:09, 30 September 2013 (UTC)[reply]
This should work now. Hooking search for search terms that match still does not work because:
  1. Client requests /w/index.php?search=<search-term>&title=Special:Search&uselang=myLang
  2. Server responds: 303 Moved Temporarily Location: /wiki/<search-term>
  3. Client navigates to /wiki/<search-term>
-- Rillke(q?) 11:44, 30 September 2013 (UTC)[reply]
Thanks. It works there now. But one more request, can uselang be applied on mid-clicking on links (= open in new tab) too? Liangent (talk) 10:36, 1 October 2013 (UTC)[reply]

Norwegian Bokmål[edit]

Hi, I'm not sure how to do this, but please make it so Norwegian Bokmål uses the code 'nb' instead of 'no'. 'no' is a common code for both Bokmål ('nb') and Nynorsk ('nn'), so using 'no' is erroneous – especially on Wikidata, where this script is also used. Thanks. Jon Harald Søby (talk) 05:51, 19 August 2014 (UTC)[reply]

Removing redundant language select[edit]

{{Editprotected}} Imho "- It creates the "Language select" menu in the sidebar which sets &uselang= and saves choise in a cookie" is redundant, mw has a own language selector now. Adding {{Editprotected}} because i don't speak js. Thanks --Steinsplitter (talk) 12:41, 22 November 2014 (UTC)[reply]

@Krinkle: @Rillke: --Steinsplitter (talk) 14:28, 22 November 2014 (UTC)[reply]
ULS dos not work for anons :( (Log in to select a different language for menus.) --Steinsplitter (talk) 17:25, 24 November 2014 (UTC)[reply]
Indeed, and that's the problem. -- Rillke(q?) 06:44, 25 November 2014 (UTC)[reply]

Broken JavaScript[edit]

MediaWiki developers found that this page probably breaks JavaScript for users (example: not seeing the buttons when editing a page). You probably need to edit this .js page and/or MediaWiki:Gadgets-definition as in the examples at phabricator:T122755. List more pages to check.

If you have questions or need help, please ask at phabricator:T164242. You can login with your wiki account. Best wishes, Nemo 09:49, 14 May 2017 (UTC)[reply]

Show only yue, do not show zh-yue[edit]

yue is the correct ISO langcode. zh-yue is only a wikipedia legacy. As user interface language, only yue should be used. Commons pages do not use zh-yue either Category:Commons-yue.--Roy17 (talk) 23:06, 28 September 2019 (UTC)[reply]

@Roy17: Thanks, I've reported the issue at https://github.com/Krinkle/intuition-web/issues/4. --Krinkle 19:56, 10 October 2019 (UTC)[reply]

Convert to a gadget[edit]

{{Editprotected}}

I think this should be converted to a (hidden) gadget. It has several advantages:

  • Automatic minification, so the massive amount of comments and whitespace that help making the code easier to understand for humans don’t cause unnecessary bytes to be downloaded for all anons.
  • Opportunity to associate a CSS stylesheet with the JavaScript, so the mw.util.addCSS() and the style attributes can be moved to a separate page where it’s treated as CSS instead of just a string, so there’s syntax highlight, linting etc. This CSS is minified just like JS.
  • Version-aware caching, so the code can be cached for a longer time without risking fast purging when someone changes the code.

The minification and longer caching are especially important for a script executed by all anons, so even if the conversion requires a small amount of work, I think it’s worth it. I don’t write down exact steps, as it would be quite long and I hope interface admins know how to do this, but if the fulfilling IA needs help, I’m happy to provide it. ―Tacsipacsi (talk) 19:56, 4 December 2020 (UTC)[reply]

@Tacsipacsi: This sounds like a good idea to me, and I think I mostly know how to do it, but I’d still appreciate some help :) maybe in some chat like Telegram or chat.wmcloud.org? Anyways, the main thing not clear to me is how we would avoid loading the script for logged-in users. Is there an elegant way to do it in the gadget definition, or would you just put something like if ( mw.config.get('wgUserName') !== null ) return; at the top of the gadget JS? --Lucas Werkmeister (talk) 15:39, 5 December 2020 (UTC)[reply]
@Lucas Werkmeister: I don’t like to register for yet another service, so these two services don’t look right for me (Telegram seems to ask for a phone number, which is completely out of question, no matter how encrypted it is), but I can help e.g. on IRC or anywhere else where I don’t need an extra registration. (As you can see, I’m a bit busy right now, so I can’t promise real time help until Christmas, but hopefully I’ll be relatively free between Christmas and New Year.)
I don’t know of any elegant way to load just for anons, so I thought that the main entry point in Common.js would be kept (changing the actual loading code appropriately, of course). Putting a return statement in this script is less ideal, as that would mean that logged-in users need to download the (minified) full script even though they don’t need it. —Tacsipacsi (talk) 15:47, 11 December 2020 (UTC)[reply]
@Tacsipacsi: IRC works for me, I’ll try to remember to go online between Christmas and New Year’s. So the common.js code would be something like mw.loader.load( 'ext.gadget.anonymous-i18n' ), I guess, to load the ResourceLoader-minified version of the script. --Lucas Werkmeister (talk) 19:46, 14 December 2020 (UTC)[reply]
@Lucas Werkmeister: Yes, that’s what I was thinking about. —Tacsipacsi (talk) 21:24, 20 December 2020 (UTC)[reply]
@Tacsipacsi: I’m lucaswerkmeister on Freenode and trying to be online in #wikimedia-commons and #wikimedia-commons-tech. My plan so far would be:
  1. Create a temporary copy of this page, maybe MediaWiki:AnonymousI18N-copy.js.
  2. Make MediaWiki:common.js load that copy instead of the original.
  3. Move this page to MediaWiki:Gadget-AnonymousI18N.js. (This way, we preserve the revision history.)
  4. Add the gadget to MediaWiki:Gadgets-definition#modules.
  5. Open a private window, run window.AnonymousI18N = {}; while the page is loading (to prevent the real AnonymousI18N from loading), wait, run delete window.AnonymousI18N;, then run mw.loader.load( 'ext.gadget.AnonymousI18N' ) to test that the gadget version is working. (I was hoping to test this using ?safemode=1, but it looks like that only disables user JS, not site-wide JS.)
  6. Make MediaWiki:common.js load the gadget instead of the copy.js file.
  7. Ask an admin to delete MediaWiki:AnonymousI18N-copy.js.
  8. Optionally, edit the comment at the top of MediaWiki:Gadget-AnonymousI18N.js to explain how the code is loaded now.
I’m not completely sure if the copy.js part is necessary – the move ought to leave some kind of redirect behind, but I’d rather not trust that. --Lucas Werkmeister (talk) 10:58, 27 December 2020 (UTC)[reply]
@Lucas Werkmeister: Looks good to me. Yes, there ought to be a redirect, but double protection never hurts. ?safemode=1 works for me—when logged out, the blue bar doesn’t appear with it (and the message boxes at the top of this page also look awful, as their styles from Common.css don’t load either). I’m tacsipacsi on Freenode. —Tacsipacsi (talk) 11:09, 27 December 2020 (UTC)[reply]
✓ Done, mostly – common.js currently loads the copy.js file as a fallback if the ResourceLoader module can’t be loaded, so in a month (to let caches expire) we should remove that from common.js, and then another month later remove the copy.js file again. --Lucas Werkmeister (talk) 15:25, 27 December 2020 (UTC)[reply]
Update: fallback to copy.js now removed from common.js (diff); deletion of copy.js can be requested one month later. --Lucas Werkmeister (talk) 17:13, 18 March 2021 (UTC)[reply]
Final update: deletion of copy.js requested and done. Lucas Werkmeister (talk) 11:12, 9 May 2021 (UTC)[reply]

vector-menu-heading for h3 tag[edit]

{{Ep}}

@@ -51,7 +51,7 @@

 // Don't load in skins other than Vector
 // Don't load twice
-if (conf.skin !== 'vector' || window.AnonymousI18N) {
+if ((conf.skin !== 'vector' && conf.skin !== 'vector-2022')) || window.AnonymousI18N) {
 	return;
 }

@@ -340,7 +340,7 @@
 		// their own path and preserving different languages.

 		// Insert Language-portal
-		var portalHTML = ' <div class="portal persistent vector-menu-portal" id="p-AnonymousI18N"><h3>' + (this.msgHelp[wgAnonUserLanguage] || this.msgHelp[
+		var portalHTML = ' <div class="portal persistent vector-menu-portal" id="p-AnonymousI18N"><h3 class="vector-menu-heading">' + (this.msgHelp[wgAnonUserLanguage] || this.msgHelp[
 			wgAnonUserLanguage.split('-')[0]] || this.msgHelp.en) + '</h3><div class="body">' + this.getLangDropdown() + '</div></div>';
 		$('#p-navigation').after(portalHTML);
 		mw.util.addCSS(

Add support to vector-2022, fix strange behavior problem with h3 tag. I could not remember the normal behavior of "#p-AnonymousI18N", so if there is some better solution, feel free to ping me. Stang 18:17, 10 March 2022 (UTC)[reply]

✓ Done, and I appreciate the diff syntaxhighlight :) --Lucas Werkmeister (talk) 21:41, 10 March 2022 (UTC)[reply]

Wrong language recognition: Slovenčina[edit]

{{Editrequest}} Hello. I have accessed the Main Page with another browser (MS Edge) as anonymous and have been offered Slovak (sk) instead of Slovene (sl) language on the Main Page. I have accessed the page by writing the address in the URL bar and have only English and Slovene installed in the browser; my IP is accurately located to Ljubljana, Slovenia. Could someone please check and correct the code or at least let me know if I should add a Phab request? Thank you. --TadejM (t/p) 12:33, 28 January 2023 (UTC)[reply]

@TadejM: The gadget doesn’t use IP-based lookup, so your IP is irrelevant. Unless you have already set your preference (try an InPrivate window instead of a normal one), the only thing the gadget takes into account is the language preference you set in your browser settings. (I don’t have an Edge at hand; in Chromium, it’s Settings → Languages → Preferred languages.) Any chance you mistakenly set “slovenčina” instead of “slovenščina”? This one letter difference can be really confusing at times… (But not for the gadget: it works with language codes, so sl and sk are not more similar than, say, sl and sv (Swedish).) I deactivated the edit request, since this is not an edit request, but a support request.Tacsipacsi (talk) 21:26, 29 January 2023 (UTC)[reply]

Hi, Tacsipacsi. Thank you for the reply. I checked it immediately and there was no Slovak language in my browser preferences. However, I visited some Slovak pages a few days earlier, so there may perhaps be some cookie... Anyway, I will check this in a private window and will see if the error persists. --TadejM (t/p) 21:31, 29 January 2023 (UTC)[reply]