Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by George Orwell III (talk | contribs) at 04:29, 1 January 2016 (→‎A challenge for anyone who supports Wikimedia Flow.: poor resource management). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
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.


Cyclic redirects: Avoid misleading the reader

Tracked in Phabricator
Task T122292

A common problem on Wikipedia are redirects that direct back to where they come from. Example: Olympic winners of the Stadion race has a link for each athlete. Some of these are redlinks, some are blue. Unfortunately, many of the blue links are misleading: For Anticles of Messenia, Menus of Megara and many others, there is no article, just a redirect to the Olympic winners article itself. This is just frustrating for any reader who clicks on that link to get more information about a particular athlete.

One idea that would at least reduce the problem would be to color all links to redirects in another color; say orange. That would have the additional advantage that it would also alert editors that they could use a piped link instead. Of course, not all links to redirects are bad, so this may be misleading, too. Also, I'm not sure how this would be implemented.

Does anyone have a better idea to mitigate this problem? — Sebastian 07:21, 22 December 2015 (UTC)[reply]

To mark all redirects to green, you can put this into your CSS page:
.mw-redirect, .mw-redirect:visited {
  color: green;
}
--Edgars2007 (talk/contribs) 07:33, 22 December 2015 (UTC)[reply]
@Edgars2007: The question asks how to make it better for "any reader", not just himself. -- John of Reading (talk) 07:39, 22 December 2015 (UTC)[reply]
I wasn't starting my reply with "Solution to this is..." :) Edgars2007 (talk/contribs) 07:44, 22 December 2015 (UTC)[reply]
Redirects have the same class="mw-redirect". A Phabricator request could be made to give an additional class to redirects going back to the page they are on. Then they could be treated differently. I haven't found an existing request and don't know the server cost of implementing it. PrimeHunter (talk) 14:59, 22 December 2015 (UTC)[reply]
How about links that redirect back to the current page simply render the same as a redlink? If someone does click that link then apply redirect=false so they stay on the redirect page? That's basically the expected behavior for clicking on a redlink. Getting bounced back to the source page is pointless. Alsee (talk) 19:52, 22 December 2015 (UTC)[reply]
Creating a redirect was probably a wrong method of solving a wp:redlink. Until the fixes mentioned were implemented, bot's might do them: Wikipedia:WikiProject_Check_Wikipedia, /List of errors, #106, "Redirect link from=to" — CpiralCpiral 03:23, 23 December 2015 (UTC)[reply]
No, it's a perfectly legitimate situation, as in Alsee's example below: It is natural for the article on Acme to have a link to Bob, and it's natural that as long as we don't have an article on Bob, that will be a redirect to Acme. — Sebastian 02:45, 29 December 2015 (UTC)[reply]
Actually, Cpiral is right about the example I picked: Anticles of Messenia, Menus of Megara should probably have better remained redlinks. — Sebastian 18:24, 29 December 2015 (UTC)[reply]

I opened it on Phabricator, including this: 

Once possible solution:
 In article [[Acme]], can the software render [[Bob]] as a redlink? (Or maybe orange-red.) This correctly indicates that the article doesn't exist and that clicking the link is normally pointless. Also: if someone does click that link then apply Redirect=false. This is the expected behavior for clicking a redlink, and getting bounced back would be pointless anyway.

Do people support that idea or see problems with it? Any alternatives? Alsee (talk) 13:38, 23 December 2015 (UTC)[reply]

I support the idea. The bug you opened was T122292. It was falsely closed as "invalid", but I reopened it. — Sebastian 02:45, 29 December 2015 (UTC)[reply]
Self-links are rendered in bold, so perhaps they should be displayed that way instead. WhatamIdoing (talk) 01:38, 24 December 2015 (UTC)[reply]
Bold and without link. Are you suggesting to remove the links altogether, or are you suggesting for them to just appear black and without underlines, while keeping the link functionality? — Sebastian 02:45, 29 December 2015 (UTC)[reply]
I'm not sure that there is a perfect solution, but if you want them to look just like a redirect to that page, then it should be bold, with no link or link-style formatting. WhatamIdoing (talk) 05:30, 29 December 2015 (UTC)[reply]
I could see a benefit for the cyclical link to look just like a self-redirect, but only if there was an unambiguous formatting standard for those. Plain-colored bold is not such a standard, since it is primarily used for other purposes. I am sure it was never intended as such and that it was just an ad-hoc idea someone came up with. Highlighting alternative names in bold may make sense if a reader came to the article through that redirect; there is a chance that the formatting makes it easier for the reader to find what they are really interested in. That becomes less likely for non-self-redirects. More importantly, it will become confusing for readers who access the "Acme" article directly: "Bob" is not an alternative name for "Acme", so readers will scratch their heads why "Bob" is bold. — Sebastian 18:24, 29 December 2015 (UTC)[reply]
i am not sure everyone here, and on the phabricator ticket, took all cases into account. specifically, i refer to the case where the redirect is a "section/anchor redirect", i.e., when the redirect has #. in the example above, imagine the "Bob" redirects to "Acme#Management". in this case, displaying it differently from "normal" internal link will be inconsistent: in effect, using [[Bob]] from inside the Acme article, is equivalent to [[#Management | Bob]], i.e., same-page anchor link. since the 2nd case is displayed like any other internal link, displaying the 1st case differently will be inconsistent. peace - קיפודנחש (aka kipod) (talk) 15:25, 30 December 2015 (UTC)[reply]

VisualEditor News #6—2015

Read this in another language • Subscription list

Did you know?

A new, simpler system for editing will offer a single Edit button. Once the page has opened, you can switch back and forth between visual and wikitext editing.

Screenshot showing a pop-up dialog for switching from the wikitext editor to VisualEditor
If you prefer having separate edit buttons, then you can set that option in your preferences, either in a pop-up dialog the next time you open the visual editor, or by going to Special:Preferences and choosing the setting that you want:
Screenshot showing a drop-down menu in Special:Preferences

The current plan is for the default setting to have the Edit button open the editing environment you used most recently.

You can read and help translate the user guide, which has more information about how to use the visual editor.

Since the last newsletter, the VisualEditor Team has fixed many bugs and expanded the mathematics formula tool. Their workboard is available in Phabricator. Their current priorities are improving support for languages such as Japanese and Arabic, and providing rich-media tools for formulæ, charts, galleries and uploading.

Recent improvements

You can switch from the wikitext editor to the visual editor after you start editing.

The LaTeX mathematics formula editor has been significantly expanded. (T118616) You can see the formula as you change the LaTeX code. You can click buttons to insert the correct LaTeX code for many symbols.

Future changes

The single edit tab project will combine the "Edit" and "Edit source" tabs into a single "Edit" tab, like the system already used on the mobile website. (T102398) Initially, the "Edit" tab will open whichever editing environment you used last time. Your last editing choice will be stored as a cookie for logged-out users and as an account preference for logged-in editors. Logged-in editors will be able to set a default editor in the Editing tab of Special:Preferences in the drop-down menu about "Editing mode:".

The visual editor will be offered to all editors at the following Wikipedias in early 2016: Amharic, Buginese, Min Dong, Cree, Manx, Hakka, Armenian, Georgian, Pontic, Serbo-Croatian, Tigrinya, Mingrelian, Zhuang, and Min Nan. (T116523) Please post your comments and the language(s) that you tested at the feedback thread on mediawiki.org. The developers would like to know how well it works. Please tell them what kind of computer, web browser, and keyboard you are using.

