Policy | Technical | Proposals | Idea lab | Miscellaneous |
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).
Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk. |
|||||||||||||||||||||
|
|||||||||||||||||||||
« Older discussions, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145 | |||||||||||||||||||||
Centralized discussion | |||
---|---|---|---|
![]() |
|||
Proposals: policy | other | Discussions | Ideas |
Note: inactive discussions, closed or not, should be archived.
|
|||
Contents
- 1 Unresolved issue is archived - How to "UN-Archive"?
- 2 Preferred protocol for external links templates
- 3 Strip marker problems with nowiki tags
- 4 New (to me) mobile site - images in header
- 5 Certain articles on the iOS Wikipedia app show wrong images
- 6 Small improvement to standard Search Box
- 7 Tracking multiple transclusions
- 8 Wikipedia email
- 9 Template issue
- 10 Wrong page count in category
- 11 ru-wiki LinkSearch / api exturlusage issue
- 12 Breaking change: wikibits
- 13 Too many references
- 14 RfC notice: WP:CITEVAR scope, and citation coding (markup) vs. citation style (presentation)
- 15 Why does this happen?
- 16 Citation autofill on toolbar not working for journals
- 17 WP:Checklinks is still going bonkers
- 18 CSS Image Crop
- 19 Tech News: 2016-13
- 20 There's something wrong with XTools
- 21 Unhidden category
- 22 Recycled url
- 23 Broken links table
- 24 IPv6 range contributions
Unresolved issue is archived - How to "UN-Archive"?
Greetings, A problem awaiting resolution is now archived here and tracked at phabricator:T126553.
If it's not possible to pull back from archive, does it need to be re-posted again?
Regards, JoeHebda (talk) 19:04, 27 February 2016 (UTC)
- @JoeHebda: Just post the new question, with a link back to the archived thread. --Redrose64 (talk) 21:39, 27 February 2016 (UTC)
- If I re-post again here, will it be archived again before the issue is solved? Just wondering... JoeHebda (talk) 02:19, 29 February 2016 (UTC)
- Possibly; archiving bots do not take any notice of whether a thread has been replied to or not. Threads on this page are archived if they've not been posted to for five days. So if nobody responds here before the next bot run that occurs after 10:30, 5 March 2016 (UTC), it will be archived. --Redrose64 (talk) 10:30, 29 February 2016 (UTC)
-
-
- Redrose64 – Thanks for the update. Yesterday I did repost the new VPT archive link to Wikipedia talk:User scripts#Fix needed: Gadget only works with Vector skin, script error which was orginally posted on Feb. 15th. Wondering if there might be a better place to post where the issue can be fixed? Without waiting for months for a resolution? If I knew anything about scripts (which I do not) I would attempt to fix myself. Regards, JoeHebda (talk) 13:39, 29 February 2016 (UTC)
-
1) ω Awaiting a solution – also see: MediaWiki:Gadget-mobile-sidebar and Wikipedia:Gadget. JoeHebda (talk) 13:45, 29 February 2016 (UTC)
@JoeHebda: You can use {{DNAU}} to prevent archiving. nyuszika7h (talk) 21:26, 29 February 2016 (UTC)
2) ω Awaiting a solution — JoeHebda • (talk) 12:08, 2 March 2016 (UTC)
3) ω Awaiting a solution — JoeHebda • (talk) 18:12, 3 March 2016 (UTC)
-
-
- FWIW, i copied User:Brion VIBBER's script locally, and verified it works with "monobook" and "modern" after minor changes. i had to modify about 5 lines to use
mw.util.$content
instead of$('#content')
, and add a line to incease z-index specifically for monobook: for some reason the left edge of the mobile image was overshadowed by the right edge of the content in monobook (i'm sure there's more . you can try User:קיפודנחש/mobile-sidebarcopy.js to verify it indeed works with other skins (you'll probably want to disable the gadget, or you may get 2 of them...). peace - קיפודנחש (aka kipod) (talk) 20:55, 3 March 2016 (UTC)
- FWIW, i copied User:Brion VIBBER's script locally, and verified it works with "monobook" and "modern" after minor changes. i had to modify about 5 lines to use
-
-
-
-
- קיפודנחש – Thanks for helping. I know about testing computer programs in other languages but nothing about js scripts. If you or anther editor could explain the steps to test, I would be willing to try testing. So far, I did un-check existing Gadgets option to disable Mobile sidebar preview option. Regards, — JoeHebda • (talk) 21:36, 3 March 2016 (UTC)
- to test the modified script, add to your personal script file the following line (if you copy from edit screen, *do not* include the "code" tags):
importScript('User:קיפודנחש/mobile-sidebarcopy.js');
- (if the file does not exist yet, create it, add the line, and save. more detailed instructions and explanations about personal scripts can be found in WP:JS). peace - קיפודנחש (aka kipod) (talk) 22:15, 3 March 2016 (UTC)
- קיפודנחש – Thanks for helping. I know about testing computer programs in other languages but nothing about js scripts. If you or anther editor could explain the steps to test, I would be willing to try testing. So far, I did un-check existing Gadgets option to disable Mobile sidebar preview option. Regards, — JoeHebda • (talk) 21:36, 3 March 2016 (UTC)
-
-
קיפודנחש – Followed the test instructions & same results = Mobile sidebar preview works only with Vector skin & not the other skins. I did the Purge and logout for each; not seeing the little toolbar icon to activate preview. I know it is running the test version because I have the Gadgets one unchecked with Vector & icon shows & works correctly. — JoeHebda • (talk) 22:37, 3 March 2016 (UTC)
-
- you are correct. it turned out to be more elaborate than i thought - the code Brian wrote displayed the phone nicely, but placing the icon for turning it on/off on the menu turned out to be a bitch... anywhoo, i at least made it so that you can use it now, though it's not really pretty when you use a skin other than vector. peace - קיפודנחש (aka kipod) (talk) 00:10, 4 March 2016 (UTC)
- @JoeHebda: update: could not get the mobile on/off icon to look acceptable on monobook, modern and cologne blue, so on these skins, the on/off switch is text only (top row for mo*, left-menu under "Edit" for cologne). peace - קיפודנחש (aka kipod) (talk) 16:34, 4 March 2016 (UTC)
- @קיפודנחש: – So far, it looks good and okay to me. For Cologn Blue, I am confused because I can not find any "Edit" anywhere on the page; not on top or left sidebar. I do see a "Mobile view" but that is just for switching the entire page between Mobile/Desktop views. Wondering where to look? — JoeHebda • (talk) 16:48, 4 March 2016 (UTC)
- @JoeHebda: i practically never use cologne, and not aware of all its idiosyncrasies. for me, using this skin, when i am on a page i am allowed to edit, i see in the left-hand menu column "Edit". i verified that this is so even as anon (you can test any skin by appending to the address line "?useskin=<skinname>". this works for anons too. names are [ vector monobook modern cologneblue ]). i also verified that the script causes "Mobile" to appear there even for anons. there might be something in your prefs that causes it not to show, or maybe it *does* show and for some reason you missed it. HTH, peace - קיפודנחש (aka kipod) (talk) 17:58, 4 March 2016 (UTC)
- @קיפודנחש: – So far, it looks good and okay to me. For Cologn Blue, I am confused because I can not find any "Edit" anywhere on the page; not on top or left sidebar. I do see a "Mobile view" but that is just for switching the entire page between Mobile/Desktop views. Wondering where to look? — JoeHebda • (talk) 16:48, 4 March 2016 (UTC)
- @JoeHebda: update: could not get the mobile on/off icon to look acceptable on monobook, modern and cologne blue, so on these skins, the on/off switch is text only (top row for mo*, left-menu under "Edit" for cologne). peace - קיפודנחש (aka kipod) (talk) 16:34, 4 March 2016 (UTC)
- you are correct. it turned out to be more elaborate than i thought - the code Brian wrote displayed the phone nicely, but placing the icon for turning it on/off on the menu turned out to be a bitch... anywhoo, i at least made it so that you can use it now, though it's not really pretty when you use a skin other than vector. peace - קיפודנחש (aka kipod) (talk) 00:10, 4 March 2016 (UTC)
קיפודנחש – Yes, I did find it now. I had to set my custom CSS font-size to 155 percent for Cologne Blue skin to help overcome a line-height issue making that skin very hard to read. And the Mobile preview sidebar works okay there as well. Just a FYI, I found a report of User skin preferences at Wikipedia:Database reports/User preferences#Skin. Thanks so much for getting Mobile to work correctly with these skins! IMO not seeing the little toolbar icon is a lesser (non-structural) issue.
Now in order to go live with this script, what needs to be done? Once it is out there I will check On in Gadgets. Then, could the Mobile sidebar preview line of Gadgets be moved out of the Testing and development section? Perhaps move into Appearance section? Cheers! — JoeHebda • (talk) 19:13, 4 March 2016 (UTC)
- @JoeHebda: i saw this more as an experiment, to gauge the amount of change needed to make mobile-sidebar work with other skins. ideally, User:Brion VIBBER would patch the script on meta to work with all skins (TBH, Brion needs me to tell him how to do that exactly as much as i need my grandson to teach me to suck eggs). if, for any reason, Brion doesn't do it, enwiki can decide that limiting this gadget to vector is acceptable. the very last resort would be to change the gadget on enwiki to consume Brion's css file from meta, and the modified js file from my userspace (or some copy of it). this last option is both undesirable and unlikely. if none of those options is executed, people who do not use vector can consume my modified script privately, the same way i listed above and you tried. peace - קיפודנחש (aka kipod) (talk) 20:31, 4 March 2016 (UTC)
Preferred protocol for external links templates
I recently modified {{TED speaker}} to use https://www.ted.com/speakers/
instead of http://www.ted.com/speakers/
.
Would it be better to use //www.ted.com/speakers/
? Is there a policy/ MoS page describing this? Should we apply the latter to all external link templates for sites which use both protocols? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:50, 8 March 2016 (UTC)
- We only serve our content as https these days, so there should be a preference for https (since relative protocol does nothing in that case). I know of at least one user (Bender something or other) actively converting Internet Archive and Google links to https, so there is precedent. --Izno (talk) 12:14, 8 March 2016 (UTC)
- @Pigsonthewing: There is no policy, but we do have an essay, WP:PRURL. --Redrose64 (talk) 16:43, 8 March 2016 (UTC)
- WP:EL mentions it at WP:External links#Links to Wikimedia vs. to elsewhere. That essay hasn't been updated to take into account the two RFCs regarding IA and Google, or the fact we only serve our content via HTTPS, so I would be careful referencing it (especially since the word "preferred" gets used, when in fact it's not). --Izno (talk) 17:11, 8 March 2016 (UTC)
- @Pigsonthewing: There is no policy, but we do have an essay, WP:PRURL. --Redrose64 (talk) 16:43, 8 March 2016 (UTC)
Thank you, all. Time for an RfC? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:32, 8 March 2016 (UTC)
- @Pigsonthewing: As Izno indicated, Bender235 has for some time been changing http: to https: for Google and Internet Archive (Wayback Machine), per this RfC result, with no objections that I am aware of. PRURL could have been used instead in those cases, but he and others decided https: was preferable. If this is the same situation I don't see the need for another RfC. Here's some related user talk from last year. ―Mandruss ☎ 11:34, 9 March 2016 (UTC)
- I don't see any reason to still use PRURL. Wikipedia is now delivered HTTPS-only, and this won't change any time soon.--bender235 (talk) 15:21, 9 March 2016 (UTC)
- Because
HTTPHTTPS might be extremely slow as companies use a single server to MitM and we have reusers who use HTTP and dislike the expense and complexity of encryption. Also, I've noticed we're being overrun by political activists who are undermining the encyclopedia's neutrality to benefit their own groups. — Dispenser 17:21, 10 March 2016 (UTC)- I assume you had a typo there and meant HTTPS ("because HTTP"). Those rationale are not a defense of continuing to link to HTTP rather than HTTPS where we know that there is an available HTTPS link. --Izno (talk) 17:46, 10 March 2016 (UTC)
- Dispenser: Those who dislike the expense and complexity of encryption will avoid Wikipedia in the first place. Check your address bar, Wikipedia uses encryption. Re your political activists comment, I don't see how that applies to this thread. ―Mandruss ☎ 20:47, 10 March 2016 (UTC)
- (Fixed typo, sorry) Making HTTPS available is (mostly) non-political, disabling HTTP is political. Why close the option to our reusers? — Dispenser 23:02, 10 March 2016 (UTC)
- Fixed your typo fix per standard (this allows future readers to make sense of Izno's response). ―Mandruss ☎ 23:20, 10 March 2016 (UTC)
- Why are our reusers relevant? The ones who care about their security will accept the HTTPS; the ones who don't but who don't want HTTPS and care will rewrite the various linkage; and the ones who don't and don't and don't care... well, we don't care about them. This was mostly covered in the two RFCs related to HTTPS linking for IA and for Google. --Izno (talk) 02:04, 11 March 2016 (UTC)
- Reuse is part of the WP:Five pillars, that's why its important. And your argument amounts to more pointless work for reusers. — Dispenser
- (Fixed typo, sorry) Making HTTPS available is (mostly) non-political, disabling HTTP is political. Why close the option to our reusers? — Dispenser 23:02, 10 March 2016 (UTC)
- Because
- I don't see any reason to still use PRURL. Wikipedia is now delivered HTTPS-only, and this won't change any time soon.--bender235 (talk) 15:21, 9 March 2016 (UTC)
Do we have consensus here, or not? If not, I reiterate my suggestion of an RfC, to resolve the matter once and for all. (I have absolutely no opinion, one way or the other.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:20, 14 March 2016 (UTC)
- Last chance for comments, before I start an RfC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 18 March 2016 (UTC)
- I don't understand what you think you need an RFC for. [1] establishes a general consensus for where certain kinds of links should be used, and [2] establishes a consensus for IA and Google to use HTTPS only (such that a bot can execute on that action). Any RFC you propose should be on the specific question of TED if you think the changes may be controversial. --Izno (talk) 13:27, 18 March 2016 (UTC)
- I argued against that consensus. HTTPS offers an impact hit on every server and browser/computer. It also does not guarantee "security" of the information transferred. I would argue that we should modify user preferences to allow readers to select the protocol and find a way to encode URLs to honour that preference. For those who want all of their content encrypted, they can insist on it. For those who don't want it encrypted, they can request it. We can determine what the default should be as part of the discussion on how to implement it. Walter Görlitz (talk) 14:31, 24 March 2016 (UTC)
- I don't understand what you think you need an RFC for. [1] establishes a general consensus for where certain kinds of links should be used, and [2] establishes a consensus for IA and Google to use HTTPS only (such that a bot can execute on that action). Any RFC you propose should be on the specific question of TED if you think the changes may be controversial. --Izno (talk) 13:27, 18 March 2016 (UTC)
@Izno Because different people, in various places, keep telling me that there is consensus, but for different things (and because there was no answer to my question here of 14 March). That said, I think this is the first time that the January 2014 link you have newly provided has been mentioned. It's closing statement says:
There is a clear consensus to "Use HTTPS links for HTTPS only sites, protocol relative links for sites that support both HTTP and HTTPS, and HTTP links for sites that don't support HTTPS at all". Note, however, that the discussion doesn't concern the implementation of this proposal, and therefore a new one should be initiated regarding this.
which seems to be contradicted by your earlier comment:
We only serve our content as https these days, so there should be a preference for https (since relative protocol does nothing in that case).
Also, I'm looking for a general consensus, not one that is specific to TED, nor any other single site. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 23 March 2016 (UTC)
-
@Pigsonthewing: The January 2014 link is that general consensus; the individual site consensuses have been specifically to modify all uses of those protocols for those websites to HTTPS via (semi-)automatic method (so as to explicitly suggest that the edits being made do not run afoul of WP:COSMETICBOT). You can probably make an argument after-the-fact, if questioned, that those RFCs show that COSMETICBOT is not infringed on w.r.t. TED links, but it is usually better to show such a priori.
I suppose I should have caveated my comment regarding "so there should be a preference" as being my opinion, given that 2014 RFC, but consensus may since have changed and probably has, since the introduction of HTTPS-only Wikimedia. Regardless, without a separate RFC, use the consensus result from January 2014 to decide what kind of links you want to make. -- Izno (talk) 17:14, 24 March 2016 (UTC)
- I'd like to reiterate that not every Wikipedia mirror uses HTTPS. Do not limit your scope to WMF owned servers. — Dispenser 19:53, 24 March 2016 (UTC)
Strip marker problems with nowiki tags
Whence came the oddness in infobox television episode?
Above | |
---|---|
Header |
Above | |
---|---|
Header |
Compare the infobox formatting in The Foretelling and The Archbishop - the title in the blue header in the infobox is larger and horizontally-centred in the latter (which is correct), but smaller and left aligned in the former (which is wrong, I think). I've recently made an (unrelated) edit to The Foretelling, so presumably it's showing the change there because the caches were flushed by my edit. Test editing The Archbishop shows the same defect in it, were it to be saved. The infobox by itself, in my sandbox, has the defect. So I think there's something gone wrong with the infobox template(s). That infobox is {{Infobox television episode}}, which depends on {{Infobox}}. I don't see a relevant change in the history of either. It's a pretty subtle change, so I can well understand how it can have been overlooked for some time. Can anyone see what might be causing this? -- Finlay McWalter··–·Talk 14:30, 11 March 2016 (UTC)
- Oddly, the issue is caused by the addition of {{abbr}}. See the current sandboxed version utilising the HTML entity
.
in place a a natural period character - Template:Infobox television episode/sandbox. This appears to be the fix. I would appreciate confirmation from other editors before pushing the change live. fredgandt 14:57, 11 March 2016 (UTC) - Request placed at the template talk page - awaiting feedback. Albeit a seemingly trivial change, look what a dot in the wrong place can do! fredgandt 15:03, 11 March 2016 (UTC)
-
- At least in my sandbox, your proposal doesn't seem to manifest as a fix ☹ Finlay McWalter··–·Talk 15:07, 11 March 2016 (UTC)
- Yeah, that's not good
. However, although not a fix, it is the problem. At least that's one part of the equation. I'll continue looking into it. fredgandt 15:15, 11 March 2016 (UTC)
- Yeah, that's not good
- At least in my sandbox, your proposal doesn't seem to manifest as a fix ☹ Finlay McWalter··–·Talk 15:07, 11 March 2016 (UTC)
-
-
-
- Whoever fixes this might also fix the centering of the title parameter in mobile view. – Jonesey95 (talk) 15:28, 11 March 2016 (UTC)
-
-
- Apparently whatever happened during my initial evaluation was an anomaly which I cannot duplicate; some kind of caching ghost or something. I thought it unusual that the use of a period in a simple template should be any problem, but that's what I saw. I will have another look at it in a while, but need to bathe my dog and rest my eyes (too many curly braces!). It's more than likely something more obvious that a stray period - like a style declaration -_- fredgandt 15:38, 11 March 2016 (UTC)
-
- We had a similar problem with {{Infobox television}} today. (See the discussion). The problem there seemed to be related to links to a subpage. The ability to customise the colour used in Infobox television was removed a long time ago but {{Infobox television/colour}} exists to allow 14 of the 37,122 articles using the infobox to still have differently coloured infoboxes. (I don't know why!) In order to solve the problem I simply commented out the links.[3] I don't know why it worked, as there have been no recent changes to the template and this has been working for years. --AussieLegend (✉) 15:44, 11 March 2016 (UTC)
-
- I've now made the same change at {{Infobox television episode}} and the problem seems to be fixed. Please hold all applause for the person who can explain why this fixed the problem, because I have no idea. --AussieLegend (✉)
- I believe there was some change to how nowiki tags are parsed since this seems to have fixed it. Frietjes (talk) 16:25, 11 March 2016 (UTC)
- another one and here. Frietjes (talk) 16:28, 11 March 2016 (UTC)
- I added two examples to show that it's <nowiki> tags that are causing the problem. Frietjes (talk) 16:32, 11 March 2016 (UTC)
- this may be a _major_ problem considering how many of these color templates are using <nowiki> tags, e.g., all the meta/color templates ... Frietjes (talk) 16:35, 11 March 2016 (UTC)
- Yep, someone has changed how the nowiki (and perhaps other) stripmarkers are rendered. This is a percent encoded version of a nowiki stripmarker:
%7F%27%22%60UNIQ--nowiki-0000000E-QINU%60%22%27%7F
– the%27%22%60
and%60%22%27
are new
- The previous version was just
%7FUNIQ--nowiki-...-QINU%7F
- If they changed this, no doubt they changed how nowiki stripmarkers are handled. Was there a reason for this change?
- —Trappist the monk (talk) 17:03, 11 March 2016 (UTC)
- @Trappist the monk: The weird "nowiki" text occurs when you put a "ref" tag after the pipe in a piped link: [[Main Page|<ref>https://en.wikipedia.org/wiki/Main_Page</ref>]] displays as '"`UNIQ--nowiki-0000000A-QINU`"'1'"`UNIQ--nowiki-0000000B-QINU`"'. 63.251.215.25 (talk) 17:24, 11 March 2016 (UTC)
- Yep, someone has changed how the nowiki (and perhaps other) stripmarkers are rendered. This is a percent encoded version of a nowiki stripmarker:
- I've now made the same change at {{Infobox television episode}} and the problem seems to be fixed. Please hold all applause for the person who can explain why this fixed the problem, because I have no idea. --AussieLegend (✉)
References
-
-
-
-
-
- This case (along with the <math> in the link text below) both occur with the old strip-marker format on fresh installs of MediaWiki. It looks like this is an open issue (T27417) from 2010. CSteipp (WMF) (talk) 23:05, 18 March 2016 (UTC)
- 3425 templates with "color" or "colour" in the title and "nowiki" in the source. So this isn't going to be fixed manually. Right? fredgandt 17:38, 11 March 2016 (UTC)
- Fred_Gandt can you provide an example where one of the meta/color templates are now broken? all the places that I have checked thus far, e.g., Aberdeenshire#Governance and politics, are still working. also, Template:Infobox election and Template:Composition bar aren't broken, as far as I can tell (probably because they don't use {{infobox}} or {{navbox}}). but, there may be some uses which are broken? Frietjes (talk) 18:22, 11 March 2016 (UTC)
- @Frietjes: - Short answer = "no", which is my point. I'm not trudging through thousands of templates by hand to find which might be broken by this. A root or automated
fixsolution is needed; assuming the nowiki handling isn't broken, but rather is changed - I'd like to think this problem is an edge case which needs a special solution.
- @Frietjes: - Short answer = "no", which is my point. I'm not trudging through thousands of templates by hand to find which might be broken by this. A root or automated
- Fred_Gandt can you provide an example where one of the meta/color templates are now broken? all the places that I have checked thus far, e.g., Aberdeenshire#Governance and politics, are still working. also, Template:Infobox election and Template:Composition bar aren't broken, as far as I can tell (probably because they don't use {{infobox}} or {{navbox}}). but, there may be some uses which are broken? Frietjes (talk) 18:22, 11 March 2016 (UTC)
-
-
-
-
- It seems that with vast numbers of these meta/colo[u]r templates, it would be prudent to scrap them all and utilise MediaWiki:Common.css to apply classes. The argument of course will be that only admin can edit it, but that shouldn't be a problem (all things considered). fredgandt 07:50, 12 March 2016 (UTC)
mw.html?
Example 1 |
---|
Example 2 |
---|
Example 3
|
---|
the first two infobox examples used to render the same. the odd thing is that example 3 works, which makes me think that it's a combination of nowiki tags and the HTML builder (mw.html) that's barfing? checking further, I get some interesting results from the following
Input | Output |
---|---|
{{str left|{{Green Party (United States)/meta/color}}|5}} | |
{{str left|#0BDA51|5}} |
|
{{#invoke:string|sub|{{Green Party (United States)/meta/color}}|1|5}} | '"`U |
{{#invoke:string|sub|#0BDA51|1|5}} |
|
{{#invoke:string|len|{{Green Party (United States)/meta/color}}}} | 34 |
{{#invoke:string|len|#0BDA51}} | 7 |
Frietjes (talk) 22:31, 11 March 2016 (UTC)
This is the Example 1 infobox output according to Special:ExpandTemplates:
<table class="infobox" style="width:22em"><tr><th colspan="2" style="text-align:center;font-size:125%;font-weight:bold;border-bottom:2px solid ?'"`UNIQ--nowiki-00000000-QINU`"'?;">Example 1</th></tr></table>
and it's accompnying raw html output window:
<table class="infobox" style="width:22em"><tr><th colspan="2" style="text-align:center;font-size:125%;font-weight:bold;border-bottom:2px solid ?'"`UNIQ--nowiki-00000000-QINU`"'?;">Example 1</th></tr></table>
This is the output when the infobox is wrapped in {{code}}
<table class="infobox" style="width:22em"><tr><th colspan="2" style="text-align:center;font-size:125%;font-weight:bold;border-bottom:2px solid #0BDA51;">Example 1</th></tr></table>
This is the output as it is in my browser's source:
<table class="infobox" style="width:22em"> <tr> <th colspan="2" style="/* invalid control char */">Example 1</th> </tr> </table>
—Trappist the monk (talk) 23:32, 11 March 2016 (UTC)
-
- It looks like the strip markers are being changed to
/* invalid control char */
by HTML Tidy. That would explain why they appear in the HTML for the Special:ExpandTemplates preview but not in the HTML for this page. The change in nowiki tag behaviour doesn't seem to be caused by Lua. Strip markers have always been visible - and editable - from Lua, and Frietjes' example of{{#invoke:string|sub|{{Green Party (United States)/meta/color}}|1|5}}
would have worked the same way before. The nowiki tags are converted to strip markers before they are passed to Lua, and MediaWiki converts them into whatever they are supposed to be after they are returned back from Lua. If you edit them while they are in Lua then they won't be recognised properly by MediaWiki after they are returned, which is what is happening in Frietjes' example here - the remaining characters left after the operation on the strip marker are just being treated as normal wikitext. The change in the nowiki tag behaviour seems to have something to do with how the strip markers are processed after they have been returned from #invoke, or from other templates or parser functions. — Mr. Stradivarius ♪ talk ♪ 02:18, 12 March 2016 (UTC)- Mr. Stradivarius, it seems to be #invoke (and padleft?) and not templates in general. as far as I can tell, {{Infobox election}} isn't having any problems, but I had to change {{Infobox political party}} to use the div hack. Frietjes (talk) 14:10, 12 March 2016 (UTC)
- It looks like the strip markers are being changed to
Hi Folks. My fault about changing the format of the UNIQ markers. I can confirm it was an intentional change, but I did not anticipate it would cause these problems (Sorry!). I am hopeful we will have this issue resolved by the end of Monday. User:Mr. Stradivarius's explanation above about why things are different in Special:Expandtemplates is a good guess, but not entirely right. The reason that Special:Expandtemplates is returning different results, is due to subtle differences between it and normal pages. Special:Expandtemplates parses stuff by first expanding all templates, and then in a second step, parsing the expanded templates to html (Normal pages do it all in one step). This is mostly the same as normal pages, except that it converts {{#tag:syntaxhightlight|...}} into <syntaxhighlight> instead of interpreting directly. Additionally Ascii delete (aka F;) is removed at the beginning of each step, and UNIQ tags might not remain valid between each step. Last of all, I believe tidy is now applied to the output of Special:Expandtemplates, and the invalid control character thing comes from MW not tidy. BWolff (WMF) (talk) 04:33, 14 March 2016 (UTC)
- What does I can confirm it was an intentional change, but I did not anticipate it would cause these problems (Sorry!). I am hopeful we will have this issue resolved by the end of Monday really mean? Why was it necessary to change the format of the stripmarkers? Does the ...resolved by the end of Monday mean that there will be additional changes? If so, what are they? Have you made a note in the code to warn future editors of these problems so that similar situations can be avoided?
- —Trappist the monk (talk) 11:45, 14 March 2016 (UTC)
- That he is a developer who says sorry for introducing an unexpected side-effect, and that he takes ownership of solving it, so that other ppl don't have to worry. —TheDJ (talk • contribs) 11:56, 14 March 2016 (UTC)
- Yeah, I got that and I appreciate it. Perhaps my quote is too long. What is not clear, to me anyway, is: I am hopeful we will have this issue resolved by the end of Monday. All of the subsequent questions that I asked are about that. I asked because, apparently, the intentional change (whatever that is) is still incomplete, may or may not be complete today, and so may yet further break existing templates and modules or rebreak those that have been 'fixed' to accommodate the intentional change.
- —Trappist the monk (talk) 13:13, 14 March 2016 (UTC)
- It means 1 of 2 things will happen: Either A: the change in strip markers will be temporarily reverted until we are sure we are not accidentally beaking anything. (This should not break any of the template fixes, as they were all back compatible, afaik). Or B: we will try to fix the issues identified. My proposed fix for these issues would be to make it so that syntaxhighlight always removes strip markers before highlighting (esentially making the extension treat nowiki the same as normal text). And making mw.html not mess with strip markers it puts in attributes. Ive been assuming that while the most pressing examples have been worked around , it is still causing problems and wikipedia would want this issue resolved quickly. If everything has basically been fixed and nobody's worried about this anymore, please let me know. BWolff (WMF) (talk) 14:20, 14 March 2016 (UTC)
- The change of stripmarker form from (these shown percent encoded to include the delete characters):
%7FUNIQ--<name>-...-QINU%7F
- to
%7F%27%22%60UNIQ--<name>-...-QINU%60%22%27%7F
- where
<name>
isgallery
,math
,nowiki
,pre
,ref
and...
is the unique identifier, was felt beyond the templates identified here. Module:Convert uses a pattern to discover<ref>...</ref>
tags used within{{convert}}
templates. Module:Citation/CS1 uses a similar pattern to prevent the inclusion of stripmarkers in the metadata that are part of each cs1|2 template rendering. Similarly, that module also relies on stripmarker detection to create simplified but meaningful representations of equations wrapped in<math>...</math>
tags when they are made part of the metadata – typically journal article titles.
- The change of stripmarker form from (these shown percent encoded to include the delete characters):
-
- What was the purpose and benefit of making the stripmarkers more unique by the additions of '"` and `"'? You mentioned 'we'; is there a centralized discussion related to the stripmarker form change that I can read?
- —Trappist the monk (talk) 15:44, 14 March 2016 (UTC)
- "We" is the Wikimedia Security Team, so I also share responsibility for this, and add my apology. We're working on fixing an issue related to the strip markers, and we'll make the issue public once the fix is released. It's unfortunately a difficult balance to socialize that we need need to make a significant change when we don't want to make the details of the vulnerability public before we have the fix in place. I've just deployed the fix for Scribunto, so hopefully this particular situation has improved. CSteipp (WMF) (talk) 17:01, 14 March 2016 (UTC)
- Ah, understood. Do report back when the 'issue' is fixed, please.
- —Trappist the monk (talk) 13:34, 15 March 2016 (UTC)
- "We" is the Wikimedia Security Team, so I also share responsibility for this, and add my apology. We're working on fixing an issue related to the strip markers, and we'll make the issue public once the fix is released. It's unfortunately a difficult balance to socialize that we need need to make a significant change when we don't want to make the details of the vulnerability public before we have the fix in place. I've just deployed the fix for Scribunto, so hopefully this particular situation has improved. CSteipp (WMF) (talk) 17:01, 14 March 2016 (UTC)
- It means 1 of 2 things will happen: Either A: the change in strip markers will be temporarily reverted until we are sure we are not accidentally beaking anything. (This should not break any of the template fixes, as they were all back compatible, afaik). Or B: we will try to fix the issues identified. My proposed fix for these issues would be to make it so that syntaxhighlight always removes strip markers before highlighting (esentially making the extension treat nowiki the same as normal text). And making mw.html not mess with strip markers it puts in attributes. Ive been assuming that while the most pressing examples have been worked around , it is still causing problems and wikipedia would want this issue resolved quickly. If everything has basically been fixed and nobody's worried about this anymore, please let me know. BWolff (WMF) (talk) 14:20, 14 March 2016 (UTC)
- That he is a developer who says sorry for introducing an unexpected side-effect, and that he takes ownership of solving it, so that other ppl don't have to worry. —TheDJ (talk • contribs) 11:56, 14 March 2016 (UTC)
Infobox on Dutch language looks broken
Hi! The Dutch language article's infobox is kind of not correct looking, because the name of the language (Dutch / Nederlands) is in fairly small print and left-justified, making it hard to read. Click this link to see a screenshot (PNG, 275kb) of the issue. The <th> and <td> tags have style="/* invalid control char */"
which looks wrong. The issue happens in Firefox Developer Edition 47.0a2, and also appears to happen in Google Chrome "Version 48.0.2564.116 (64-bit)". Could this be fixed? Thanks :) Goldenshimmer (talk) 20:54, 12 March 2016 (UTC)
- @Goldenshimmer: This edit has fixed Dutch language but it's knackered the template's own doc page. I've not undone my edit: given the choice of broken article or broken template doc, I'd go with the latter. --Redrose64 (talk) 21:14, 12 March 2016 (UTC)
- Thanks @Redrose64! Yeah, I would agree that broken article is much more important 😛. I feel something of a fool now, since I skimmed this discussion yesterday, but didn't make the connection when I saw the issue today, even though I looked for a report… i think i might have assumed that it had to do with Template:Infobox language specifically…. Anywho, thanks again :) Goldenshimmer (talk) 21:33, 12 March 2016 (UTC)
- I made a further change, which does not affect Dutch language but has fixed the documentation. The sum of my two edits is this: every instance of
<nowiki>#rrggbb</nowiki>
has become/**/#rrggbb
- The
/**/
is a valid CSS comment, and it's passed through untouched by the MediaWiki parser, and its presence hides the hashes so that they're not converted to ordered-list item markers, but remain valid RGB hex triplet markers. --Redrose64 (talk) 21:38, 12 March 2016 (UTC) - Seems that the
bgcolor=
attribute of table cells doesn't like that technique. Never mind; it's obsolete in HTML5 anyway, so an edit like this is also necessary. --Redrose64 (talk) 21:50, 12 March 2016 (UTC)
- I made a further change, which does not affect Dutch language but has fixed the documentation. The sum of my two edits is this: every instance of
- Thanks @Redrose64! Yeah, I would agree that broken article is much more important 😛. I feel something of a fool now, since I skimmed this discussion yesterday, but didn't make the connection when I saw the issue today, even though I looked for a report… i think i might have assumed that it had to do with Template:Infobox language specifically…. Anywho, thanks again :) Goldenshimmer (talk) 21:33, 12 March 2016 (UTC)
Redirects from plurals
Template:R from plural and the pages transcluding it such as numbers say '"`UNIQ--nowiki-00000000-QINU`"'
instead of [[link]]s
. GeoffreyT2000 (talk) 00:12, 13 March 2016 (UTC)
- I wonder if this is the same issue causing the infobox fuckery above. The Template:R from plural page for me seems to contain the same delete character (0x7f) that shows up in the discussion of the broken infoboxes. I'm seeing: <snip />
Huh, the deletes are turning into 0x3f for some weird reason in the saved page, so let's try this: <snip /> Dafuq? I get why the entity I left the semicolon off of isn't working, but the first one? Let's try this again…This redirect link is used for convenience; it is often preferable to add the plural directly after the link (for example, '"`UNIQ--nowiki-00000000-QINU`"'). However, do not replace these redirected links with a simpler link unless the page is updated for another reason (see WP:NOTBROKEN).
- I can't get those entities to work for some weird reason (I'm probably missing something obvious…) so yeah, just use your imagination that the
""
s are actually, ya know, like, 0x7f. Goldenshimmer (talk) 01:08, 13 March 2016 (UTC)- (Edited comments again, cause I seem to have a semicolon deficiency today…. Goldenshimmer (talk) 01:10, 13 March 2016 (UTC))
- I can't get those entities to work for some weird reason (I'm probably missing something obvious…) so yeah, just use your imagination that the
Examples of the problem that lead to the above (the third example works with no problem):
{{code|<nowiki>[[link]]s</nowiki>}}
→[[link]]s
{{#tag:syntaxhighlight|<nowiki>hello</nowiki>|lang="text"}}
→hello
{{#tag:syntaxhighlight|<nowiki>hello</nowiki>}}
→hello
A workaround would be to remove the nowiki and replace "[" with [
, but a fix for the underlying problem is needed. Johnuniq (talk) 01:22, 13 March 2016 (UTC)
- @GeoffreyT2000, Goldenshimmer, and Johnuniq: No need to encode the square brackets; if you check the documentation for
{{code}}
, it says "the template uses the<syntaxhighlight>
tag with the attributeenclose="none"
. This works like the combination of the<code>
and<nowiki>
tags", therefore, there is no need to provide your own<nowiki></nowiki>
tags, so I removed them. --Redrose64 (talk) 10:26, 13 March 2016 (UTC)- OK, I did this search for "UNIQ--nowiki" and got four hits. Two were
<nowiki>...</nowiki>
inside{{code}}
; two were<ref>...</ref>
inside wikilinks. All fixed. --Redrose64 (talk) 10:57, 13 March 2016 (UTC)- Thanks, that has fixed Template:R from plural. However, my point was to show the wikitext in the template that used to work and which now results in a broken strip marker. Perhaps the nowiki should never have been in {{code}}, but should placing it there cause a strip marker to become visible? Johnuniq (talk) 10:59, 13 March 2016 (UTC)
- @Redrose64: I wasn't trying to encode the square brackets. Rather, I was trying to encode the delete character U+007F. Goldenshimmer (talk) 17:48, 13 March 2016 (UTC)
- Indeed; but see comment by Johnuniq above, beginning "A workaround would be ...". --Redrose64 (talk) 18:09, 13 March 2016 (UTC)
- Oh, got it. Thought the ping meant the comment was responding to mine too, :P, thanks :) Goldenshimmer (talk) 21:24, 13 March 2016 (UTC)
- It was a reply to everybody who had posted before me; you and Johnuniq both seemed to be going to a lot of trouble (with various encodings; re-editings of the posts here, comments like "I can't get those entities to work") to find what was really a very simple solution - simply omit the
<nowiki></nowiki>
tags. I mentioned GeoffreyT2000 as well by way of saying "fixed". --Redrose64 (talk) 21:35, 13 March 2016 (UTC)- To Redrose64: It's a lot of trouble to remove nowiki tags from everywhere, for example, I caught your edit to {{R from plural}}, but what about its category, which still shows the superfluous code as of 18:50, 14 March 2016 (UTC)? There are times when the nowiki tags may be needed, e.g., when using the {{Code}} template to render
tlx|
, which comes out as'"`UNIQ--nowiki-00000034-QINU`"'
. Omit the nowiki tags and the pipe disappears, as in
. Perhaps a better idea would be to leave the code alone and wait for the devs instead of telling people to omit nowiki tags, which may lead to more problems? Follow Jimbo! Paine 18:50, 14 March 2016 (UTC)tlx
- Fixing the cat page is easy. When do you need to put
tlx|
inside{{code}}
? Do you have examples of pages where this is done? --Redrose64 (talk) 20:03, 14 March 2016 (UTC)- Being an easy fix misses my point. The loss of the pipe in my example above is a subtle loss that may go unnoticed, and there are plenty other possible instances where the removal of nowiki tags might cause subtle yet important differences. An example of the
tlx|
inside{{code}}
is actually how I found this problem that led me to this discussion. It's on my user talk page in a discussion with Martin at the end when I disabled some template loops. Point is, there should be no encouraging people to remove code (nowiki tags) until the devs have worked their magic. Follow Jimbo! Paine 23:32, 14 March 2016 (UTC)- Can we be sure that the devs will return things to the previous state? We can't. But if they eventually do, how long will this problem (which might be temporary) last? Do we sit around waiting and/or complaining, or do we assume that it may take months, and actually get off our arses and do something about it ourselves?
- This bug/feature/effect is highlighting misused markup. Too often I see people using complicated techniques for situations that don't merit them - for instance, you don't need a
<nowiki>...</nowiki>
inside{{code}}
when<code>...</code>
does the whole job, like this. --Redrose64 (talk) 00:18, 15 March 2016 (UTC)- Thank you – I changed that last one back so it's easy for me to tell when the problem is fixed. This shouldn't be too difficult for the devs to fix quickly. I just think we're asking for more problems if we encourage the removal of nowiki tags, since subtle diffs could be missed. Some editors are more careful than others. It'll soon be a moot point, I trust. Paine 09:18, 15 March 2016 (UTC)
- Being an easy fix misses my point. The loss of the pipe in my example above is a subtle loss that may go unnoticed, and there are plenty other possible instances where the removal of nowiki tags might cause subtle yet important differences. An example of the
- Fixing the cat page is easy. When do you need to put
- To Redrose64: It's a lot of trouble to remove nowiki tags from everywhere, for example, I caught your edit to {{R from plural}}, but what about its category, which still shows the superfluous code as of 18:50, 14 March 2016 (UTC)? There are times when the nowiki tags may be needed, e.g., when using the {{Code}} template to render
- It was a reply to everybody who had posted before me; you and Johnuniq both seemed to be going to a lot of trouble (with various encodings; re-editings of the posts here, comments like "I can't get those entities to work") to find what was really a very simple solution - simply omit the
- Oh, got it. Thought the ping meant the comment was responding to mine too, :P, thanks :) Goldenshimmer (talk) 21:24, 13 March 2016 (UTC)
- Indeed; but see comment by Johnuniq above, beginning "A workaround would be ...". --Redrose64 (talk) 18:09, 13 March 2016 (UTC)
- OK, I did this search for "UNIQ--nowiki" and got four hits. Two were
One possible alternative, is if the lang is unspecified for {{code}}, to use <code>{{#tag:nowiki|{{{1}}}}}</code> instead of using #tag:syntaxhighlight. This would handle embedded nowiki's better than syntaxhighlight currently does. Bawolff (talk) 22:05, 15 March 2016 (UTC)
- Yes, I sandboxed that and it works well on my talk page; however, since {{Code}} is but one part of this problem, shouldn't we be looking for a fix that allows #tag:syntaxhighlight to work as well as it did a few days ago? so other issues reported above will also be fixed? Paine 18:42, 17 March 2016 (UTC)
Math inside wikilinks broken?
For markup like (markup: [[Mathematics|<math>e^{i\pi}=-1</math>]]; should look like: eiπ = −1) where a wikilink encloses a mathematical formula, I'm seeing renderings like ?'"`UNIQ--postMath-00000001-QINU`"'?. This is with Chrome under OS X with the MathML/SVG-fallback option enabled. Is it happening more widely? —David Eppstein (talk) 20:46, 17 March 2016 (UTC)
- The link works, it just isn't blue? 90.199.52.141 (talk) 20:49, 17 March 2016 (UTC)
- Under PNG it looks fine, but when I switch to MathML in the Preferences, the first and third wiki links have the UNIQ...QINU problem. This is also with OSX, Chrome Version 49.0.2623.87 (64-bit). So, verified, but I don't know the solution. --Mark viking (talk) 21:28, 17 March 2016 (UTC)
- I assume you know that this used to work? There have been a few discussions about broken strip markers recently. At #mw.html? above, BWolff (WMF) said "I am hopeful we will have this issue resolved by the end of Monday" although that was not in relation to math. BWolff might like to comment on this as well. The problem exists when "MathML with SVG or PNG fallback" is selected in Preferences for Firefox. Johnuniq (talk) 22:29, 17 March 2016 (UTC)
- Yes, stripmarker treatment has changed, I think in connection with phabricator:T103269. This has also caused problems with <math> in citation template parameters (such as article titles and quotations) but that's under control (fixed in the latest sandbox version of the citation templates, to be included in the next monthly update). —David Eppstein (talk) 23:16, 17 March 2016 (UTC)
- David Eppstein, I looked into how the strip marker change could have caused this, and it looks like this is a new case of an old, open issue-- T27417. If this only started recently, it might have been a change to the MathML processing. But I'm able to duplicate this issue on a fresh install of mediawiki, using the old strip-marker format, so the issue predates Bawolff's patch. CSteipp (WMF) (talk) 23:16, 18 March 2016 (UTC)
- Maybe a change to math processing exposed the math stripmarkers to the same problem that was already occurring with other kinds of stripmarkers? Anyway, thanks. Having a known bug to refer to for this saves the trouble of starting a new one. —David Eppstein (talk) 23:37, 18 March 2016 (UTC)
- David Eppstein, I looked into how the strip marker change could have caused this, and it looks like this is a new case of an old, open issue-- T27417. If this only started recently, it might have been a change to the MathML processing. But I'm able to duplicate this issue on a fresh install of mediawiki, using the old strip-marker format, so the issue predates Bawolff's patch. CSteipp (WMF) (talk) 23:16, 18 March 2016 (UTC)
- Yes, stripmarker treatment has changed, I think in connection with phabricator:T103269. This has also caused problems with <math> in citation template parameters (such as article titles and quotations) but that's under control (fixed in the latest sandbox version of the citation templates, to be included in the next monthly update). —David Eppstein (talk) 23:16, 17 March 2016 (UTC)
There is another bug for this specific problem, T130508.--Salix alba (talk): 16:36, 21 March 2016 (UTC)
May we get a firm timeline when this will be fixed?
I see this problem on template documentation pages almost everywhere I turn! Embrace neutralisms! Paine 14:47, 21 March 2016 (UTC)
- As it is related to a security issue, I very much doubt so. The fact that it is still there is proof enough that it is a rather troublesome problem to solve without reintroducing the security problem and thus logically a date cannot be given, because that would imply that the problem is predictable in complexity. —TheDJ (talk • contribs) 23:57, 22 March 2016 (UTC)
- I do apologize for the delay in getting this fixed. I've just deployed the fix for syntaxhighlighter, so {{code}} and {{bcode}} should be fixed now. I believe that was the major issues with the template documentation pages. If you're still seeing issues, can you point me to some examples? CSteipp (WMF) (talk) 22:24, 24 March 2016 (UTC)
- After looking into things again, it looks like the lua patch was dropped from the current deployment branch. That has been redeployed. So as of about 25 Mar 03:45 UTC, the issue with lua modules and the {{code}} templates should both be fixed, and things should be back to being parsed as they were prior to the strip marker change. Apologies, again, for the delay in getting this fixed. The next mediawiki release should be published soon as well, so we can make the issue behind this public. CSteipp (WMF) (talk) 04:02, 25 March 2016 (UTC)
- To BWolff (WMF) and CSteipp (WMF): Thank you beyond words for fixing this multiple-page damage! I knew it wouldn't take you long! Happy E-day (belatedly) and Best of Everything to You and Yours! Embrace neutralisms! Paine 13:59, 28 March 2016 (UTC)
- After looking into things again, it looks like the lua patch was dropped from the current deployment branch. That has been redeployed. So as of about 25 Mar 03:45 UTC, the issue with lua modules and the {{code}} templates should both be fixed, and things should be back to being parsed as they were prior to the strip marker change. Apologies, again, for the delay in getting this fixed. The next mediawiki release should be published soon as well, so we can make the issue behind this public. CSteipp (WMF) (talk) 04:02, 25 March 2016 (UTC)
- I do apologize for the delay in getting this fixed. I've just deployed the fix for syntaxhighlighter, so {{code}} and {{bcode}} should be fixed now. I believe that was the major issues with the template documentation pages. If you're still seeing issues, can you point me to some examples? CSteipp (WMF) (talk) 22:24, 24 March 2016 (UTC)
New (to me) mobile site - images in header
Sorry my Wikipedia-foo is failing me and I cannot find out where even to ask this. I've been using the mobile site on ios (not the app) and it has an image at the top of the screen, which is generally the same as the one in the infobox. Where is it pulling this from - Wikidata? Is it the image property on a page's wikidata entry? Two copies of the same image in close proximity is sub-optimal and would like to debug this. Thanks. Secretlondon (talk) 19:36, 20 March 2016 (UTC)
- I think mobile is using Extension:PageImages to select the "hero" image. --Izno (talk) 22:45, 20 March 2016 (UTC)
- What does that mean in practice? Where does it get the picture from? Secretlondon (talk) 20:35, 22 March 2016 (UTC)
- @Secretlondon: In a nutshell, it looks at the images in the article and tries to choose the best one. It almost always (but not always) chooses the first image. Things that mean it might not choose the first image include if the dimensions of the image are suboptimal (e.g. it's a very wide image) or if the image is non-free (ever since T124225 was implemented). --Dan Garry, Wikimedia Foundation (talk) 20:41, 22 March 2016 (UTC)
- Thanks. The problem here is that we have the same image twice in close succession, which doesn't look good. Secretlondon (talk) 20:26, 24 March 2016 (UTC)
- (edit conflict) A hero image is a prominent banner image. As to where the image comes from in this case, according to mw:Extension:PageImages, it grabs the first meaningful, freely usable image on the page, which is often the infobox image.
- There's also a Phabricator project here, which might be a more direct way to address the functionality. clpo13(talk) 20:42, 22 March 2016 (UTC)
- @Secretlondon: In a nutshell, it looks at the images in the article and tries to choose the best one. It almost always (but not always) chooses the first image. Things that mean it might not choose the first image include if the dimensions of the image are suboptimal (e.g. it's a very wide image) or if the image is non-free (ever since T124225 was implemented). --Dan Garry, Wikimedia Foundation (talk) 20:41, 22 March 2016 (UTC)
- What does that mean in practice? Where does it get the picture from? Secretlondon (talk) 20:35, 22 March 2016 (UTC)
Certain articles on the iOS Wikipedia app show wrong images
The article on the TV show House shows a picture of Sherlock Holmes in the search results as well as in top image spot, on the iOS app. This is only one of several images within the article, and not the first one. The first image in this article is of the House logo, which should be the one at the top as well as in the search results. How can I edit this? werewolf 23:33, 21 March 2016 (UTC) — Preceding unsigned comment added by Revirvlkodlaku (talk • contribs)
- The image is selected automatically and I wouldn't call it wrong as long as the image is actually in the article. It's just an unfortunate choice in some cases. I don't know how the image is selected. File:House logo.svg in House (TV series) is a public domain image so it's not omitted for copyright reasons. It's five times as wide as high and mobile search displays all the images in a square so that might be a reason it isn't chosen. PrimeHunter (talk) 09:45, 22 March 2016 (UTC)
Thanks for your contributions, PrimeHunter and Izno. The image may not be "wrong", but I don't think it's the correct image to use as a representation of the show, that's why I think it needs to be changed. Another example of this type of thing, as another Wikipedia user mentioned to me, is that of Agnes Boulton. The first image in her article is that of her husband, so the title image, as well as the one in the search results is her husband's photograph. I would say this is problematic as it doesn't correctly represent the article. How can we fix this? werewolf 01:29, 25 March 2016 (UTC) — Preceding unsigned comment added by Revirvlkodlaku (talk • contribs)
- This is caused by the community policy to limit use of non-free images (Wikipedia:Non-free_content#Exemptions), and and the resulting removal of non-free images from our images-API results (that power things like the lead image in apps). I agree with you that the user experience is noticeably diminished for some of our most popular pages: books, albums, movies, television.
- It is also true that the change to the API forces does not allow for discrimination by the feature that is calling the image. Apparently, image search in visual editor is equally impacted and this is not a navigational element, the same goes for the app 'lead image'.
- As mentioned here, I see 3 paths forward to alleviate the issue:
-
- try and revisit policy or ask for a re-intepretation of existing policy (complete 'fix')
- change API to flag image and let project/feature decide usage. This actually alleviates concerns around re-use. (partial fix)
- prevent non-lead image sections from appearing in results or let users over-ride image. This is captured here: https://phabricator.wikimedia.org/T87336 and here: https://phabricator.wikimedia.org/T91683. (least complete fix--users lose out on valuable visual queues provided by the non-free images and see inconsistency between preview image and page)
- Jkatz (WMF) (talk) 23:55, 25 March 2016 (UTC)
-
- @Jkatz (WMF): While this may be true in some instances, this is not what's happening here:
- The image File:House logo.svg in House (TV series) is free (public domain), but too wide. A non-lead image with a not immediately clear relation to the article is chosen instead. (I think it's unfortunate the image is discarded for this reason. It would still fit in a hovercard. And could still be made into a square thumbnail for search by extending the white background. Although picking File:Hugh Laurie 2009 crop.jpg would also be a good alternative.)
- The article Agnes Boulton does not have any image of Mrs. Boulton (free or non-free), so a non-lead image of Eugene O'Neill is chosen instead. (In this case no image would probably be better than an image of the wrong person.)
- —Ruud 00:42, 26 March 2016 (UTC)
- @Jkatz (WMF): While this may be true in some instances, this is not what's happening here:
Small improvement to standard Search Box
The current search box algorithm by Wikipedia for article searches implements a simple search with autofill option for linking to articles. Other major companies and institutions, like Amazon and others, who use similar search boxes offer the same feature, though they have significantly improved their versions to include a spelling correction facility to help users find their products and what they are looking for. It is fairly easy to implement an improved Wikipedia search box with simple spelling correction and perhaps it should be done. If someone misspells Dostoeievsky then they do not need to be told that their page does not exist or that a new page can be created. A simple spelling fix suggestion in the search box might be more useful and more user friendly. The current Wikipedia subtext of "Did you mean... option is the poor man version of what companies like Amazon and others have usefully implemented for their users. Fountains-of-Paris (talk) 16:23, 22 March 2016 (UTC)
- This is being worked on by the Discovery team. I'm not sure which exact task it is, but [4] is the project board on Phabricator. --Izno (talk) 16:59, 22 March 2016 (UTC)
- Hi Fountains-of-Paris. What timing! The Discovery department just updated the 'smarts' behind the search-as-you-type "completion suggester" last week. The update brings better handling of spelling mistakes as you mentioned. You can read more about the update on the Wikimedia Blog. CKoerner (WMF) (talk) 17:50, 22 March 2016 (UTC)
- That's a nice link and it works for the correction of their test case of "David Bowtie" corrected to "David Bowie". I then tried it for my example of Dostoyevsky by typing the letter next to it by accident "Fostoyevsky" and it went back to "no page exists" mode. Do the coders of the new version know about this glitch that corrections only seem to catch the last letters of mistyped search box entries? Fountains-of-Paris (talk) 19:35, 22 March 2016 (UTC)
I quote:
ebernhardson> thedj: we don't do fuzziness on the first letter, it was too expensive
ebernhardson> thedj: it would basically require iterating every possible article
ebernhardson> the short answer is a suggest takes 10-12ms of server time by handling the first character, and 2-3 ms by forcing the first character to not be fuzzy. This makes a very large change in the number of servers required to serve this feature
Hope that answers your question. —TheDJ (talk • contribs) 17:06, 23 March 2016 (UTC)
- @TheDJ and CKoerner (WMF): That clarifies a lot if you are saying that the algorithm currently being used is fixed at a 1-character or 2-character look-back for error correction in the simple search box. If I am reading this correctly, then could one of you tell me if it is an n-character look-back algorithm which is now being used starting at the end of the typed search box item which is limited to a 2-3 ms response time maximum? Or is it some other search-correction strategy? Fountains-of-Paris (talk) 15:03, 25 March 2016 (UTC)
Tracking multiple transclusions
Is there any way to track pages that transclude one template but not another? In reality, any page that uses {{Episode list}} should also be using {{Episode table}}, but many television series pages still use raw code for the table header, and they should be converted. So, is there any way to track pages that use {{Episode list}} but do not use {{Episode table}}? Alex|The|Whovian? 03:37, 24 March 2016 (UTC)
- According to the math: this minus this = 5575, most of the transclusions of
{{Episode list}}
aren't accompanied by transclusions of{{Episode table}}
. This doesn't tell you exactly which, but most is a simple place to start. fredgandt 04:41, 24 March 2016 (UTC) - (edit conflict) @AlexTheWhovian: You can use AWB's list comparer. I've dumped the list here. (Please move it if you would like to keep it.) — JJMC89 (T·C) 04:43, 24 March 2016 (UTC)
- Thank you both. I wasn't aware of AWB's list comparer, but that's mighty handy. I've moved the page to my own userspace. Only the first list is necessary in this case; most of the content in the second list is because those particular articles use {{Episode list/sublist}} rather than {{Episode list}}. Alex|The|Whovian? 04:58, 24 March 2016 (UTC)
- to the original question: the inbuilt search is powerful enough to answer this question. it has codes, such as "hastemplate:", "incategory:", "linksto:", "intitle:", "insource:" (the colon is essential), and probably a few more. when you use more than one, "and" relationship is assumed. each of these can be prefixed with - (minus character) to signal "not". so what you want, in this case, is Special:Search/hastemplate:"Episode list" -hastemplate:"Episode table" (the quotes are not essential: if the template name has no spaces, you can simply drop the quotes, and if it *does* contain spaces, you can either use quotes like in the example, or you can substitute each space with an underscore). note that you can do "normal" searches in the subset of pages defined by the "codes". you can also use regex, but this is only available when using insource: keyword (i.e., you can use regex to search in the wikicode, but not in article parsed text). peace - קיפודנחש (aka kipod) (talk) 05:21, 24 March 2016 (UTC)
- Thank you both. I wasn't aware of AWB's list comparer, but that's mighty handy. I've moved the page to my own userspace. Only the first list is necessary in this case; most of the content in the second list is because those particular articles use {{Episode list/sublist}} rather than {{Episode list}}. Alex|The|Whovian? 04:58, 24 March 2016 (UTC)
Wikipedia email
My computer is an 18 months old Mac with the current software and my browser is Safari. My email doesn't work when I email another editor and I suspect it does not receive emails from other editors. There was a time when it did. Quite recently I got it to work once - I think because I got an admin to email me and after that I managed to send one message and then no more will go through. Although when it does go through I receive a copy of my message, when I get no copy I Now know the message has not in fact gone. I have re-checked ny preferences again and again. I occasionally fail to receive emailed notifications of changes and that is a puzzle too. Please tell me what I might be doing wrong. Thanks and regards, Eddaido (talk) 04:29, 24 March 2016 (UTC)
- Do you know which mail providers were involved on both sides? Something like Yahoo, GMail, or Hotmail? Asking because of bugs like phab:T58414... --AKlapper (WMF) (talk) 11:50, 24 March 2016 (UTC)
- Try mailing me. I never have problems receiving mails. I have mailed you and got a copy in seconds. I think mails are sent but don't reach some receivers. PrimeHunter (talk) 12:22, 24 March 2016 (UTC)
- From email me to you sending now
- From email me to you sending now
Sorry its 1:22am here and I missed your question. The answer is Yahoo. Is there a way to fix it? Many thanks for getting involved. Eddaido (talk) 12:26, 24 March 2016 (UTC)
-
- I got your mail. You can use another mail provider for your Wikipedia account. See Comparison of webmail providers for some free options. PrimeHunter (talk) 12:33, 24 March 2016 (UTC)
- @Eddaido: Yahoo has been a long-term problem for mails sent from Wikipedia, there's plenty in the archives of this page. See also phab:T66795. The only guaranteed solution is not to use Yahoo. --Redrose64 (talk) 20:01, 24 March 2016 (UTC)
- I got your mail. You can use another mail provider for your Wikipedia account. See Comparison of webmail providers for some free options. PrimeHunter (talk) 12:33, 24 March 2016 (UTC)
Template issue
I want to duplicate a feature of the Template:Infobox military conflict in the Template:Infobox civil conflict, but don't know how to do it.
The feature I want to duplicate is a parameter called "campaignbox". It is an "optional field for appending a campaignbox template to the bottom of the infobox, which allows both boxes to float as a single element (useful if there are subsequent left floating images, which would otherwise not be able to float above the campaign box)."
I will also need to create a Template:Campaignbox for "civil" conflicts. The existing one appears to be solely for "military" conflicts. Thanks. Mitchumch (talk) 16:40, 24 March 2016 (UTC)
- Mitchumch, the whole "Template:Campaignbox" is just a {{sidebar}} with military colouring. you should be able to use a standard {{sidebar}} template for a non-military series. let me know on my talk page if you have a specific example. however, I do understand the desire to glue the sidebox to the bottom of the infobox to allow left floating elements to float past the block, so I have added a
|sidebox=
parameter to the civil conflict template. Frietjes (talk) 14:13, 26 March 2016 (UTC)
Wrong page count in category
Category:Days of the year says "The following 200 pages are in this category, out of 354 total." when it actually contains 366 pages, one for each day, including leap day on February 29. GeoffreyT2000 (talk) 00:31, 25 March 2016 (UTC)
- This is a longstanding issue. T18036, I believe. – Jonesey95 (talk) 07:14, 25 March 2016 (UTC)
- It's also come up on this page before, it'll be in the archives but I'm not sure what to search for. One thing I am certain of is that my signature is on the most recent relevant discussion. --Redrose64 (talk) 09:21, 25 March 2016 (UTC)
- WP:Village pump (technical)/Archive 130#Count of pages in the category (October 2014)
- toollabs:erwin85/categorycount.php --Pipetricker (talk) 10:01, 25 March 2016 (UTC)
- I looked at that thread an hour or so ago, but it's not the right one - it doesn't concern the issue where physically counting the page links below the heading 'Pages in category "Days of the year"' yields a figure that is different from the figure given by 'out of 354 total'. The latter figure is a match for the 354 given by
{{PAGESINCATEGORY:Days of the year}}
. There is a thread, earlier than Archive 130 (I've searched all subsequent archives today), that specifically concerns a discrepancy between the figures. --Redrose64 (talk) 10:18, 25 March 2016 (UTC)
- I looked at that thread an hour or so ago, but it's not the right one - it doesn't concern the issue where physically counting the page links below the heading 'Pages in category "Days of the year"' yields a figure that is different from the figure given by 'out of 354 total'. The latter figure is a match for the 354 given by
- It's also come up on this page before, it'll be in the archives but I'm not sure what to search for. One thing I am certain of is that my signature is on the most recent relevant discussion. --Redrose64 (talk) 09:21, 25 March 2016 (UTC)
ru-wiki LinkSearch / api exturlusage issue
I'm investigating T130912. Not being a Russian speaker doesn't make it too easy. Anyway, user of ru-wiki reports LinkSearch not working in AWB, which we do via mediawiki API. Seems like results from Special:LinkSearch page on ru-wiki web here give correct results and various mainspace pages for the "рус.башкирская-энциклопедия.рф" site. However with what I think is the equivalent search via the API here I only see 1 result in namespace 1 (I have simplified the call used, this simplified version shows the issue). So ostensibly Special:LinkSearch and equivalent API function (exturlusage) not giving same results. So could somebody please shed any light, is my API query somehow wrong or is there an API issue here, or something else? Thanks Rjwilmsi 09:14, 26 March 2016 (UTC)
Breaking change: wikibits
Beginning with MediaWiki 1.27 (April 2016) wikibits Javascript module will no longer load by default. In MediaWiki 1.28 (November 2016) it will be removed entirely. It is advised that code using wikibits be refactored to use modern replacements. See this email for more details.
wikibits identifiers |
---|
|
— JJMC89 (T·C) 13:16, 26 March 2016 (UTC)
- Is there a list of often-used gadgets and user scripts that will break once this change is rolled out? MER-C 14:14, 26 March 2016 (UTC)
- Well the loss of
importScript
will affect virtually everyone who calls any scripts on their own js pages. Nthep (talk) 14:50, 26 March 2016 (UTC) - There is no replacement for
importScript
. 19:58, 26 March 2016 (UTC) — Preceding unsigned comment added by Ruslik0 (talk • contribs)- importScript should be replaced by
mw.loader.load
. I think it was a long-term plan to do this replace. --Edgars2007 (talk/contribs) 21:15, 26 March 2016 (UTC)- I've successfully upgraded User:John of Reading/common.js by hand. I wonder if a bot could do this? There could be about 27,000 affected pages. -- John of Reading (talk) 21:17, 26 March 2016 (UTC)
- Since only administrators and interface editors can edit other users' js and css pages, the bot will have to be either an administrator or an interface editor. Preferably, the bot should be a global bot and an interface editor because the change also applies to the other wikis. GeoffreyT2000 (talk) 21:53, 26 March 2016 (UTC)
- I wouldn't be keen on a bot doing this. I've changed the use of
importScript
on my own .js pages and it didn't take much working out. What is needed is a much wider advertising of the change and how to fix things to users whose pages will be affected - that is a task for a bot. Nthep (talk) 23:07, 26 March 2016 (UTC)- Agreed, it's more an issue of knowing this needs to happen. Anyone capable of editing their .js pages to add a script can just as easily change the statements to the new function call, but if they don't know that they need to, then that's a problem. Also, all the documentation pages for scripts will need to be updated so new users don't add outdated code. Since this affects anyone using scripts, maybe a watchlist notification linking here or to an information page with steps for migrating? clpo13(talk) 23:11, 26 March 2016 (UTC)
- I agree this needs wider notice and have posted at WP:AN. Here's a bunch of gadgets that need to be updated. MER-C 13:01, 27 March 2016 (UTC)
- Agreed, it's more an issue of knowing this needs to happen. Anyone capable of editing their .js pages to add a script can just as easily change the statements to the new function call, but if they don't know that they need to, then that's a problem. Also, all the documentation pages for scripts will need to be updated so new users don't add outdated code. Since this affects anyone using scripts, maybe a watchlist notification linking here or to an information page with steps for migrating? clpo13(talk) 23:11, 26 March 2016 (UTC)
- I wouldn't be keen on a bot doing this. I've changed the use of
- Since only administrators and interface editors can edit other users' js and css pages, the bot will have to be either an administrator or an interface editor. Preferably, the bot should be a global bot and an interface editor because the change also applies to the other wikis. GeoffreyT2000 (talk) 21:53, 26 March 2016 (UTC)
- I've successfully upgraded User:John of Reading/common.js by hand. I wonder if a bot could do this? There could be about 27,000 affected pages. -- John of Reading (talk) 21:17, 26 March 2016 (UTC)
- importScript should be replaced by
- Well the loss of
I agree; while mw.loader
is generally good, importScript
's desirable simplicity in referencing on-wiki JS files is missing in mw.loader.load
. Here's a quick hack for those too lazy to properly update that restores it:
window.importScript = function (importPage) {
var wg = mw.config.get(["wgServer", "wgScript"]),
importUrl = wg.wgServer + wg.wgScript + "?title=" + mw.util.wikiUrlencode(importPage) +
"&action=raw&ctype=text/javascript";
return mw.loader.load(importUrl);
};
Note that scripts may still have errors from implied globals, because of the way mw.loader.load()
wraps its output. These can be fixed by making the global explicit by specifying it as a property of the window
object, as in the snippet above. {{Nihiltres |talk |edits}} 23:55, 27 March 2016 (UTC)
-
- So I just need to add this snippet to the top of my .js and importScript will continue to work? Is there a reason importScript is going away, it seems rather useful and more elegant? –xenotalk 18:55, 28 March 2016 (UTC)
- something is wrong here, IMO: for other stuff that were obsoleted, we received console.log messages (at least when running with "debug=true" address-line parameter), reporting this obsolescence. anyone using wiked or wikeddiff gadgets can see tons of such report in JS console, complaining about direct access to wgXxxxx global variables.
- however, importScript() is *not* marked as obsolete even now, and there's no report in js console telling users to replace it. announcing something like this on WP:VPT in enwiki is grossly inadequate. i can see no justification for such a breaking change.
- the fact that there is no adequate substitute for importScript anywhere in mw libraries is even more puzzling (for instance, if i remember correctly, addPortletLink() was obsoleted long time ago, with a message instructing to use "mw.util.addPortletLink", and during the time since it was declared obsolete, practically all call-sites were converted. other such functions were handled similarly (appendCSS => mw.util.addCSS, etc.) nothing like that happened with importScript and importStylesheet(). the least i'd expect is for "someone" to create mw.util.import(Script|Stylesheet), add "obsolete" marker to wikibits functions, and give the communities some time to convert. peace - קיפודנחש (aka kipod) (talk) 15:35, 28 March 2016 (UTC)
- Read the email. It hasn't happened yet. Load by default goes first with Mediawiki 1.27 next month with the wikibits removed in a further release in November so that's the 6 month period for people to convert etc. Nthep (talk) 15:41, 28 March 2016 (UTC)
- @Nthep:: removing "load by default" _is_ a breaking change: stuff that works today will stop working, and will require code change to work again. whether this code change is manually loading wikibits or rolling your own "importScript()" is irrelevant.
- TWISI, for wmf to be considered "good citizens", 3 things need to happen before removing the "load by default":
- mark *all* wikibits functions as "deprecated" or "obsolete", so calling them will leave a mark in JS log. this is how these things were done until now, and we came to expect it. please don't surprise us.
- offer good substitute for each function removed. most functions have them, but not all: as several people noted in this section, there is no reasonable substitute for some of the calls, specifically import(Script|Stylesheet)
- allow the communities reasonable time to go over the obsolete calls and update the call-sites.
- removing "load by default" _is_ a breaking change, so claiming you give people 6 months to adjust is just not true. not marking the calls that are going to disappear as "obsolete", is being less helpful than you can be. not providing good substitute is just wrong - why should every single project have to place the code User:Nihiltres in their mediawiki:common.js, when it clearly blongs in mw.util ?
- peace - קיפודנחש (aka kipod) (talk) 18:28, 28 March 2016 (UTC)
- Yes, I agree that we should have a solution in
mw.util
ormw.loader
. It would be better if we had a simplemw.loader.wikiLoad()
or something, with the same basic functionality (probably worthwhile to addimportCSS
functionality as well, with type defaults based on page suffix). Themw.loader.load()
functionality is built around server-side registration of modules, while user code has to use the ugly URL-based fallback. In the long term, with plans to create Gadget namespaces and such, it's not so bad, but until we have that, a clean way to load wiki-based JS/CSS pages is quite desirable. {{Nihiltres |talk |edits}} 19:19, 28 March 2016 (UTC)
- Yes, I agree that we should have a solution in
- Read the email. It hasn't happened yet. Load by default goes first with Mediawiki 1.27 next month with the wikibits removed in a further release in November so that's the 6 month period for people to convert etc. Nthep (talk) 15:41, 28 March 2016 (UTC)
- @Nihiltres Beware that mw.util.wikiUrlencode (from
mediawiki.util
) requires a dependency as otherwise it may be undefined in race conditions. A shortcut for local wikis in Common.js could look as follows instead:window.importScript = function (pageName) { mw.loader.using('mediawiki.util').then(function () { var conf = mw.config.get(['wgServer', 'wgScript']), url = conf.wgServer + conf.wgScript + '?title=' + mw.util.wikiUrlencode(pageName) + '&action=raw&ctype=text/javascript'; mw.loader.load(url); }); };
- So I just need to add this snippet to the top of my .js and importScript will continue to work? Is there a reason importScript is going away, it seems rather useful and more elegant? –xenotalk 18:55, 28 March 2016 (UTC)
Too many references
In List of Stuff You Should Know episodes, there should be about 840 references. However, instead all that appears is "Template:Reflist." I started playing around with it in my sandbox, and discovered that if I cut out some sections, I was able to restore the references. The sandbox is showing 637 references, although I don't know what the maximum number is. Is there a work around for this? Thanks! --BrianCUA (talk) 13:39, 26 March 2016 (UTC)
- Too many templates. See Wikipedia:Template limits#Post-expand include size. Time to split the list?
- —Trappist the monk (talk) 13:59, 26 March 2016 (UTC)
- I've proposed splitting the article, as it's technically unmanageable. fredgandt 16:37, 26 March 2016 (UTC)
RfC notice: WP:CITEVAR scope, and citation coding (markup) vs. citation style (presentation)
![](https://web.archive.org/web/20160329220900im_/https://upload.wikimedia.org/wikipedia/en/thumb/3/31/Imbox_notice.png/20px-Imbox_notice.png)
Please see Wikipedia talk:Citing sources#RFC: Is a change in citation markup method a change in citation style? (on whether WP:CITEVAR can be interpreted to apply to details of citation code formatting as well as overall citation style, e.g. Harvard, Vancouver, etc., citation styles). — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 22:12, 26 March 2016 (UTC)
Why does this happen?
As you can see that arrangement gets reversed? Why? --QEDK (T 📖 C) 07:00, 27 March 2016 (UTC)
- You refer to the left-to-right order of top icons changing from {green, yellow, red} to {red, yellow, green} when you preview User:QEDK. It's {green, yellow, red} in both cases in my Firefox 45.0.1. What is your browser? What happens when you log out? PrimeHunter (talk) 10:09, 27 March 2016 (UTC)
-
-
- That sounds like something in user settings. Have you enabled "Use live preview" at Special:Preferences#mw-prefsection-editing? It's described at Help:Show preview#Live preview and gives {red, yellow, green} when I enable it. PrimeHunter (talk) 12:57, 27 March 2016 (UTC)
-
-
-
-
-
- I don't know the details but if you only load part of a page as described at Help:Show preview#Live preview then it doesn't surprise me that the layout can change. I wouldn't worry about it. PrimeHunter (talk) 13:26, 27 March 2016 (UTC)
-
-
-
Citation autofill on toolbar not working for journals
When I use the citation autofill feature by clicking on the "cite" button on the toolbar (the one that is furthest to the right), sometimes it generates an error message saying the "month" parameter is not recognized. This seems to happen because the autofill tool is using an old form of the cite journal template that no longer works--that is, one that uses month and day parameters rather than one date parameter. Does anyone know if the autofill feature can be fixed to have it use the current version of this template, and if so, how can I contact the people who can fix it? Everymorning (talk) 00:00, 28 March 2016 (UTC)
- Hi. See Wikipedia talk:RefToolbar#Autofill not working for an albeit short discussion that seems to be about the same issue (although you added more useful detail). That's probably the best place to start your enquiries in any case. fredgandt 00:16, 28 March 2016 (UTC)
WP:Checklinks is still going bonkers
13 days ago I reported that WP:Checklinks is going bonkers by duplicating added accessdates. Today it is doing it again. (cc to @Frietjes and Dispenser:. I would like to be able to rely on Checklinks to do a tidy job. Cheers! {{u|Checkingfax}} {Talk}
12:07, 28 March 2016 (UTC)
Reping Frietjes {{u|Checkingfax}} {Talk}
12:09, 28 March 2016 (UTC)
CSS Image Crop
There is a problem with a file name unexpectedly appearing below an image generated by a css template, with a screenshot provided, at the discussion here (scroll down to "Image review". Help would be appreciated.--Wehwalt (talk) 16:02, 28 March 2016 (UTC)
- @Wehwalt: The screenshot shows a copy of the image name instead of the usual "jump to the full image" icon, so this is something to do with the "magnify" CSS class. I noticed that Module:Location map generates
<div class="magnify">[[:File:Foo.jpg| ]]</div>
, whereas {{CSS image crop}} omits the pipe and the space, generating<div class="magnify">[[:File:Foo.jpg]]</div>
. But that's as far as I can go, and I don't know whether that is significant or why Nikkimaria is seeing an unexpected result. -- John of Reading (talk) 16:58, 28 March 2016 (UTC)
Tech News: 2016-13
19:43, 28 March 2016 (UTC)
There's something wrong with XTools
Article info gives me an error which says "The ini file could not be read". The other XTools are at the moment having spotty reliability at best: at times they work, but in other times they take too long to load. Narutolovehinata5 tccsdnew 00:50, 29 March 2016 (UTC)
- @Narutolovehinata5: Should be working now (it is for me). It was related to a permissions issue that the labs reboots brought to light. ~ Matthewrbowker Drop me a note 01:56, 29 March 2016 (UTC)
- Yes, props to Matthewrbowker! He spent quite some time earlier today diagnosing this issue. Still need to figure out what's up with the edit counter, but I believe we have some solid theories — MusikAnimal talk 02:23, 29 March 2016 (UTC)
- It appears the edit counter is now functional. ~ Matthewrbowker Drop me a note 05:21, 29 March 2016 (UTC)
- Yes, props to Matthewrbowker! He spent quite some time earlier today diagnosing this issue. Still need to figure out what's up with the edit counter, but I believe we have some solid theories — MusikAnimal talk 02:23, 29 March 2016 (UTC)
Template:EPA content adds unhidden Category:Wikipedia articles incorporating text from the United States Environmental Protection Agency to the articles (currently only one article there). Could someone look if this cat could be hidden? Brandmeistertalk 08:49, 29 March 2016 (UTC)
- Done. The category has only a single member. Not sure, then, why we have the cat. --Tagishsimon (talk) 09:00, 29 March 2016 (UTC)
- @Brandmeister: Redlinked categories are never hidden. This is because the code to hide them must be placed on the category page; and if it's there, the cat page must then exist, therefore it's no longer a redlinked category. --Redrose64 (talk) 15:05, 29 March 2016 (UTC)
Recycled url
The Gender Equality Architecture Reform (GEAR) Campaign lobbied from 2007 for a new UN gender equality entity, with a website at http://www.gearcampaign.org. It achieved its goals in 2010 and dissolved, letting the domain name lapse. Now the domain name is being used by a blog about electric battery technology. The effect is that links in the Gender Equality Architecture Reform article point to the home page of the electric battery blog. I changed the citations to look like:
- "GEAR Campaign History" (PDF) . As of 2010-07-18 stored at http://www.gearcampaign.org/uploads/cms/_images/the-gear-campaign-background3.pdf
Is there a better way? This cannot be a new problem. I do not see anything about it at Wikipedia:Link rot. Aymatth2 (talk) 12:48, 29 March 2016 (UTC)
- You should provide a
|archiveurl=
. --Izno (talk) 13:16, 29 March 2016 (UTC)- That would work if the pages had been archived, but on a search for the page the Wayback Machine says
- Page cannot be crawled or displayed due to robots.txt.
- See www.gearcampaign.org robots.txt page. Learn more about robots.txt.
- So even if the pages were archived, the present version of the site is hiding the archived versions. Aymatth2 (talk) 13:36, 29 March 2016 (UTC)
- Seems like a "bug" with IA. --Izno (talk) 13:47, 29 March 2016 (UTC)
- This is just IA being responsible and adhering to the robots.txt file of the website. We also have a https://en.wikipedia.org/robots.txt. PrimeHunter (talk) 13:52, 29 March 2016 (UTC)
- @PrimeHunter: The point I'm making is that that is the current owner's robots.txt. We do not know if the previous owner's robots.txt also required noindex. --Izno (talk) 13:58, 29 March 2016 (UTC)
- This is just IA being responsible and adhering to the robots.txt file of the website. We also have a https://en.wikipedia.org/robots.txt. PrimeHunter (talk) 13:52, 29 March 2016 (UTC)
- Seems like a "bug" with IA. --Izno (talk) 13:47, 29 March 2016 (UTC)
- That would work if the pages had been archived, but on a search for the page the Wayback Machine says
-
-
-
-
-
- The "new" owner may be just a new name for the previous owner, like Alphabet and Google, and archive.org may choose to respect the current robots.txt setting whatever it was in the past. Anyway, assuming that for whatever reason we cannot find an archived version, how do we show we are citing a page by that name we found at that url on that date, which has since been replaced by something completely different? Aymatth2 (talk) 16:24, 29 March 2016 (UTC)
-
-
-
-
Broken links table
I just moved Glen Parva railway station to Wigston Glen Parva railway station, following which Special:WhatLinksHere/Wigston Glen Parva railway station was empty for several minutes; most worryingly, the redirect wasn't listed there. Is this phab:T117332? Perhaps Matma Rex (talk · contribs) knows. --Redrose64 (talk) 13:14, 29 March 2016 (UTC)
- @Redrose64: I'm afraid I don't know. But it looks like Special:WhatLinksHere is correct now. A delay of a few minutes is normal. Matma Rex talk 19:31, 29 March 2016 (UTC)
- It used to be that it was updated so quickly that you wouldn't notice - to all intents and purposes it was instantaneous. If there is now a measurable delay, then fixing resultant double redirects - as we have been advised to do for years - might get completely missed. --Redrose64 (talk) 19:48, 29 March 2016 (UTC)
IPv6 range contributions
Is there any tool available which will show all the edits from an IPv6 range? I have the gadget that allows viewing contributions from an IPv4 CIDR range turned on, but it doesn't appear to work with IPv6 ranges. -- Ed (Edgar181) 15:36, 29 March 2016 (UTC)