In 2016, the feedback pages for the visual editor on many Wikipedias will be redirected to mediawiki.org. (T92661)

Testing opportunities

  • Please try the new system for the single edit tab on test2.wikipedia.org. You can edit while logged out to see how it works for logged-out editors, or you can create a separate account to be able to set your account's preferences. Please share your thoughts about the single edit tab system at the feedback topic on mediawiki.org or sign up for formal user research (type "single edit tab" in the question about other areas you're interested in). The new system has not been finalized, and your feedback can affect the outcome. The team particularly wants your thoughts about the options in Special:Preferences. The current choices in Special:Preferences are:
    • Remember my last editor,
    • Always give me the visual editor if possible, 
    • Always give me the source editor, and 
    • Show me both editor tabs.  (This is the current state for people using the visual editor. None of these options will be visible if you have disabled the visual editor in your preferences at that wiki.)
  • Can you read and type in Korean or Japanese? Language engineer David Chan needs people who know which tools people use to type in some languages. If you speak Japanese or Korean, you can help him test support for these languages. Please see the instructions at mw:VisualEditor/IME Testing#What to test if you can help, and report it on Phabricator (Korean - Japanese) or on Wikipedia (Korean - Japanese).

If you aren't reading this in your favorite language, then please help us with translations! Subscribe to the Translators mailing list or contact us directly, so that we can notify you when the next issue is ready. Thank you!

Whatamidoing (WMF), 00:54, 24 December 2015 (UTC)[reply]

Single edit tab

  • Oppose. I discussed this deployment a month ago on Phabricator. I asked whether the WMF was going to try to slip in a Visual Editor default as part of the single-edit-tab-deployment. Jdforrester-WMF assured me the answer was no.[1] I apologized for being paranoid. Whelp, I just went to the test wiki. I created a brand new account. I clicked the edit tab. Would anyone like to guess which editor came up by default? Alsee (talk) 02:11, 24 December 2015 (UTC)[reply]
  • Unclear what is going on here. Apparently there's a bug that there is supposed to be a menu, which isn't showing up. Could other editors report what browser you use, and whether you get a menu or if it just defaults to VE? And regarding the menu (I saw an image of it), it seems like a poor plan. New editors are asked to answer a question they don't understand, and get locked into whatever random editor they click. With two edit buttons they will naturally explore both. Alsee (talk) 04:59, 24 December 2015 (UTC)[reply]
    I recommend reading the long box on the right, with the two pictures. The second picture is from Special:Preferences, and shows how to change the settings whenever you want. You don't get "locked in" to anything. NB that the first "menu" box only appears once, but if you reset all of your preferences at test2, it will come back (or "should": I can't get it to appear in Firefox today). Whatamidoing (WMF) (talk) 05:05, 24 December 2015 (UTC)[reply]
    I can't see what it's supposed to look like in action, because it's broken. So I'm going on little info here. By "locked in", I meant that a brand new user may well quit before they discover Special:preferences. With two edit tabs they will most likely explore both within a matter of minutes. Alsee (talk) 05:15, 24 December 2015 (UTC)[reply]
    I just tried editing the test2wiki in Chrome on Windows 7, and I saw the window asking me to choose my editor without any problems. — Mr. Stradivarius ♪ talk ♪ 06:45, 24 December 2015 (UTC)[reply]
  • Oppose default single edit tab for IPs who delete cookies. I agree with most everything Alsee wrote here. I saw the popup choice on the test wiki while signed in. New IP users are going to bail if they make the bad decision to choose VE, and are using Firefox. Because when on a page like Barack Obama they will see that it takes 25 to 30 seconds to load VE before they can do anything. As it does for me in Firefox. They might get lucky and figure out how to get back to wikitext as they are used to in the past. But since many IPs delete most or all cookies when they close their browser, they will be stuck with wasting time on this confusing popup choice again and again later. So this creates user paralysis, confusion, and loss of yet more editors. This also breaks the promise to not impose VE on editors. Imposing this popup window over and over is all about VE. It will be a waste of time for them. They just want their "edit source" button as before, and no cookies. People edit Wikipedia at work too. They don't want to leave a trail of any kind. So they don't save the Wikimedia cookies. Or they just want to be as anonymous as possible no matter where they are editing from. --Timeshifter (talk) 15:39, 24 December 2015 (UTC)[reply]
    • Under the current configuration for the English Wikipedia, the single edit tab for IPs would open in the wikitext editor. It would really be no different from what they have right now. The main question for the English Wikipedia is whether this set of four preferences would work for logged-in editors – for example, for the people who want the wikitext editor for everything except editing tables, and whose current choices are either (1) get used to having two edit buttons all the time or (2) re-enable the visual editor every time they want to use the visual editor for a single edit, and then re-disable it again to get rid of the double edit buttons. Whatamidoing (WMF) (talk) 18:37, 24 December 2015 (UTC)[reply]
      • Right now IP users apparently don't have a choice. I logged out and looked at an article. They get a single edit tab, labeled "edit". But it edits wikitext only. As for logged-in editors I see no benefit in giving logged-in editors a single edit tab. I only see problems. They will have to go to preferences to choose editors. Whereas now, they can choose which editor to use at anytime by picking "edit source" or "edit". I think we should put those 2 buttons on IP articles too. Same labels. Why are we using an "edit" button for IP users that produces a wikitext editor? --Timeshifter (talk) 20:40, 24 December 2015 (UTC)[reply]
  • To quote from the Phab thread, "it's not clear to me what problem is being solved by a single edit tab." I don't find the responses there compelling (Some users click the wrong tab and some users don't know which tab does what) because a single button obscures what interface will be used and disguises that there even are multiple editing interfaces. That said, that's just my initial assumption so I'll go test it and come back. Sam Walton (talk) 15:58, 24 December 2015 (UTC)[reply]
    • I'd be particularly interested in hearing what you think about the ability to switch back and forth between the two editing systems during your edit (=without needing to save). Whatamidoing (WMF) (talk) 18:38, 24 December 2015 (UTC)[reply]

Whatamidoing (WMF), perhaps there would be less confusion if we weren't going to a VE-configured test server to see what is being proposed here? Alsee (talk) 00:15, 25 December 2015 (UTC)[reply]

And what effect would this have on people like me who have disabled VE? Will I lose my edit tab entirely until I enable VE? I see that cookies will save the option that I picked last time, but we'll need to ensure that it gives both options until a "last time" happens. Nyttend (talk) 15:15, 25 December 2015 (UTC)[reply]
If you have disabled access to the visual editor, then this will have no effect at all. "Always give me wikitext" is nearly equivalent to disabling it (pages would always open in the wikitext editor, but once inside it, you'd have the option of manually switching solely for that particular edit), but if you've disabled the visual editor entirely, then this doesn't affect your editing experience at all. You can't even set a preference for this if the visual editor is disabled. (Cookies are only for IPs. Preferences for registered are recorded directly in their accounts, not in cookies.) Whatamidoing (WMF) (talk) 23:05, 25 December 2015 (UTC)[reply]
  • Comment. Please create a dedicated talk page for the single edit tab on English Wikipedia. There is the dedicated talk page on MediaWiki.org but it uses Flow, and many people have problems with it. I suggest this:
  • Wikipedia:VisualEditor/Feedback/single edit tab
  • Wikipedia talk:VisualEditor/Feedback/single edit tab
See also the Flow discussion below in this section: #Flow is driving people away from Mediawiki.org reporting. This tech board is also inadequate. --Timeshifter (talk) 04:02, 30 December 2015 (UTC)[reply]

Fixed font transitions don't space correctly

If there are two spaces in wikitext, one is rendered. If the two spaces occur around a font tag, one is still rendered, and it's always the wrong one, or was this intentional:

.nospace. chosen-spacing . wanted-spacing . chosen-spacing .nospace.
∈ chosen-spacing <samp><code>.</code> wanted-spacing <code>.</code> </samp>chosen-spacing

It shows one space outside the <samp>...</samp>, and one inside. No matter where the spaces are they're always either chosen or converted to the same narrow space.

Is it just me that prefers the version

That has  for things and stuff to cut and paste  the space template?
∈ That has {{space}}<samp>for things and stuff to cut and paste{{space}}</samp>the space template? — CpiralCpiral 19:42, 24 December 2015 (UTC)[reply]
@Cpiral: Multiple spaces always collapse to a single space. That is how all browsers have always worked. --Redrose64 (talk) 20:53, 26 December 2015 (UTC)[reply]
'Twould be nice if it didn't convert the wide space to a narrow one. — CpiralCpiral 21:26, 26 December 2015 (UTC)[reply]

Empty bullets

In articles such as Căile Ferate Române that have an expand language template within multiple issues, there are empty bullets when you click on "show". GeoffreyT2000 (talk) 04:48, 25 December 2015 (UTC)[reply]

I see all bullets in that article (Win XP, latest Firefox). --Edgars2007 (talk/contribs) 09:14, 25 December 2015 (UTC)[reply]
It looks normal to me in Firefox. "show" produces five entries with a bullet and initial words "View", "Google's", "Do", "After", "For". Do you mean you see lines with a bullet and no other content? What is before and after those lines? What is your browser? PrimeHunter (talk) 12:34, 25 December 2015 (UTC)[reply]
Using the latest edition of IE, I see the following:
  •  
  • View a machine-translated version of the French article
  •  
  • Google's machine translation is a useful starting point for translations, but translators must revise errors as necessary and confirm that the translation is accurate, rather than simply copy-pasting machine-translated text into the English Wikipedia.
  •  
  • Do not translate text that appears unreliable or low-quality. If possible, verify the text with references provided in the foreign-language article.
  •  
  • After translating, {{Translated|fr|Căile Ferate Române}} must be added to the talk page to ensure copyright compliance.
  •  
  • For more guidance, see Wikipedia:Translation.
Nyttend (talk) 15:10, 25 December 2015 (UTC)[reply]
I also see the problem in IE 9.0. It occurs for {{Multiple issues|{{Expand French}}}} but not for {{Expand French}} alone. Maybe there is an issue with nested classes. PrimeHunter (talk) 12:44, 26 December 2015 (UTC)[reply]
Seems the bullets are rendered twice. In Chrome and other, they overlap, but in IE they seems to be forced apart. It happens because there are real list itmes inside fake list itmes, and both try to render the bullets. -- [[User:Edokter]] {{talk}} 15:17, 26 December 2015 (UTC)[reply]

Some search results counts with 0 words

See https://en.wikipedia.org/w/index.php?title=Special:Search&limit=20&offset=20&ns10=1&search=christmas for example. Some templates with many words counts on the search result page with '0 words', which is incorrect. --RezonansowyakaRezy (talk | contribs) 14:27, 25 December 2015 (UTC)[reply]

I'd assume it has something to do with only counting words that aren't in templates, but I'm not sure. Sam Walton (talk) 14:36, 25 December 2015 (UTC)[reply]
But this search page (above) prints only results from Template pages. I think the problem is that words inside tables/boxes are not counted. --RezonansowyakaRezy (talk | contribs) 15:11, 25 December 2015 (UTC)[reply]
That's what I mean; text on the template page that's in another template. Though a couple of other examples contradict that, so I have no idea. Sam Walton (talk) 16:06, 25 December 2015 (UTC)[reply]
It's a bug, but I don't know where yet. --RezonansowyakaRezy (talk | contribs) 18:49, 25 December 2015 (UTC)[reply]
WP:SIZERULE explains why zero words is correct for that wp:list article — CpiralCpiral 21:16, 26 December 2015 (UTC)[reply]

issues with images

Sometimes images load fine but browsing here and there then the images will crash. I click on them and instantly says they can't load or there was an error. Lucia Black (talk) 21:34, 25 December 2015 (UTC)[reply]

Lucia Black, how long has this been going on (hours/days/weeks?)? Whatamidoing (WMF) (talk) 23:11, 25 December 2015 (UTC)[reply]
since I've returned to Wikipedia which is around 1 week. Lucia Black (talk) 23:12, 25 December 2015 (UTC)[reply]
Might be phab:T115563? Help is welcome as it's still hard for the developers to track down the underlying issue. :( --AKlapper (WMF) (talk) 10:24, 28 December 2015 (UTC)[reply]
Well it only happens with Wikipedia. In other websites, all images load faster. Sometimes they crash, but only because they are too big, but Wikipedia seems to crash them imediately without trying to load (if that makes sense) Lucia Black (talk) 19:22, 28 December 2015 (UTC)[reply]

Wikipedia Metro app's license

Tracked in Phabricator
Task T122468
Wikipedia App Windows 8

Does some developer know where's the license for out Wikipedia app for Windows 8/10? Its source is on our Wikimedia git repo – https://git.wikimedia.org/summary/apps%2Fwin8%2Fwikipedia.git. It's titled as 'open source' on Windows Store. --RezonansowyakaRezy (talk | contribs) 23:39, 25 December 2015 (UTC)[reply]

@Rezonansowy: I can't find one, either. I've filed a report on phab:T122468. Zhaofeng Li talk (Please {{Ping}} when replying) 06:34, 27 December 2015 (UTC)[reply]
OK, thanks! --RezonansowyakaRezy (talk | contribs) 22:50, 27 December 2015 (UTC)[reply]

Substitution in comments

(I was directed here from Wikipedia:Help desk#Substitution in comments.) Under Help:Substitution#Documenting substitution, it states: "Thus a comment can be used to mention the template. It can even contain the values of the parameters, because substitution of parameters works even in comments." I believe this to be wrong, as User:AlexTheWhovian/Upcoming substitutes the provided parameter into the un-commented version of {{{1}}}, but not the occurrences of {{{1}}} that are inside the comment, as seen at User:AlexTheWhovian/sandbox#DNI substitution. How do I fix this? Alex|The|Whovian 03:31, 27 December 2015 (UTC)[reply]

@AlexTheWhovian: You can use something like <!<noinclude />-- {{{1}}} -->. I found this trick in {{Do not archive until}}. – nyuszika7h (talk) 20:48, 28 December 2015 (UTC)[reply]
@Nyuszika7H: Thanks! Worked! Alex|The|Whovian 23:37, 28 December 2015 (UTC)[reply]

Should we change ten thousand articles to implement a "noprint"?

Request for comments on the plan proposed at Template_talk:In_title#How_to_alter_this_template_and_its_wiki_landscaping.

I'm asserting that

  • the 9703 pages that use intitle or lookfrom templates must be changed by AWB or other bot to remove a stray bullet from a print preview.
  • "noprint" code fix in the intitle sandbox is the same one needed for the lookfrom code
  • Search links have not been allowed in article space (wp:elno rule 9), and so the missing guideline was only just written for this occasion.
  • Search links should be allowed in article space, but only if they follow "the missing guideline".

It's all clearly spelled out there (and at its predecessor talk-posting). Please comment. Thank you. — CpiralCpiral 07:46, 27 December 2015 (UTC)[reply]

Cite web problem

A note in the article Regula fidei contains the following error message: "line feed character in |quote= at position 1641". What does it mean and how can we correct it? --Jonund (talk) 13:29, 27 December 2015 (UTC)[reply]

@Jonund: Line feeds are newlines. The |quote= parameter is intended for short quotations, not two whole paragraphs; hence, they should not contain paragraph breaks, which Wikipedia normally forms using two newlines. I've removed those and replaced them with a <p> tag, but I strongly suggest trimming that |quote= parameter right down to the essentials. --Redrose64 (talk) 14:48, 27 December 2015 (UTC)[reply]

No new RfBs

There have been no new Requests for Bureaucratship since January 2014. The last one was Wikipedia:Requests for bureaucratship/Acalamari 2. That means that 2015 is the first year without any new RfBs. GeoffreyT2000 (talk) 16:03, 27 December 2015 (UTC)[reply]

@GeoffreyT2000: This isn't really the place for this; WP:RfA or WP:VPM would be better. Sam Walton (talk) 16:12, 27 December 2015 (UTC)[reply]

Interlanguage links with WikiData on Mingrelian language

Hello !

On Mingrelian language article, I don't see interlanguage links whereas this article is correctly linked with Wikidata item. I suppose it is same as user:Glenn's message above. But I see Interference (wave propagation) interlanguage links without problem (like every other articles).

Does anybody see same as me ?

Sorry for my bad English. --Pols12 (talk) 11:30, 28 December 2015 (UTC)[reply]

WP:Null edit usually helps in such cases. I "fixed" that article. --Edgars2007 (talk/contribs) 11:49, 28 December 2015 (UTC)[reply]

Special:LinkSearch

Special:LinkSearch will no longer display results past 10,000. See sample search. Any idea what's going on with this? Nikkimaria (talk) 14:27, 28 December 2015 (UTC)[reply]

This limitation was added in gerrit:250877, due to phab:T107265. Anomie⚔ 23:48, 28 December 2015 (UTC)[reply]
@Anomie: This seems like it might be a bug introduced by that change. More specifically, the issue is that you can't click "Next 5,000", though changing the URL directly to the next 5000 works fine. Sam Walton (talk) 00:04, 29 December 2015 (UTC)[reply]
Hmm. You're right, I see two bugs now that I actually look at that change. Added code review comments there. Anomie⚔ 02:24, 29 December 2015 (UTC)[reply]

Title

How to make title italicized without preventing transliteration if one Wikipedia uses it? Example (not working with DISPLAYTITLE nor -{t:...}- syntax): sr.wikipedia.org --Obsuser (talk) 02:12, 10 December 2015 (UTC)[reply]

{{Искошен наслов}} worked just fine in preview. --Edgars2007 (talk/contribs) 17:07, 10 December 2015 (UTC)[reply]
Yes, but it is not working because after you save the page and try to change between cyrillic/latin script it stays cyrillic (if root pagename is cyrillic) or latin (if root pagename is latin). Shortly, transliteration is not possible that way. What to use to type formatted text for title (italicized) without "locking" that text to itself what {{DISPLAYTITLE}} or {{Italic title}} do? --Obsuser (talk) 18:41, 10 December 2015 (UTC)[reply]
Anyone? --Obsuser (talk) 16:16, 12 December 2015 (UTC)[reply]

Can anyone help? Still not resolved... --Obsuser (talk) 22:34, 28 December 2015 (UTC)[reply]

@Obsuser: This isn't resolved either because either (a) none of us knows the answer (b) none of us (myself included) understands the question or (c) it's not English Wikipedia, so no concern of ours. Apparently there is a problem at sr:Соно џој: but exactly what is the problem, what are you trying to do, what have you tried so far?
Also: sr:Соно џој is a redirect to sr:Соно џои, so there is a further difficulty: which of the two do you mean? --Redrose64 (talk) 00:26, 29 December 2015 (UTC)[reply]
Question is how to make title italicized (like its done on .en Wikipedia using "DISPLAYTITLE" or "Italic title" templates, what does not work on .sr Wikipedia).
Serbian Wikipedia uses two scripts (uses transliteration, option next to the "Разговор" i.e. dropdown menu "ћир/lat"). If I simply put "DISPLAYTITLE" or "Italic title" template in the article and save it — title get "locked" to Cyrillic or Latin script depending on which one was used when creating article at the very beginning (when it had not existed; if you type "Википедија" to create article that does not exist, it will "carry Cyrillic rootname"; if you type "Vikipedija", it is Latin).
After you save it with "DISPLAYTITLE" or "Italic title" template it get’s locked — transliteration is disabled, and if you try to change script — title remains as it is (either Cyrillic or Latin), while article’s text get’s transliterated as usually.
I’m referring to sr:Соно џои (current article, not redirect obviously).
Is there a way to display (wiki-)formatted text as article’s name by typing it somewhere in article (for example, to type as a wikitext <u>Title</u> i.e. in my case I would use <i>Title</i> or ''Title'' so title gets underlined or what I need — italicized)? --Obsuser (talk) 00:50, 29 December 2015 (UTC)[reply]
(edit conflict) The example page was moved after the original question.[2] I investigated it December 10 but couldn't find a solution and suspect there isn't one. At the Serbian Wikipedia sr:Special:Preferences you can choose between two writing systems sr-EC (Cyrillic) and sr-EL (Latin) in a box below the normal language choice box. See mw:Writing systems#LanguageConverter. It's possible an automatic choice is made for IP's depending on geolocation (I think the Chinese Wikipedia does this). The selection affects normal page content and not just the interface. uselang=sr-ec and uselang=sr-el display the same page differently, including the title. I cannot find a way to use a DISPLAYTITLE such that an italicized page title still displays differently for the two writing systems. Among other things, I examined interlanguage links of Template:Italic title for some languages with variants but couldn't find any that implemented a solution. 01:01, 29 December 2015 (UTC)PrimeHunter (talk)

Protection did not transfer when page was moved

Template:Main was protected in May 2014 by Mr. Stradivarius (see log) and today I moved it to Template:Main article (see log). Although it says "moved protection settings from Template:Main to Template:Main article" this did not appear to happen and Template:Main article was left unprotected for a couple of hours. Can anyone explain what happened? Thanks — Martin (MSGJ · talk) 22:53, 28 December 2015 (UTC)[reply]

@MSGJ: See Category talk:Wikipedia pages with incorrect protection templates#Page moves. GeoffreyT2000 (talk) 22:56, 28 December 2015 (UTC)[reply]
Thanks, I have posted a comment there. Seems to be an ongoing issue — Martin (MSGJ · talk) 17:22, 29 December 2015 (UTC)[reply]

Flow is driving people away from Mediawiki.org reporting. This tech board is also inadequate

People are sent to Mediawiki.org from this tech board. But then they have to use Flow. See WP:Flow. Many people are reporting problems with using it at Mediawiki.org. And Flow is no longer in active development. See mw:Flow: "However, starting in October 2015, Flow is not in active development."

The Mediawiki software is being hurt by Flow driving away people from reporting and commenting on Mediawiki bugs and features. From what I read, English Wikipedia will soon be Flow-free. Flow-based talk pages are eventually abandoned on English Wikipedia due to lack of users, and so they have been deleted one by one.

I hope we are not depending on this tech board to take up the slack for Mediawiki.org reporting and commenting? --Timeshifter (talk) 01:46, 29 December 2015 (UTC)[reply]

So you want mediawiki to change from flowboards to talk boards? — xaosflux Talk 01:48, 29 December 2015 (UTC)[reply]
I want mediawiki.org to use regular talk pages for all discussion pages.
See: https://www.mediawiki.org/wiki/Topic:Suspcq0bf5nd3gsd
People were sent there from this Village Pump recently. Some of the discussion is about Flow problems. --Timeshifter (talk) 01:59, 29 December 2015 (UTC)[reply]
First of all, Flow isn't evil like some people seem to think it is. I sometimes respond to technical support requests at mw.org using Flow, and have no problems. It is a smooth interface for simple discussions.
Secondly, I'm not sure when people are sent to mw.org from this page. I suppose some WMF teams might want to have all feedback centralised, which is a very sensible idea to avoid duplication of effort across many wikis. But I can't think of any recent feature developments that would have included a request to post feedback at MediaWiki.org.
Thirdly, I'd like to know where "many people are reporting problems with using it at Mediawiki.org", so I can make up my own mind.
Finally, any software bugs and feature requests should, as always, be reported to Phabricator. — This, that and the other (talk) 05:01, 29 December 2015 (UTC)[reply]
Your experience is not my experience with Flow. I find it to be terrible talk page software. I don't want to go all anthropomorphic and "evil" about it, though it is tempting. :)
Software bugs and feature requests are reported at Phabricator, here on this Village Pump, and are discussed on the talk pages at Mediawiki.org. Phabricator is not really for discussion. Comments tend to be short, and many are not replied to right away. It is not really meant for discussion. Newbs are intimidated by it, and developers are very busy. People feel much freer to discuss things here, or on Mediawiki.org talk pages. That is why it is important to use easy-to-use standard talk page format.
See the Mediawiki.org thread I linked to in my previous comment for some comments by people mentioning their difficulty with Flow. See also my talk page, and User:Alsee's comment recently about Flow. He is very knowledgeable about Flow problems. --Timeshifter (talk) 11:21, 29 December 2015 (UTC)[reply]
As "Phabricator is not really for discussion" was written: Phabricator's Maniphest tool is for tracking specific software development requests. It's not a forum software. :) Discussing those requests is one important function, among many others. Issue tracking system in general welcome contributors clearly sticking to the topic to keep discussions focused (hence I'd agree, if that's what was meant by writing "people feel much freer to discuss things here"). Right now I don't see how "Comments tend to be short" is a criterion for something plus "easy-to-use" can mean a lot of different things to different people...
Coming back to Flow: If many people are reporting problems with using Flow at Mediawiki.org, could you please point to some of these reports so interested people (like me) could take a look at them? Thank you a lot in advance! --Malyacko (talk) 12:05, 29 December 2015 (UTC)[reply]
Malyacko. See my comment farther down. The one that includes the box. --Timeshifter (talk) 14:44, 29 December 2015 (UTC)[reply]
No we are not dependent on this board to take up the slack, because there is no slack (not in the least because a core crowd of tech savvy users actually visits both venues as well as phabricator to tie stuff together).
Indeed, I(DONT)LIKEIT is not something that tends to go into phabricator. And indeed, please report actual experiences of users, so that interested people can look at them, triage them and possible distill an actionable out of it to file in phabricator. Which doesn't mean that they will then be immediately fixed; resolution time for any ticket is somewhere between 1 day and 8 years. —TheDJ (talk • contribs) 13:59, 29 December 2015 (UTC)[reply]
"please report actual experiences of users, so that interested people can look at them". I prefer that users report their experiences themselves. Flow makes that difficult for many. --Timeshifter (talk) 14:42, 29 December 2015 (UTC)[reply]
People are. Don't extend your own aversion to using Flow towards the entire population. —TheDJ (talk • contribs) 20:16, 29 December 2015 (UTC)[reply]
I didn't say "the entire population". I said "Flow makes that difficult for many." Plenty of others have expressed problems with Flow. See Alsee's comments below. Did you bother to read it? Or did you look in the MediaWiki.org thread I linked to a couple times previously? It uses Flow, and as I said several times already people in that thread commented on the problems they were having with Flow. People were sent to that Flow thread from this Village Pump. Specifically, from this section: #Testing opportunities which is a subsection of the "VisualEditor News #6—2015" heading. I think it is a good thing that the Flow thread it links to is dedicated to a single topic (single edit tab). But the problem is that it uses Flow. I would prefer a dedicated talk page using the standard talk page format. For example:
  • Wikipedia:VisualEditor/Feedback/single edit tab
  • Wikipedia talk:VisualEditor/Feedback/single edit tab
It doesn't have to be on Wikipedia. It could be on MediaWiki.org, but the Wikipedia watchlist is looked at much more often by average editors than the MediaWiki.org watchlist. Now that the cross-wiki watchlist was voted as the number 4 priority by editors, maybe the location of a dedicated talk page will soon no longer be a problem. But I would prefer a standard Mediawiki talk page, not Flow.
--Timeshifter (talk) 03:59, 30 December 2015 (UTC)[reply]
Yes,Ii read all of that. I just don't think that 3 people amongst many are a problem. People complain ALL THE TIME, all feedback pages by nature are 95% complaints, people who don't care or are happy don't have a reason to post. That doesn't mean anything in itself. Alsee is running an anti change campaign, you are annoyed, I get it. —TheDJ (talk • contribs) 06:56, 30 December 2015 (UTC)[reply]
People were invited to that Mediawiki.org thread from VisualEditor News #6—2015. 3 of the 11 editors in that thread mentioned problems with the Flow software used in that thread. Others may have had problems and did not bother to comment. That thread's topic was not about Flow. I think that is pretty significant. And if English Wikipedia has deleted almost all its Flow pages one by one due to people not using them, I think that is significant. Obviously, Flow is not ready for prime time. I never really saw a need for a complete rewrite of the talk page software. But anyway, my main point is that the number of Flow pages on Mediawiki.org should go down, not up. They should be eliminated altogether from Mediawiki.org for now. Mediawiki.org is too important. --Timeshifter (talk) 09:12, 30 December 2015 (UTC)[reply]
DJ, It's interesting that you say I'm running an anti change campaign. I believe I'm speaking for consensus, and that the WMF has been campaigning to get Flow to where it is. "Where Flow is" is that Flow deployment has stopped on EnWiki and most Flow pages are either gone or are about to be gone. If you disagree with our view on Flow, that's fine. But please don't imply we have a fringe view unless you're prepared to open an RFC proposing to move forward with Flow deployment, with a sincere belief that it might pass. I would welcome a Village Pump discussion to clearly ascertain the general consensus towards Flow. Alsee (talk) 09:52, 30 December 2015 (UTC)[reply]
Re "running an anti change campaign", Flow is a clear case of "Our current editing scheme/software has several known problems. Something must be done. Flow is something. Therefor implementing Flow must be done." Give us something good that replaces the current system and we will be a lot more open to change. If I resist switching our drinks from coke to pepsi you could accuse me running an anti change campaign, but if I resist resist switching from coke to sand, I am not running an anti change campaign but rather pointing out that sand does not have the attributes that allow it to function as a beverage. --Guy Macon (talk) 10:14, 30 December 2015 (UTC)[reply]

(unindent). Here is a comment below about Flow from my talk page. It is from User:Alsee in reference to my comment about Flow in this MediaWiki.org thread I previously mentioned higher up in this Village Pump discussion.

What you saw was Flow.

  • The WMF has been eliminating most of their talk pages (user pages and some major mainspace pages), so you're forced to use Flow if you want to contact them to discuss problems with their projects. A particular problem is that they switched over all official contacts points related to Flow itself! That is particular problem for discussing Flow bugs. (Writing about the bug *in* Flow triggers the problem!)
  • You've only seen the tip of the iceberg. The list of problems with Flow is 142 feet long. Copy-paste is broken. A simple revert destroyed my original comment. Problems with templates. History is a disaster. The reply-threading turns modest-size discussions into unreadable spaghetti. You can't delete your own comments, much less someone else's. (You "hide" it, which leaves a link for it on the board.) IMO the biggest issue is that Flow does not store an accurate stable copy of what you write! Flow can randomly rewrite your formatting codes and nowikis etc. The way Flow works is kind of like translating your text into Russian, then translating it from Russian back to English when someone views or edits it. Sometimes those bugs can mangle your entire post into garbage during the rewrite. In fact Flow preforms that round-trip translation every time you try to preview what you wrote. So you preview, return to editing your wikitext, and Flow has REWRITTEN your wikitext! It's like editing on quicksand. There's no "truetext", everything Flow shows you is an illusion created on the fly.
  • It seems the WMF still wants to eventually get Flow deployed, but the good news is that they've realized that there are serious objections here. They have been *trying* to improve their relations with the community ever since the superprotect incident, with limited success. Putting Flow on hold has been one of the successes. The current official policy is that no Flow pages will be deployed without local consensus requesting it. I think they are hoping the tiny wikis start accepting it, and that eventually all the 'obstructionist-change-averse editors' get dragged along into the wonderful future. BTW there's a doc page where "Admins" and the most "Experienced" editors are defined as the change-averse groups. Lols.
  • There used to be 7 Flow pages on EnWiki. Activity has dropped to zero on every board where Flow gets deployed. One board was the Flow testing board: it died and was never fixed after an admin tried testing admin tools on it. I had a pair of abandoned boards deleted at MFD. I have another abandoned board at MFD with unanimous deletes so far. I have an open RFC at a dead wikiproject to roll back Flow - I *think* its passing but running an RFC inside Flow is a disaster. We can't move the discussion posts down to a separate discussion area, it's almost impossible to tell who is replying to who, and it is difficult to figure out which posts are !votes. Anyway, assuming it passes, that will leave us with two dead Flow pages. It's possible that EnWiki will be Flow-free in a month or two. I need to contact some of the other language Wikis with Flow to see if they want to move forward with Flow or start rolling it back. Alsee (talk) 17:28, 24 December 2015 (UTC)[reply]

VisualEditor News #6—2015 sent people to the MediaWiki.org thread. VisualEditor News #6—2015 is also still on this Village Pump page. --Timeshifter (talk) 13:48, 29 December 2015 (UTC)[reply]

I'm pretty sure that everyone in this discussion is capable of finding my talk pages and WP:VisualEditor/Feedback here at en.wp, none of which have Flow. I'll make sure that the information gets passed along. (For those who haven't read the thread there, yes, I have explicitly posted this as an option in the mw.org for anyone who's struggling with Flow. So far, nobody has taken me up on that offer.) I'll even take Flow bug reports, although I've got nothing to do with that product. (If you're feeling "stuck" in Flow, then the most important thing for an experienced wikitext editor to know is that you should click the "[[ ]]" button in the lower right corner, and then proceed with plain old wikitext.)
Whether some other wiki ought to do something else cannot be decided here. What another wiki chooses to do is up to the community at that other wiki. If you want to change things there, then you need to actually have the conversation there. Whatamidoing (WMF) (talk) 18:40, 30 December 2015 (UTC)[reply]
Whatamidoing (WMF), doesn't the link to the Flow text editor look more like this: {{}} ? PS: I like a lot of the features of Flow. One thing I did not care for was the refresh time for paging down when scrolling down page by page. Cheers! {{u|Checkingfax}} {Talk} 08:26, 31 December 2015 (UTC)[reply]
Eventually, someone will attempt to implement WP:Flow here. If Flow is failing miserably at other wikis, I want to know about it.
For example, the history of the Feedback page you can't click "prev" in most edits?? When looking at past postings, I can't see what the whole topic looked like at a certain date?? This kills my main user cases. I can understand why editors would abandon Flow boards..... Flow looks like a much bigger clusterfuck than talk pages ever were. --Enric Naval (talk) 19:55, 30 December 2015 (UTC)[reply]
  • I for one don't like flow, and the moment it gets forcibly added to my talkpage, and other places I visit, is the moment I leave Wikipedia. I hate it. One big reason is, what the hell is up with those topic names?? I'm glad the project has been abandoned, because it means I won't have to deal with flow. Testing it left a bad impression with me.—cyberpowerChat:Online 21:01, 30 December 2015 (UTC)[reply]
  • More than 90% of users that go to mediawiki.org are users that have not edited on any other wikis on wikimedia and if they find "flaw" unbearable, unwelcoming or hard to use, why the hell are we trying to enforce it on all wikimedia wikis?.. the idea itself is over 3 years away from being implemented cause it has more "flaws" than then number of hair on your head (if you are not bald or balding)....I can honestly say its anti-user friendly and should not be enforced on mediawiki for now..--Stemoc 02:16, 31 December 2015 (UTC)[reply]
  • One very annoying feature with Flow is that each topic needs to be individually added to my watchlist and that I need to remove all topics individually whenever I wish to unwatch a talk page. The standard talk pages do not have this problem; watching and unwatching one page automatically watches and unwatches all topics. --Stefan2 (talk) 12:46, 31 December 2015 (UTC)[reply]

Display language

Using the Display Language feature in language settings, I have my display language set to English; on many but not all other language WPs it correctly translates at least some of the interface to English, and it's a very handy feature. But for the deWP, for some reason, the language displayed is Italian. Iknow what the headings mean, but it's peculiar. DGG ( talk ) 05:57, 29 December 2015 (UTC)[reply]

Does de:Special:Preferences say "en - English"? Try changing it away, save and change back to en. What interface language do you see at de:Wikipedia:Hauptseite and at https://de.wikipedia.org/wiki/Wikipedia:Hauptseite?uselang=en? I have en and see English at both. PrimeHunter (talk) 13:14, 29 December 2015 (UTC)[reply]

Page image

Can somebody explain me, what are the criteria for picking "page image" to database, that is included as "Page image" at page information and "page_image" (for pp_propname) in page_props table? More importantly - what kind of images are not picked? Here are two examples with different results (where I would expect only one result) - Ashville, Alabama (there is "page image") and Alamo, Tennessee (there isn't "page image"). --Edgars2007 (talk/contribs) 09:24, 29 December 2015 (UTC)[reply]

The code comes from mw:Extension:PageImages. From the description page: "[The extension's] aim is to return the single most appropriate thumbnail associated with an article, attempting to return only meaningful images, e.g. not those from maintenance templates, stubs or flag icons. Currently it uses the first non-meaningless image used in the page." Glancing through the code, I see that images are given a score based on their size and whether they are blacklisted. — Mr. Stradivarius ♪ talk ♪ 10:14, 29 December 2015 (UTC)[reply]
Thanks. --Edgars2007 (talk/contribs) 11:12, 29 December 2015 (UTC)[reply]

idea to improve wikipedia

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

dear wikipedia organisation,

as a regular user of your webpage I have a suggetsion to add to the articles.


I, and im sure many other reader as well, would be thankful if there was a automatic readers voice that could read the article to the user.


>this would help ppl who want to learn the language (I myself regularly use wikipeda to practise languages im not fluent in by reading the articles in both the foreighn and my native language) and are struggling with pronouncing certain words. >it would help blind or old people who cant read (well) >it would help ppl with a low concentration capacity to not always get lost in the articles and get distracted.

i hope you take my suggestion into concideration and i hope ii send this to the right department. I simply couldnt find another place to submit it — Preceding unsigned comment added by 178.189.196.12 (talk) 11:05, 30 December 2015 (UTC)[reply]

Closing per WP:MULTI; also posted to Wikipedia:Village pump (proposals)#idea to improve wikipedia. – nyuszika7h (talk) 11:43, 30 December 2015 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Emailing issue

I've been trying to send emails to other editors for an interview and my email keeps getting unsubscribed due to "multiple message delivery failures". I have no clue how to fix this as every time I subscribe my email, when I email someone again, I get unsubscribed once more. GamerPro64 17:21, 30 December 2015 (UTC)[reply]

You will have a better result if you post the above question to our help desk. --Guy Macon (talk) 22:34, 30 December 2015 (UTC)[reply]
Why? This seems like a technical issue; they'd probably be sent straight back here. Sam Walton (talk) 12:32, 31 December 2015 (UTC)[reply]
@GamerPro64: Could you give the exact error returned (minus any identifying information) - you may wish to paste it to a sub-page of yours or use a secure pastebin -- samtar whisper 12:37, 31 December 2015 (UTC)[reply]
GamerPro already posted to Wikipedia:Help desk#Emailing issue as suggested, and got a good reply about the Yahoo DMARC issue. PrimeHunter (talk) 15:17, 31 December 2015 (UTC)[reply]
No worries, thanks for letting me know PrimeHunter -- samtar whisper 15:31, 31 December 2015 (UTC)[reply]

A challenge for anyone who supports Wikimedia Flow.

Note: Anyone unfamiliar with Flow can freely try test posting at the Flow mw:Talk:Sandbox.

Background: When the Flow project was first proposed, the Wikimedia developers insisted that [A] no existing software was suitable for Wikipedia talk pages, [B] no independent software vendor was qualified to create Flow, [C] If the Wikimedia developers were allowed to create Flow, it would come in on time, under budget, and [D] the users of Wikipedia would embrace the result as being better than what we are doing now. If I were in charge of the project, there would be documentation posted somewhere on the Wikimedia website that attempted to prove [A] and [B] with a detailed evaluation of multiple existing software packages and multiple vendors. I would also expect them to provide evidence that [C] and [D] are reasonable claims, perhaps by pointing out how well the Visual Editor project worked out.

I have a simple challenge for anyone who supports Wikimedia Flow. Please look at the following Free and Open Source software:

After looking at the above software, can you honestly say that Flow is better suited for Wikipedia talk pages? Can you honestly say that any upgrade to Flow that can be created in a reasonable amount of time is better suited for Wikipedia talk pages?

And now a challenge for those who dislike Flow:

After looking at the above software, can you honestly say that what we have now is better suited for Wikipedia talk pages? Please keep the Baby Duck Syndrome in mind and imagine the respose I would get if I was proposing new talk page software that requires a reminder to add four tildes at the end of your comment, requires a bot to fix it if you forget, and allows you to edit anyone's comment (including forging the signature) in a way that is invisible without checking the history?

I think that it is time to reexamine the alternative of starting with existing Free and Open Source software, then hiring someone to customize it as needed for use on Wikipedia talk pages. --Vlad Putin (talk) 16:17, 31 December 2015 (UTC) <--- forgery | real sig --> --Guy Macon (talk) 16:17, 31 December 2015 (UTC)[reply]

Given that we are a wiki, and by definition must have a system for editing documents including templates, wikilinks, advanced formatting etc, I actually think it makes a great deal of sense to use the same system for discussions. At a minimum any replacement must accept all of the same markup syntax as is used when editing articles. There is no doubt that there are some significant areas for improvement, but most of these could be addressed with low-drama tweaks to the existing system (auto signatures, "reply" link automatically added to each comment, etc). But I don't believe that the pain associated with the current system is anywhere near severe enough to justify throwing it out, particularly if it would be replaced by something significantly less capable (c.f. Flow). And for what it's worth, the current system is very far from being the first forum/discussion system I have used so I don't think I'm baby-ducking on this one. Thparkth (talk) 16:15, 31 December 2015 (UTC)[reply]
  • I used multiple forum sites, including one running phpBB, before starting at Wikipedia or MediaWiki, and I can honestly say that (IMO) what we have now is better for our talk pages. You can sandbox content, make unobtrusive redactions, and view the entire history with MediaWiki, not to mention the best feature, which is the immense power of wikitext, templates and Lua to make and customise a variety of processes tailored to our needs. Perhaps this is not necessary on all talk pages, but using multiple systems is worse than putting up with minor annoyances in a single one, but of content incompatibility (as others have demonstrated with Flow) and just having to be fluent in multiple systems. BethNaught (talk) 16:54, 31 December 2015 (UTC)[reply]

  • If I'm having any "baby duck" issue, I'd be requesting systems that resemble a bulletin board system, or perhaps a newsgroup. (Cue cracks about showing my age). So I don't think that's at issue with me. Wikitext would probably not be a great choice for a system designed to be a pure discussion forum, which the software you cite often is used for. That's just fine. But this is not primarily a discussion site. Article talk pages are intended for work on the article. That may mean that sometimes, users need to copy over chunks of text to work with or discuss. Sometimes, I've even seen an entire article be copied into a Talk subpage, for editors who disagree to try to figure it out without worrying about the state of the "live" article. Using the same setup for talk pages as article pages allows that type of thing to happen. They are powerful, flexible, and work the exact same way the corresponding article page does.

    Additionally, our community isn't like others. If someone comes along and spams "Make eleventy billion dollars working from home!!!!1111!!!!" or "YOU ALL SUCK!!!!!!!!!" crap on a talk page, we don't want to have to have an admin come along and remove it. Anyone can. (That is even more true when the garbage is harassment or a blatant BLP violation). I have not yet once heard of talk page signature forgery being at issue, and why would it be? As soon as someone says "I never said that!", they, or someone else, will immediately go check the history to find out who did. I would consider deliberately forging someone else's signature in an attempt to harass or joe job them to be worth an immediate indef. But I've just never even heard of it happening, except perhaps from a few instances of blatantly obvious vandalism. So for those reasons, I just don't see the benefits of Flow (or the other systems you cited) being worth the tradeoff of losing the power and flexibility talk pages provide. We could make talk pages better, likely (perhaps auto-signing of posts being available as a preference and triggered by a flag on the page, as an example), but I don't see replacing them with something that's not wikitext. Seraphimblade Talk to me 17:42, 31 December 2015 (UTC)[reply]

    • This is irritating. I keep coming along behind User:Seraphimblade and find he's said what I wanted to say, only better. Yes please, don't make changes that make talk pages work in a form basically different to article pages. I also frequently copy over material from articles. And anyone should be able to revert spam/vandalism/socking etc edits on talk pages. Doug Weller talk 19:46, 31 December 2015 (UTC)[reply]
In a bid to understand-- is Flow the software I am using now? Is the proposal to set up a bulletin board system? Is the issue the wikisyntax that I can type in my sleep, or the text-editor that I dream of patching into Firefox?
There are a couple improvements I would like to see- like the ability to display two character subset panels at the same time- or set up a custom one. ( I have a gedit file that does that job). Like a drop down menu of my favourite templates- such as efn sfn convert. Like being able to customise the number of lines displayed on the fly- oops I have just found that button- wow. Default autosign would be useful. Clem Rutter (talk) 19:06, 31 December 2015 (UTC)[reply]
See mw:Flow, and for an example mw:VisualEditor/Feedback. PrimeHunter (talk) 19:31, 31 December 2015 (UTC)[reply]
I have to say, the idea of making incremental improvements on what we have now is quite appealing. Especially if the WMF gets away from the mentality that prevents them from paying a software development company to do that for them instead of giving the job to the organization that produced Visual Editor and Flow. --Guy Macon (talk) 20:11, 31 December 2015 (UTC)[reply]
I would also like incremental improvements. Some of them will be imperfect because talk pages aren't set up with clearly defined posts and fixed sections but many things could be done without starting over without MediaWiki features we are used to and like.
  • Automatic signing cannot be done reliably but then make it semi-automatic. Run a Sinebot-like test on save and ask the user whether to sign, or always do it depending on a preference.
  • Section watching cannot be done reliably because sections can be renamed, archived, and full page edits can make changes that are hard to identify correctly in diffs. But allow section watching anyway and give a warning (depending on a preference) if the software can no longer identify the watched section. Many section renames are easy to detect in diffs, and archiving could introduce standardized procedures that tell the software where a section goes as long as the recommended procedure is followed, for example wikilinking the archive in the edit summary which removes the section.
  • Indenting is hard to automate with the current system but then semi-automate it. If any indentation at all is used then accept it. If no indentation is used in an addition of a paragraph then ask the user whether they are replying to the preceding post or something else. There will sometimes be wrong indentation but it could be made to usually work. Maybe add a small reply link after identified signatures (with a disable option in preferences) to reply to that post, automatically adding one more indentation.
As long as new features which may annoy power users come with a preference to easily disable them, the drama about changes will be reduced a lot. PrimeHunter (talk) 21:28, 31 December 2015 (UTC)[reply]
All points well taken here except maybe for the 'Section Watching' one. Besides getting the HTML5 semantic/heading element bits up and running under mark-up already (don't get me started), all we really need to do is treat "sections like an extension of the PAGEID magicword ({{PAGEID}} = 3252662 in this case) approach and assign each "section" its own unique id too. No more fumbling around with ascii/escape/control/Unicode character considerations, no more ltr/rtl concerns, no more language translation issues; the possibilities go on and on and on. The User: will never "see" anything different when it comes to page titles, section names or target anchor linkages to boot.

Nice to dream aloud once in awhile <sigh> - George Orwell III (talk) 23:33, 31 December 2015 (UTC)[reply]

  • The other forum software cited is useless here because wikipedia isn't a forum. It's a workplace. Wikicode gets tossed about as part of that work. Our pages have all the power and features of article space because talk pages *are* article pages. We can copy-paste anything from anywhere to anywhere, do anything anywhere, and literally move any page from anywhere to anywhere. There is an underlying simplicity in that powerful system. There are tradeoffs whatever system we use. If the software had been designed from the start *by* the community *for* the community, maybe it would have been worthwhile. For a while I was submitting bug reports and improvements, but then I realized it was counterproductive. Developer time is a limited and valuable resource, and I realized it was just diverting them to do work that shouldn't actually be done. Imagine all of the improvements we could have gotten if the WMF hadn't sunk god-knows how many man-years of work on Flow. The current system hasn't been improved because the WMF decided not to improve it.
Regarding section-watching, it was on the Community Wishlist but it didn't get enough votes to make the cut. The WMF was talking about complicated and difficult ways to reliably track sections - bad idea. Simply ignore edits that don't touch an existing section. In the worst case it would alert you to an edit that causes the software to lose track of that section - like if someone moves the section and renames it. That is an edit you want to be alerted to anyway. It's no big deal if that case forces the software to ask you which section (if any) you'd like to select as a replacement-watch item. Alsee (talk) 00:37, 1 January 2016 (UTC)[reply]
Hmm, section watching was supported by the German Community Wishlist, but already back then did developers caution that the rewrite of core software that would be required to support that section may be too impractical to happen.Jo-Jo Eumerus (talk, contributions) 00:51, 1 January 2016 (UTC)[reply]
Of course it was poo-pooed; it would have needed the required HTML5 elements vetted and in place, have 'defined' how those elements must be applied in order to consistently detect &/or generate document outlines that are "usable" and a period of trial and error testing before it was made 'permanent'. If a page can be tracked for "changes", its only because the 'foundation and position' of that page has been well establish and consistently the same. Define a 'section' the same way a page (article) is at its most basic of components and the same 'tracking' very could have been done with sections.

Heck, have every section reside on a sub page of the root main page and transclude them all in for viewing - problem solved; your section is really a page. If you look at it that way, its really not all that different than what we have now.

So, if you can't even keep "pace" with the basic advances & improvements provided by new specs and better agents, its no mystery to me why participation is dropping off. "Whaaa.... we'd be stranding tens of thousands of current users if we kept pace" or whatever was a poor excuse not be ready to hit the floor running next month any way you cut it imho. -- George Orwell III (talk) 04:28, 1 January 2016 (UTC)[reply]

Mobile app including HTML tags in edit summary section titles

I noticed that this edit's summary includes <i>...</i> tags. This does not happen on the normal web interface, formatting in section titles is normally just thrown away. I guess a Phabricator ticke should be opened for this if there isn't one already, but it's too late right now for me to make a proper bug report. nyuszika7h (talk) 00:54, 1 January 2016 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=697687014"