This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
Edits (rather than the text of edits) being imported into Wikipedias of other languages
Long past the point where anything of great value remains to be said. --Izno (talk) 03:13, 23 January 2018 (UTC)[reply]
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.
(Before the heading title above raises false alarms that my account's login credentials have been somehow compromised, they have not. This issue appears to involve some sort of (new?) MediaWiki importation tool.)
I've been editing Wikipedia for a long, long time, around a decade and a half, during which many articles I wrote or contributed to have been copied and pasted and translated into Wikipedias of other languages. That's fine/great; no problem! I'm happy/delighted to share the results or work product of my edits in other languages! But I just encountered something new and different.
I was just given a welcome message to the Bihari Wikipedia by another user, thanking me for my edits there. This surprised me as I don't speak or understand the Bihari languages, so why would I ever have edited there? So, I checked bh:Special:Contributions/Lowellian. And I recognize those edits: I did make those edits, but I made those edits to the English Wikipedia, not the Bihari Wikipedia!
After poking around the page histories some more (and navigation is difficult due to the aforementioned fact that I don't understand Bihari, so I have to do some informed guesswork clicking on links), for example https://bh.wikipedia.org/w/index.php?title=Template:Countries_and_territories_of_Southeast_Asia&limit=500&action=history, I can see that my edits have been somehow "copied" from the English Wikipedia to the Bihari Wikipedia, and in a way different from a normal page move: normally, when a page is moved, the edits are also moved with it so that each edit still only appears in one page history (unless it was a copy-and-paste move, in which case the text of the edits but not the edits themselves get copied/moved). But this situation appears to be something different, in which my edits are now duplicated so that the same edit history appears on both the English and Bihari Wikipedias, accredited to me.
This is fundamentally different from normal copying-and-translation of articles into other languages since that copies the prose/text (the work product of edits) rather than the actual edit history (the edits themselves). This concerns me because those page histories make it look like I have been editing the Bihari Wikipedia when I have never done so. I don't want, for instance, people complaining to me about edits I made on another-language Wikipedia that I had no knowledge of and did not make. (This is different from normal copying/translation of articles into other-language editions, since normal copying/translation doesn't make it look like I directly edited those other-language editions.)
This all appears to be done by some sort of (new?) MediaWiki importation tool? Can someone in the know provide background for what all is happening here?
@Lowellian: from bhwiki's log I can see that @SM7: has imported these using the normal transwiki import process. This part is OK and normal. phab:T179832 describes some of the intricicies of imported usernames and how it is being dealt with. — xaosfluxTalk 23:32, 12 December 2017 (UTC)[reply]
Okay, I don't really understand the issues described in phab:T179832 or whether they apply to this specific case, but maybe someone can at least clear this up for me: if you look at https://bh.wikipedia.org/w/index.php?title=Template:Countries_and_territories_of_Southeast_Asia&limit=500&action=history, some edits are marked "imported>" followed by the username. My problem is that my edits, at least, seem to have been imported without even that "imported>" designation, as if I made the edits directly to the Bihari Wikipedia, when I did not. My edits should be marked "imported>" if they were imported. Is this something that has been looked at and fixed so that it won't happen in the future? —Lowellian (reply) 23:41, 12 December 2017 (UTC)[reply]
See meta:Help:Import for the feature. It's from 2003.[1] You can select English as interface language at Special:Preferences at a foreign wiki. This may make it easier: https://bh.wikipedia.org/wiki/Special:Preferences?uselang=en. I don't know when an edit will say "imported>". I haven't seen that before so the anomaly may not be that it's "missing" from you but that it's shown for some of the others. PrimeHunter (talk) 00:02, 13 December 2017 (UTC)[reply]
The import process recently got a few enhancements, which is what phab:T179832 was talking about.
When importing edits, the importer must specify the source of the import, and can choose whether imported edits by users who exist in SUL are attributed to the local account for the user or in a fashion like "en>Example" that links to the source wiki from the edit history.
Of course, we also have over a decade of imports that were done under the previous system, where edits were attributed to a local user even if that user didn't exist. A cleanup script is being run on the servers to update the attribution to the SUL user where possible and with a "imported>" prefix otherwise. Since Lowellian's account is in SUL, they were attributed to that SUL account. BJorsch (WMF) (talk) 02:00, 13 December 2017 (UTC)[reply]
Thanks for the explanation. In that case, I would like to strongly make the following suggestion: in all cases when edits are imported, including for SUL accounts, there should always be some sort of marker/designation in the page history that the edit is an import in order to avoid the incorrect implication that the editor made that edit directly to that particular language-edition Wikipedia. It is inconsistent and misleading that only some users' imported edits are marked as imported while other users' imported edits are not marked as such, and unfair to make users look like they were spamming English edits onto Wikipedia editions in other languages when they did not do so. —Lowellian (reply) 02:38, 13 December 2017 (UTC)[reply]
The best place to make suggestions is in Phabricator. The best indication would probably be a tag. But note there's no way to reliably identify all past imported edits. Anomie⚔ 14:07, 13 December 2017 (UTC)[reply]
Local accounts attached without a visit (and welcomed without an edit)
Today I have been getting Welcomed on both the Latvian and Kazakh wikis. I have never edited over there. I checked my contribs over there, but nothing shows. Could this be part of the same issue [ the previous topic about imported contributions ]? Bit of a coincidence that they both happened today and it has never happened before. — Insertcleverphrasehere(or here) 07:26, 13 December 2017 (UTC)[reply]
This is exactly what the previous topic is about. These welcome messages are being triggered by your edits being imported over to other-language-edition Wikipedias without your knowledge, making you look like a new editor to welcomebots, so they start leaving you welcome messages. Everyone complaining here, please add your voice to that topic if you have complaints about how this process is happening. It is wrong that edits from the English Wikipedia are being imported over to other-language Wikipedias without any indication that those edits are imported. —Lowellian (reply) 21:16, 13 December 2017 (UTC)[reply]
It happened on the Punjabi Wiki as well... What is going on here? — Insertcleverphrasehere(or here) 10:38, 13 December 2017 (UTC)[reply]
Insertcleverphrasehere, local wiki accounts get attached to your global account the first time you visit that wiki while logged-in. All three of lv:, kk: and pa: were attached to your account this morning. On some wikis you automatically get a welcome message the first time you log in. So I don't think this has any relation to the topic of imported edits (and have therefore separated this topic from that section). --Pipetricker (talk) 11:41, 13 December 2017 (UTC)[reply]
Turned out I was wrong about that. --Pipetricker (talk) 10:56, 17 December 2017 (UTC)[reply]
I wonder why all three happened today though? Must be the rollout of some kind of welcome bot. — Insertcleverphrasehere(or here) 11:47, 13 December 2017 (UTC)[reply]
As Pipetricker said: "local wiki accounts get attached to your global account the first time you visit that wiki while logged-in. All three of lv, kk and pa were attached to your account this morning." According to Special:CentralAuth/Insertcleverphrasehere you visited a large number of wikis for the first time today. Many users have been confused by such welcome messages in foreign languages. I have thought about suggesting at meta to ban welcome messages to users who have no edits at a wiki and didn't create the account there but just had it created automatically by viewing a page. PrimeHunter (talk) 11:55, 13 December 2017 (UTC)[reply]
Well, I definitely didn't visit all of those wikis today. I did however submit a SQL Query on Quarry for the first time, which required me to authorise it on Mediawiki, which is probably related? Still strange though. — Insertcleverphrasehere(or here) 12:04, 13 December 2017 (UTC)[reply]
That's unrelated. I have done no such thing recently and was welcomed on three wikis also. :) --Izno (talk) 12:23, 13 December 2017 (UTC)[reply]
Izno, are you saying the SQL query is unrelated to the attachment of a number of local accounts at about the same time, despite Insertcleverphrasehere not having visited those wikis? --Pipetricker (talk) 14:04, 13 December 2017 (UTC)[reply]
Yes. --Izno (talk) 15:41, 13 December 2017 (UTC)[reply]
Actually, it probably is related. The process of attributing those old imported edits to the SUL account includes creating the local account for the attribution to belong to, which would trigger the welcome message on wikis that do automated welcome messages on account creation. Anomie⚔ 14:10, 13 December 2017 (UTC)[reply]
I'm seeing this too. Of the 32-and-still-rising wikis that Special:CentralAuth/Cryptic says I attached in December 2017, I've only ever been to two - Gujarati Wikiquote and Persian Wikivoyage, and those only afterward, because I can'tcouldn't get the notifications for the welcomebot messages to go away no matter what I try. —Cryptic 14:50, 13 December 2017 (UTC)[reply]
(In case that crops up for anyone else - what finally worked was logging in directly on those wikis and checking off the notification at Special:Notifications, not just the dropdown on the sidebar.) —Cryptic 15:21, 13 December 2017 (UTC)[reply]
I notice now that ilo.wikipedia.org was attached to my account tonight, when I was asleep and my computers were turned off. It's not in my browser history previous to that, and I have no contributions there (and have received no welcome). --Pipetricker (talk) 15:10, 13 December 2017 (UTC)[reply]
My wuu.wikipedia account was created 45 minutes ago when my computer was turned off. There is clearly some current process creating accounts at other wikis without user action, maybe releated to work on phab:T179832: "Handling of imported usernames". I don't currently have edits registered at wuu:Special:Contributions/PrimeHunter but maybe there are old imported edits somewhere which have not been added to my contributions. PrimeHunter (talk) 16:05, 13 December 2017 (UTC)[reply]
Yes, there is some current process, as I stated in the section above. See phab:T181731 for the task about it. I note that the script is already done with all the "small" wikis. The wikis still in progress or pending are dewiki, enwiki, eswiki, fawiki, frwiktionary, hewiki, huwiki, itwiki, jawiki, kowiki, metawiki, nlwiki, nowiki, plwiki, ptwiki, rowiki, ruwiki, svwiki, thwiki, trwiki, ukwiki, viwiki, wikidatawiki, and zhwiki. BJorsch (WMF) (talk) 00:40, 14 December 2017 (UTC)[reply]
If the script is still pending for larger wikis, then those future runs should be stopped and held off until the problems people are complaining about are fixed. As a starting point, per User:Anomie's suggestion above, it should tag imported edits of SULs as imports instead of misleadingly implying that they were normal edits to Wikipedias of that particular language-edition. —Lowellian (reply) 06:33, 14 December 2017 (UTC)[reply]
I see those things as honestly unnecessary. It causes a one-time notification on a per-wiki basis where any of your edits have been imported. Given that there are only 20 wikis left, spending time now would only prevent finishing the task while waiting for the extra work that is already planned-for down the road. --Izno (talk) 12:26, 14 December 2017 (UTC)[reply]
The problem is not really the welcome notifications. That's just a side effect / symptom of the ultimate cause and real problem, that we are being attributed, without our permission, to edits that we did not make. —Lowellian (reply) 20:58, 14 December 2017 (UTC)[reply]
We made our edits to articles which according to the licences we agreed to can be copied provided they are attributed. So it seems to me we agreed to the copies being attributed to us. (Maybe I misunderstood what you mean, but any way if it isn't a technical issue the tech Village pump isn't really the place to discuss that.) --Pipetricker (talk) 23:26, 14 December 2017 (UTC)[reply]
Attribution has multiple components: who wrote something, what was written, when it was written, and where it was written. The problem is that imports without tagging misrepresent one of those components: where it was written. These attributions aren't accurate because they are edits made to a specific wiki that are now being attributed as edits to a different wiki. And this is certainly a technical issue: it started out as a technical question asking why certain unusual behavior was being noticed, and it has continued as a technical discussion that includes how to, on a technical level, get those edits properly attributed; see the comments below where Xaosflux works out a technical solution to add tagging. —Lowellian (reply) 23:40, 14 December 2017 (UTC)[reply]
When you make an edit, above the edit box there is a notice containing the sentence "Work submitted to Wikipedia can be edited, used, and redistributed—by anyone—subject to certain terms and conditions." So by making the edit, you implicitly gave permission for reuse. Checking those T&Cs, I see that attribution allows several alternatives; one of them is "or c) a list of all authors". By crediting each individual edit to the person who made that edit, even if that edit was on another wiki, sufficient attribution is given. --Redrose64 🌹 (talk) 11:21, 15 December 2017 (UTC)[reply]
No, it isn't, and the legal language being quoted here only says that reuse and redistribution is allowed with proper attribution, which actually supports my point. Wikipedia allows reuse and redistribution with proper attribution, and the problem here is that the attribution is wrong. Redistribution copies text without claiming that the text was originally written directly to the copy. An attribution that claims someone wrote something somewhere that they did not write it (directly to the copy, instead of somewhere else that is then reproduced by the copy) is a fundamentally incorrect attribution, particularly when, as in this case, the copy is only a partial, non-identical copy, being in a different language. Copying over text from one wiki to another is not the same thing as claiming someone wrote directly to a wiki that the person did not. —Lowellian (reply) 22:32, 19 December 2017 (UTC)[reply]
I see you have twice listed four alleged requirements for proper attribution. The policy at Wikipedia:Copyrights#Re-use of text says that attribution under CC-BY-SA has exactly one requirement, namely that you must "provide credit to the authors". It further says that "a list of authors" (even if just plain text), is adequate. Do you believe that the policy is wrong? Can you find anything in Wikipedia:Text of Creative Commons Attribution-ShareAlike 3.0 Unported License that requires, for example, that attribution include "when it was written"?
Why does it actually matter to you that your revision has been copied from the enwiki database over to another one, without saying "copied from this other database" on it? Do you think that someone (who?) will think you've done something disreputable, as a result of omitting such a label? If you're familiar with the 5 Whys analysis, then I'm very interested in the "fifth why", or the underlying problem.
Exactly, attribution must "provide credit to the authors". That is the problem: when a credit claims someone wrote something somewhere that they did not write it, then that credit is wrong, since the actual editor is the import script, not the person claimed by the import script. Consider the following example: Alice adds the text "lorem ipsum foobar" to an article. Bob copies that "lorem ipsum foobar" text and then pastes it into another article. Alice may be the originator of the text, but the edit history would correctly show Bob, not Alice, as the editor who added it to the second article. If that text is disputed on the second article, then Bob, not Alice, is accountable for adding that text on the second article. But here, the import script is breaking that standard and instead giving the false appearance that Alice was the editor who added the text to the second article, so that Alice becomes the person who is then held accountable.
False attribution is false attribution; it should be corrected without any further justification being needed. I would think that accuracy and truth are fundamental to the goals of Wikipedia as an encyclopedia. That said, at the very least, these wrong credits also give the false appearance that the author is spamming a wiki with text in the wrong language for that wiki. On top of that, different wikis have different stylistic guidelines regarding things like formatting or titling conventions. This gives the false appearance that the author is ignorant or willfully ignoring those guidelines and conventions. Furthermore, what if text added is controversial? The author could then potentially be accused of, for example, POV-pushing on a wiki that the author has never even edited.
Is there an example of "false attribution"? You might copy the URL of a diff from a history page on another Wikipedia. Lots of fake books are sold by scammers who have copied various articles. They usually include a list of authors from the history pages to comply with the re-use procedures, so your user name may be printed by them. It's not false attribution. Johnuniq (talk) 23:45, 20 December 2017 (UTC)[reply]
Let's have a look at a page that Lowellian created - Template:Undated (Revision history) and the same at bh.wikipedia - bh:टेम्पलेट:Undated (Revision history). Other people made edits, and checking the lists together, there is a remarkable correspondence, apart from one or two users like Enterprisey / APerson which can be explained as a username change back in May 2016. Oh, I see that I'm in both lists too. Did I make this edit? There's no denying it, guilty as charged. Did I also make this edit? Well, it says that I did, but I don't recall ever making that edit on that wiki. However, if that edit is going to be credited to anybody, I'd rather that it was credited to me and not to somebody else pretending that it was their idea. Am I kicking up a stink? No. --Redrose64 🌹 (talk) 23:57, 20 December 2017 (UTC)[reply]
If these attribution issues don't bother you, that's fine, but please don't just dismiss others' concerns as "kicking up a stink". I'm not the only one who has raised concerns about the behavior of these imports. Why is it so terrible to have an imported edit be credited to both the original author and the import script via an automated tag? Automated tagging doesn't hurt you in any way, while it improves the situation for those who do care about proper attribution. That's all I'm asking for: that the import script should place a tag indicating, in addition to the original author of the text, that the edit is an import, so that there is a way to distinguish between edits made directly and edits that are imported. —Lowellian (reply) 22:49, 21 December 2017 (UTC)[reply]
Do you see the imported edit as saying not only "Lowellian wrote this", but actually "Lowellian personally placed this content on this wiki"?
I don't think that's what's intended. The point is to identify who owns the copyright, not which software database you originally placed the content in. (In your example, the copyright holder would be Alice, not Bob; if Bob copied Alice's text from one article to another, then Bob needs to include an edit summary that identifies either who originally wrote the text or which article it came from). WhatamIdoing (talk) 18:02, 21 December 2017 (UTC)[reply]
Having the implication be "this user personally placed this content on this wiki" is not intended, but it is what is happening. That is why it is so important to have some sort of tag indicating that it's an import rather than something written directly. —Lowellian (reply) 22:49, 21 December 2017 (UTC)[reply]
Who do you think interprets it that way? Not you, of course, because you already know that's not what happened. Not the admin who imported it, or the regulars at any wiki where importing edits is typical, because they already know how it works. So who do you think would be both aware of these imported edits (i.e., not >99.9% of readers) and honestly confused by it? WhatamIdoing (talk) 01:28, 22 December 2017 (UTC)[reply]
The only reason that I even know about these imports is because of those welcome alerts that drew me into this issue. I've been an admin over a decade and still didn't even know about of this import mechanism until I started asking questions in this discussion, which makes it very likely that >99.9% of editors aren't aware there is an import mechanism and upon seeing those untagged edits while examining edit history (which will become ever more common as those wikis grow in the future and more and more editors join and edit) would think they were regular edits and not know that they were imports. This issue is fresh in the minds of the editors here in this discussion right now, but we cannot expect editors outside this discussion to be aware of it years from now. That's why we need a tagging mechanism, so there will be not be any long-term future confusion. —Lowellian (reply) 23:01, 22 December 2017 (UTC)[reply]
If you're a regular editor at a wiki where this is done, then you will have seen this in dozens of articles at your wiki. If you don't know, you'll ask, and one of the other regular editors will tell you.
This has been done for years at the German Wikipedia. It looks like you've got about 10 imported edits there for every "real" one you've made directly. The numbers are very similar for me. Apparently, neither of us have ever been asked about those imported edits. I don't think that I've ever seen a question or complaint about an imported edit, and I assume that's true for you, too, or you'd have already known that it was possible to import edits. I therefore think that it's reasonably safe to assume that the likelihood of some hypothetical future editor yelling at us for doing something "wrong" on another wiki is pretty close the actual experience of it never having happened before in all these past years. WhatamIdoing (talk) 07:10, 23 December 2017 (UTC)[reply]
Actually, that you're saying that this has been done for years at the German Wikipedia actually raises another issue about there being no way from the edit history to tell when the imports were done. But to get back to the original issue, only a very small number of my edits have thus far been imported to the German Wikipedia, concentrated on a few articles. It is not reasonable to conclude from a small number of imports that that there aren't going to be complaints as the number of imports grows. And I will reiterate that fundamentally, attribution should be correct without needing to be justified. Tagging imports helps the situation for those of us who care about this attribution issue and has no effect on those who do not care, so there's no reason not to do it. —Lowellian (reply) 17:22, 23 December 2017 (UTC)[reply]
You've had about 200 edits imported to the German Wikipedia so far, which the median editor would likely not describe as a small number, and about as many again across some other wikis (one at tewiki, two at arzwiki, three at gdwiki, orwiki, and lmowiki, six at mlwikisource, eight at hiwiki and simplewiki, 10 at elwiki, 12 at the testwiki, 15 at maiwiki, 20 at bhwiki, 24 at knwiki, 34 at mlwiki, and 52 at the English Wikibooks, for anyone who's keeping count).
And, as the edits are attributed to you, I suggest again that the attribution is already correct. It appears to be your personal preference for attribution to say which wiki you happened to be using at the time your original edit was saved, but I have found no actual requirement to do so. I'll cheerfully admit that I'm wrong on that point when you quote me a line from the license that says that attribution must include information about which sub-domain of which website you first posted your copyrighted content to, rather than just your name.
This is where the disconnect seems to be. You seem to have gotten the idea that there is only one "correct" way to provide attribution, and that this One True Way™ requires four specific details, and the current system provides only three of them. I can find no source that supports your belief that anything more than your username is required. For that matter, I can't even find out whether your alleged requirement of "where it was published" refers to the physical location where it was published, the legal/copyright location where it was published, or the name of the larger work that it was included in. (There is, after all, a big difference between "printed in China", "published in the United States", and "published as part of the Anthology of Something", and (given the realities of printing costs) all three of those might be simultaneously true for any given work.) So at the risk of sounding rather Wikipedian about this, please cite your sources. I've cited mine: the license doesn't mention any requirement beyond identifying (in some fashion) the human who originally created and licensed the work in question, and which work is so licensed. WhatamIdoing (talk) 03:49, 27 December 2017 (UTC)[reply]
The sources you cite do not support the argument that untagged imports are providing proper attribution. You've cited a license that says that for redistribution, credit must be provided to the authors. But this isn't a simple case of redistribution, and credit has not been provided to the authors. Redistribution should not change the meaning of the underlying text; if it does, then it is not just redistribution, but new authorship. Let's say Alice adds to the article on the planet Earth the text that "The subject of this article is the third planet from the sun," a true statement. Bob copies that same exact text ("The subject of this article is the third planet from the sun") to the articles on Pluto and on mathematics: those statements have now become, respectively, false and absurd. Should Alice be held accountable as a liar or vandal for text that she originated but whose meaning Bob altered by placing it on a different article? No.
Is Bob or Alice the author of that text on Pluto or television? It is at least as much Bob as Alice; Alice may have originated that text, but by placing that text in a different context that changes its meaning, Bob has also become an author. Similarly, since these import scripts are copying text to different articles in different contexts, the import scripts are also an author, and the attribution is wrong when it only credits the originator of the text, since the text no longer has the same meaning in this different context. This is why imports need to be tagged as such for proper attribution.
Again: Where are your sources, the ones that allegedly support your claim that "Lowellian wrote this" (complete with a link to your account, so that everyone knows which Lowellian we're talking about) does not "provide credit to the author"? I see repeated assertions and a whole lot of IDONTLIKEIT, but I also see zero sources behind those assertions. Can you please provide any (single) plausibly reliable source to back up your personal opinion? WhatamIdoing (talk) 20:06, 2 January 2018 (UTC)[reply]
I have absolutely provided a source: the license, which requires credit be provided to the authors. Where are your sources, the ones that allegedly support your claim that the entity posting an edit is not an author? I see repeated assertions and a whole lot of IDONTLIKEIT, but I also see zero sources behind those assertions. Can you please provide any (single) plausibly reliable source to back up your personal opinion? (Note that, for the previous last two sentences, I just reused your words in a different context, that of my argument. In the edit history of this page, this reuse of words is attributed to me, not to you, because their context has been altered as part of this comment that I am posting, demonstrating the principle in question: the editor is an author.)
I don't think you and I are going to reach agreement on this issue, so let's just agree to disagree, since the debate is academic at this point, given that Xaosflux provided below a solution to tag imports.
I'm still looking for the part in the license that says "It's not credit to the author if you don't identify the location". The fullest description of what it means to give "credit to the authors", to quote section 4(c) of the license, says: "You must ... provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author")."
Notice that dates are not mentioned in this definition of what it means to give credit to the authors. Notice that locations are not mentioned in this definition of what it means to give credit to the authors. Notice that websites (URIs) are encouraged but technically optional in this definition of what it means to give credit to the authors. I simply cannot find anything at all in here that supports your claim that there's been a license violation if someone imports your work without adding a note that says "and he posted it to the English Wikipedia first". WhatamIdoing (talk) 17:44, 12 January 2018 (UTC)[reply]
@WhatamIdoing: If you're going to try to restart a debate 10 days later, after not replying within that whole time, on a discussion page that receives many, many edits on other topics, at least give me a courtesy ping. After over a week without a response, I thought we were done here, but I guess not. From now on, whenever I post in response to a comment of yours here in this topic, I will give you a ping. Please do the same for me.
That citation you keep repeating does not support your point and is in fact contrary to it, since it requires credit for the authors. Nothing you wrote shows that the entity posting an edit is not an author. And license aside, it is against the ethos of Wikipedia to omit authors, give a misleading credit that implies someone edited an article they did not, and alter the meaning of a person's words while still attributing it to them by reposting those words in a different context.
As I said previously, let's just agree to disagree, since the debate is academic at this point, given that Xaosflux provided below a solution to tag imports.
What exactly do you mean by your claim that authors are being omitted by Special:Import? Your complaint above is that "edits are now duplicated so that the same edit history appears on both the English and Bihari Wikipedias, accredited to me" (emphasis added). You've said that you're actually getting credit for the work, and you're unhappy about that.
If you read the license above, what constitutes "credit" is spelled out in numbered detail:
name of author [NB: not full identity – just the name],
title the author gave the work (if any),
URL (if reasonably practical), and
acknowledgement of any subsequent changes.
Which part of those four numbered requirements do you claim is being omitted here? (This isn't entirely academic, because the solution below is not going to work in every case.) WhatamIdoing (talk) 23:47, 15 January 2018 (UTC)[reply]
@WhatamIdoing: You're just repeating arguments already made earlier which I've already rebutted. I don't want false credit for work/edits that I did not make, and the import mechanism, as the editor, is the author being omitted. I've already stated that I'm satisfied with Xaosflux's solution. So I don't know why you're continuing to extend this debate: what actionable technical change are you wanting to happen? —Lowellian (reply) 02:17, 16 January 2018 (UTC)[reply]
I think I'm trying to figure out why anyone would (apparently) think that a piece of software can be an author of anything. I cannot understand why anyone would think that merely copying something from one place to the other, with zero changes, would make either the file-copying software or the person who did the equivalent of typing cp file.text copy.txt, become an actual author of the original work. AIUI copyright law simply does not work that way. A person cannot become an author of a work merely by copying someone else's work. WhatamIdoing (talk) 17:48, 17 January 2018 (UTC)[reply]
I'm trying to figure out why anyone would (apparently) think that falsely naming a person as an editor is okay when the person didn't make the edit and has never even been involved with the wiki. I cannot understand why anyone would think that it is okay to alter the meaning of someone's work and then hold them responsible for that altered work with which they had no involvement or even awareness. We're not getting anywhere, and there doesn't even seem to be any actionable technical change you want, so let's just agree to disagree and let this debate end. —Lowellian (reply) 00:08, 18 January 2018 (UTC)[reply]
If you are seriously concerned about someone altering the meaning of your work, then, I'm really sorry to say this, but Wikipedia is probably not a good match for you. You might investigate whether there is a place for you to contribute that has CC-BY-SA-ND licensing (the "ND" part means that the license that does not allow people to change your work). Under Wikipedia's CC-BY-SA license, one of the risks that all editors take is the risk that someone will post their work, with their usernames, in other contexts and on other sites. (I understand that more than one admin has had some of their CC-BY-SA contributions copied to attack sites, for example.) If you were unaware of this risk and would be distressed to find your name and your work on a horrifying website, then you may wish to consider WP:VANISHing. I would be sorry to see you go, but Wikipedia's contents, for better or worse, get copied to a lot of sites, including some that are not nearly as innocent as a small Wikipedia. WhatamIdoing (talk) 18:44, 22 January 2018 (UTC)[reply]
There is no such license as CC-BY-SA-ND - the -SA and -ND are mutually exclusive, since -SA concerns subsequent licensing of derivative works (the wording is "ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original."), and -ND explicitly forbids derivatives (the wording is "NoDerivatives — If you remix, transform, or build upon the material, you may not distribute the modified material."). You may be thinking of CC BY-ND. --Redrose64 🌹 (talk) 21:49, 22 January 2018 (UTC)[reply]
@User:WhatamIdoing: That's a misportrayal of the situation. I have no problem with people altering my work, and I encourage it: that is at the core of Wikipedia, collaborative editing in which people alter others' work. Also at the core of Wikipedia is that people get correct credit for work. The problem here is not that work is being altered, but that credit is not being properly given for the work. What third-party websites do is irrelevant to this discussion; by definition, they are outside Wikimedia control, and no one uses them to confirm what edits someone made on Wikipedia. They check Wikipedia for that, and this discussion is about edit histories on Wikipedia. —Lowellian (reply) 02:26, 23 January 2018 (UTC)[reply]
Tagging imports
There's no way to reliably identify old imports to tag the edits, so that's not going to happen. The unexpected creation of accounts should be mostly done since most of the wikis are done. Anomie⚔ 13:56, 14 December 2017 (UTC)[reply]
But I'm not asking to identify old imports to tag the edits. I'm asking that future imports should tag imported edits as they are being imported. —Lowellian (reply) 20:56, 14 December 2017 (UTC)[reply]
@Xaosflux: Yes, that's great, thank you so much, that's pretty much exactly what I'm looking for! :) I don't know how involved you are in the process of these Wikipedia imports; are you in position to actually get that change done immediately for all future imports? —Lowellian (reply) 22:41, 14 December 2017 (UTC)[reply]
@Lowellian: I'm not working on the ticket, so here's the situation: any newly imported revisions will follow that already - its already live. The problem that you are seeing is that pages that were imported to projects previously have no information stored to change them in to this new style. — xaosfluxTalk 23:20, 14 December 2017 (UTC)[reply]
@Xaosflux: Given the lack of stored information on previous imports, I see the difficulty there and am satisfied as long as these identifiers apply to all future imports. But I want to ask for clarification on something: these identifiers will apply to ALL future imports, including imports of edits from SUL accounts, right? Because that was the previous issue: imports of edits of non-SUL accounts were already being marked with an "imported>" identifier before the username, but edits of SUL accounts were not marked/identified in any manner. —Lowellian (reply) 23:52, 14 December 2017 (UTC)[reply]
@Lowellian: unless the software changes again in the future, then yes that is the plan for all imports going forward as far as I know, I think it is a good thing. The problem with the other edits is they USED to say your name on them, but in the database they didn't reference your userid, some of these appear to be resolvable, but many were not - in the database cleanup they are now saying "import>NAME" instead of just "NAME", because there is no way for them to know if it should be en:NAME, or es:NAME, or fr:wikisource:NAME, etc. For edits that did match a SUL account from the point of view of the destination wiki they already did match your SUL ID and there is nothing to do. — xaosfluxTalk 03:56, 15 December 2017 (UTC)[reply]
@Xaosflux: Unless the person doing the import checks the "Assign edits to local users where the named user exists locally" checkbox. If they check that box, then SUL accounts will be attributed to the local name as was done by the maintenance script. As I told Lowellian in this edit, feature requests are better made in Phabricator than by continuing to demand changes here. Anomie⚔ 15:10, 16 December 2017 (UTC)[reply]
@Anomie: thanks for the clarification. I wasn't demanding anything, but will open a feature request to include an edit type identifier. — xaosfluxTalk 15:57, 16 December 2017 (UTC)[reply]
I can see how the welcome notification when you haven't visited the wiki is annoying. There is no moral or legal obligation to "fix" anything in regards to attribution of your edit. Lowellian: Please see Wikipedia:Copying within Wikipedia. — Preceding unsigned comment added by Killiondude (talk • contribs) 00:05, 15 December 2017 (UTC)[reply]
It's annoying, confusing, unnecessary and just plain bad design. As is using a lonely bullet point for emphasis. Bullet points belong in bulleted lists. Andrewa (talk) 00:21, 15 December 2017 (UTC)[reply]
Thank you for your input. Killiondude (talk) 00:50, 15 December 2017 (UTC)[reply]
The normal process of copying within Wikipedia attributes that copying, within edit history, to the editor who was actually doing the copying. These imports are copying while attributing the copying to someone who didn't do the copying, to a wiki that they didn't edit. To repeat part of what I wrote above, attribution has multiple components: who wrote something, what was written, when it was written, and where it was written. The problem is that imports without tagging misrepresent at these components: who wrote it (since it is really the import script copying over what someone else wrote rather than that person writing it directly) and where it was written. These attributions aren't accurate because they are edits made to a specific wiki that are now being attributed as edits to a different wiki. —Lowellian (reply) 01:03, 15 December 2017 (UTC)[reply]
Regardless, the way it's happening is a confusing and annoying mess. The "welcomes" in unintelligible tongues of men and angels (for all the good they do) are just a symptom.
The problem appears to be, these so-called attributions are undecipherable. If this were not the case, the scripts would not have such problems. And since attribution is required, this is serious. Andrewa (talk) 01:46, 15 December 2017 (UTC)[reply]
Auto-created local accounts though no imported contributions
Here's what I haven't yet understood about this:
So, on wikis where articles previously have been imported, local accounts are created in order to attribute the contributing users. But most or at least some of the newly created accounts that have been reported in this thread have no contributions! Are those accounts just a side effect with no big significance (other than causing annoying welcomes and uncertainty)? Or do they reflect that contributions by that user have been imported, but the details have somehow been lost and won't therefore appear in the contributions list? --Pipetricker (talk) 10:09, 15 December 2017 (UTC)[reply]
This comment is probably more relevant. BTW, for some reason your ping didn't work. Possibly because the edit edited another line in addition to adding a comment.Anomie⚔ 15:15, 16 December 2017 (UTC)[reply]
One of the possible problems that occurs to me is really a restatement of the initial problem raised here by Lowellian. Somehow, we've lost sight of the difference between information, which can't be copyrighted but must be sourced by references, and text, which can be copyrighted and so must be attributed.
Accurate translation preserves the information but not the text. So when going from one language wiki to another, the references should be kept, but the attributions should not be.
In English Wikipedia, other language Wikipedias are not acceptable references, so translation into English should not be a problem: The sources are kept, the attributions discarded. Other language Wikipedias may have different policies on this, in which case it may be acceptable to add a reference to English Wikipedia if translating from here. But regardless, the attributions belong only in English Wikipedia.
Am I missing something? Andrewa (talk) 05:55, 16 December 2017 (UTC)[reply]
Good point but not quite so simple. While translation of a literary work certainly preserves the creative element of the original, the translation of an encyclopedia article does not. The creative aspect of the text of an encyclopedia article is purely in the phrasing (we prohibit original research, for example), and is lost in the translation.
It's a bit of a can of worms with regard to lists, but in general, the translation of an encyclopedia article is not automatically a derivative work.
In fact the better the article is written and the better the translation is performed, the less of a problem this becomes. But it's a very good point, and probably where the paranoia for preserving attributions through translation arises.
Preserving attributions is in general a good thing, and often required, and always important when required. But not as simple as it might appear, as we have been finding out. And playing safe is not always the safest strategy! Andrewa (talk) 07:37, 16 December 2017 (UTC)[reply]
Not to impugn on any of your thoughts here, but Wikipedia is a top 10 website. Much time, effort, and legal help has been put into its licensing. Killiondude (talk) 08:15, 16 December 2017 (UTC)[reply]
Not to suggest that it's not! But perhaps it is not perfect, despite its popularity? Perhaps fixing this might help us to stay popular?
Nor to suggest that my legal opinion is superior to that of the legal department. IANAL. Lawyers are important (perhaps unfortunately, if Shakespeare is to be believed). But they should never be allowed to tell an organisation what it wants to do. Their role is to help an organisation to decide how best to do it.
This has all the earmarks of lawyers calling the shots. The main problem with the legal perspective is that they tend to want everything spelled out in terms only another lawyer would understand. And isn't that exactly what we are doing with these useless attributions? Ones that even our own coding cannot interpret correctly?
There must be a better way. And yes, the lawyers have a role in finding it. And so does the community. Andrewa (talk) 16:36, 16 December 2017 (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.
Is it possible....
...to create a bot, or "auto-generated reminder" as follows: an admin blocks an editor, and...
in their block summary for the user log, the admin adds a date command that on a specific date, triggers a bot reminder...
the reminder simply says "Review block log of (bot inserts respective user's name);
the bot posts the reminder to AN, and on the TP of the blocking admin and blocked user.
Please ping me when responding. Thank you! Atsme📞📧 11:53, 4 January 2018 (UTC)[reply]
Thank you, TQP - is this something that can be done locally without having to get the WMF involved? In other words, if community consensus approves a policy change/modification that will allow admins to add such a reminder to the block log, is it simple enough a project that it can be implemented (via java script, perhaps?) without having to jump through the WMF's hoops of fire to get a programmer to write the script? Atsme📞📧 13:41, 4 January 2018 (UTC)[reply]
This COULD be done with a bot since it could be done by an editor (that is read block logs, store data locally, read data locally, make edits). To be done with a bot it would not require any software changes - it would require someone to create and run such a bot. To actually be useful you'd have to convince admins to actually use these custom block log triggers and where the edits should go. — xaosfluxTalk 14:22, 4 January 2018 (UTC)[reply]
Download daily block log.
Search each entry for trigger (e.g. "remindme 17/12/2019") and store it in a little database. Check if the date is in the correct format (dd/mm/yyyy v.s. mm/dd/yyyy)
Check if there are remindme instructions for today in the database and send out the appropriate notifications if that is the case.
This isn't very difficult to program. Ideally the person who writes this software already has a bot or bots that run every day (I wouldn't run it on this computer because it is not always turned on). That person would need a botflag to post outside of their own userspace. The WMF does not have to be involved.
Note that HTML comments do not appear in the message displayed to the blocked user; ideally, you could use that to append metadata to your blocks. This is already routinely done for Sockpuppets. -- Luktalk 13:51, 5 January 2018 (UTC)[reply]
A "remind me to check on this later" is one of the features originally envisioned for mw:Flow. The most obvious use case is probably WP:U problems, to give good-faith users a chance to request a different username. Reviewing indef blocks would be another useful situation. Whatamidoing (WMF) (talk) 17:56, 12 January 2018 (UTC)[reply]
OAuth - Developing Locally
tl;dr: what do I put here to develop on my local machine?
I'm trying to create a web application that uses MediaWiki OAuth. I'm confused by the OAuth "callback" URL field on the propose page. From my understanding of the definition, it seems that this field is hardcoded/permanent (i.e. can't be changed once set in the registration form). Does this mean that I won't be able to develop on my local machine with the consumer I create for production? What should I put in this field if I want to develop locally? Thanks in advance. -FASTILY 09:50, 10 January 2018 (UTC)[reply]
Definitely sorry that's been a while before anyone can answer. And You're welcome in advance. The best advice I have to offer is answered in your own question, where it's stated that you're "create a web application that uses MediaWiki", so maybe try the Media Wiki url. Otherwise I don't have a clue.Maybe try your question here if you're still not sure. Sincerely, User: Zanygenius(talk page) 17:31, 14 January 2018 (UTC)[reply]
Turns out you can use Localhost (e.g. http://localhost:8080/) for that field. Here's an example consumer for anyone who's interested. -FASTILY 07:48, 17 January 2018 (UTC)[reply]
OAuth 1.0a (the version we use) requires the callback to be set, even if it's unused. As you've discovered, even URLs at localhost are ok. Alternatively, the worst case scenario could be: you could probably get an OAuth grant approved for testing, which could then be revoked when you're ready to go live. FACE WITH TEARS OF JOY[u+1F602]15:24, 18 January 2018 (UTC)[reply]
"Page size" Tool: "Word count" script 'User:Dr pda/prosesize.js' does not work with skin = Timeless
The useful "Page size" Tool (which shows an article's "Prose size" and its actual word count) does not display within the Timeless skin.
I've tested repeatedly but, when "Timeless" is the chosen skin (in User / Preferences / Appearance / Skin), the coding for this "prosesize" script doesn't seem to work when placed in either the "Shared CSS/JavaScript for all skins" (i.e. in common.js) or directly in the "Custom JavaScript" for that specific skin (i.e. in timeless.js) or when placed in both.
It may be my user error, but could this be a (known?) bug? I searched the Village pump archives but did not locate a mention of this. I have gotten around the problem by choosing to use the (default) Vector skin. Users of the Timeless skin might wish to be aware of this current lack of functionality.
Many thanks, -T2.Timbuk-2 (talk) 19:11, 10 January 2018 (UTC)[reply]
The script will only work with monobook and vector skins. Ruslik_Zero 19:53, 10 January 2018 (UTC)[reply]
@Timbuk-2 and Ruslik0: I wanted to let you know that similar information is now available in the XTools' Page History tool. Look for the "Prose" column in the "General statistics" section at the top. In case you were unaware, you can load any article in XTools from within Wikipedia by going to the "View history" tab, and clicking on "Revision history statistics".
Furthermore, there is a public API to programmatically retrieve prose statistics. What this means is the user script could be updated to use the XTools API, and it will work for any skin. Pinging Dr pda in case they are interested (though it seems they may have retired from the project).
Brilliant! MusikAnimal, the first option you mention meets my needs and works in all skins except MinervaNeue (or am I just not seeing the "Page history" tab in that skin?). I will spread the word about this. Many thanks. Timbuk-2 (talk) 02:40, 15 January 2018 (UTC)[reply]
No talk pages appear on Mobile
Whenever you click view talk page on an article or user page on mobile, it goes to the browser wikipedia and says this article cant exist because it has a bad title. YuriGagrin12 (talk) 20:48, 10 January 2018 (UTC)[reply]
It works for me. When logged in at https://en.m.wikipedia.org/wiki/Foobar I have a link at the bottom saying "Talk". It goes to https://en.m.wikipedia.org/wiki/Foobar#/talk where I see the talk page. Are you using some app or the normal mobile site in a browser? Does the link actually say "view talk page"? Does the mesasge actually say "this article cant exist because it has a bad title"? Please post an example url where you see the link, and the url it takes you to. PrimeHunter (talk) 21:36, 10 January 2018 (UTC)[reply]
This definitely happened to me about a week ago, but only for one afternoon. I cannot remember whether I was in Mobile view or Desktop view (my preference is the latter). Using Android with Samsung S5. I have a suspicion that an update that afternoon hadn't fully unpacked and installed at the time I started to browse, or an update led to problems that had to be rectified by another update the next day. Akld guy (talk) 23:26, 10 January 2018 (UTC) Added comment: browser was Chrome. Akld guy (talk) 00:14, 11 January 2018 (UTC)[reply]
I was using the app as I like the ability to save articles however when I click view talk page it says that(almost always)YuriGagrin12 (talk) 00:23, 11 January 2018 (UTC)[reply]
Hello, YuriGagrin12! The talk button on the mobile skin is currently only visible to logged-in users, or logged-out users who have opted-in to the beta setting. This differs from desktop which shows it unconditionally. The mobile apps shows the talk page link regardless if you are logged in to you wiki account or not. There's a little more discussion in this Phabricator task, constructive feedback there is welcome! CKoerner (WMF) (talk) 19:52, 12 January 2018 (UTC)[reply]
@CKoerner (WMF): Yes, im logged in. Its not a question of whether i can see the talk page button or not, its that when I click on view talk page it takes me to safari and I almost always get "BAD TITLE this article cannot exist because it has a bad title" Even when i've been on those talk pages. YuriGagrin12 (talk) 00:56, 16 January 2018 (UTC)[reply]
YuriGagrin12, does this happen just in the main namespace or other areas (like User:)? Links to pages where you're seeing the error would be handy. It sounds like it might be this task. I'll leave a note there of your issue. CKoerner (WMF) (talk) 21:06, 18 January 2018 (UTC)[reply]
@CKoerner (WMF): I have encountered it a few times in the mainspace, such as in the article Pyramid, but in the mainspace(at least for me) it seems like it occurs once on only a few articles. For other talk pages, its different, I can never access a user talk page or special page talk pages. But it has occurred in the mainspace, the only ones i can remember are the pages
Is there a wiki-gaget or script which can modify twinkle or atleast the Undo feature for the mobile interface. Also what is the official WMF status of officially adding the Undo and twinkle to the mobile interface — Force Radical ( Talk • Contribs ) 11:27, 11 January 2018 (UTC)[reply]
Heya Force Radical, there's nothing on the radar for the WMF teams I work with (largely mobile and web). I've passed along your request as I am aware that the teams are looking for ideas on what sort of contributions might work best on mobile devices. Your question might be a good one to add to Wikipedia_talk:Twinkle as there's a similar question there as well from Kailash29792. CKoerner (WMF) (talk) 19:37, 12 January 2018 (UTC)[reply]
Who maintains code/table for anti-vandalism bots?
What group is in charge of anti-vandalism bots? (I'm wondering why this edit wasn't picked up by same. It seems a no-brainer keyword for basing a tentative anti-valdalism revert on.) Ok, --IHTS (talk) 00:12, 12 January 2018 (UTC)[reply]
Each bot is managed by its own respective operator. — xaosfluxTalk 01:04, 12 January 2018 (UTC)[reply]
Thx. --IHTS (talk) 02:55, 12 January 2018 (UTC)[reply]
@Ihardlythinkso: perhaps you are thinking of filters, rather than bots. There are a number of links at Special:AbuseFilter where you can post an inquiry about the filters missing something that should have been blocked. — Maile (talk) 01:26, 12 January 2018 (UTC)[reply]
Thx for the clarification & lead. --IHTS (talk) 01:56, 12 January 2018 (UTC)[reply]
Actually I think this should have been cleaned up by a bot, not prevented by a filter. --IHTS (talk) 02:54, 12 January 2018 (UTC)[reply]
Unregistered account has a contribution
See Special:Contributions/Computer. Though this account is unregistered (appears to have been renamed), it shows a contribution when queried. How is this possible? For those wondering, I picked this up off of WP:LAME, where the account is mentioned (in a very old edit war). Home Lander (talk) 01:21, 12 January 2018 (UTC)[reply]
... and the contrib shows up for that account as well. This is a mystery for the ages, here. ;-) Hijiri 88 (聖やや) 07:26, 12 January 2018 (UTC)[reply]
This entry appears in the log: 23:53, 18 July 2007 Andrevan m . . (1,072 bytes) (0) . . (moved User:WOPR to User:Computer: Automatically moved page while renaming the user "WOPR" to "Computer")
and : 20:12, 8 July 2008 EVula m . . (5,878 bytes) (0) . . (moved User:Computer to User:タチコマ robot: Automatically moved page while renaming the user "Computer" to "タチコマ robot")
Salutations, Members of the Wikipedia Community It must be brought to attention that articles show up no matter whether they were deleted, or they weren't, nonetheless, they we're thrown in together. I don't nessicarily find this as a problem, however I find it to be like
speed bumps on the road of editing
— unknown
.
Nowadays, I often find my self scrolling the list, and today I tried clicking on Iceland Sea. I was considering taking it under my wings, only to find it deleted by User:Zzyzx11, so I was unsure whether it would be a good idea. I often felt steered away from pages because of this entropy.
--
Now, I understand the Administrative needs of showing the deleted pages', don't get me wrong here. I shall implement my solution below, and submit what would be like a summary, except it's my solution, potentially the answer, in my opinion, to the problem.
It would be found quite harsh and unnecessary to delete the deleted pages, so why not provide a button. One that could temporarily hide the deleted pages to Auto-confirmed users and reveal the same to the administration, buearucrats, and the stewards(which Special:Statistics counts as 0, huh?), who could really use it. Why not provide a button like you'd see on your watchlist, in which sorts the desirable content out of the thickness. A button like: [[Wikipedia:Sort|Hide Deleted Pages]] would really do the trick.
--
I would like to take the time to thank you for all you've done for Wikipedia. What you have, what you do, and what you'll contribute to in the future, so much contributions, I must thank you. I must also thank you in advance, for responding to me, and resolving perhaps one of the most arrogant problems of the Special Pages, at least affecting me.
The reason it was deleted can be useful to know. In this case it was deleted for reason G7, which means that the original author wanted it deleted. This means that it is fine to recreate it. You can even ask for a restore, though what was there was not that useful, and had no references. Also the page was actually deleted by Sphilbrick, so perhaps you are looking at another entry. There is already a mechanism to hide or eliminate the deletion entry, but it should only be used in certain cases. (perhaps the title was libelous or very offensive, etc). As an admin I see "(change visibility)" which will allow me to hide the entry. This message appears when attempting to hide a log entry: "Deleted log events will still appear in the logs, but parts of their content will be inaccessible to the public. Other administrators will still be able to access the hidden content and to undelete it, unless additional restrictions are set. " Graeme Bartlett (talk) 07:38, 12 January 2018 (UTC)[reply]
@Graeme Bartlett: I find that to be interesting perspective there, though I have stated that there is importance to the visibility of deleted pages in parapgraph 3. Now I don't find this completely un-useful, as I decided to post a message to the Creator about his article, as you suggested, and so hopefully he'll respond soon.
Well, I'll try to keep in mind all that you've said, as I progress forward. Have a wonderful day!
Anyone else think 200 characters is too much for the "Reason" parameter when moving a page?
[2] -- is there any way to access the actual <200 character reason I actually wrote, or is it lost to the aether? I'm pretty sure it was meant to say something like "over the manuscript tradition relates to the New Testament rather than the Hebrew Bible, because of the abundance of fairly early but relatively variant manuscripts we have of the former", but with it being cut short because the automatic part of the edit summary came to 162 characters and cut the end of my reason off. If I had planned ahead for this, I would have tried to fit my reason into 93 characters or less, but... Hijiri 88 (聖やや) 07:19, 12 January 2018 (UTC)[reply]
Like the edit summary, the actual limit is 255 bytes; but a significant proportion of that is soaked up by the default text "moved page Foo to Bar" which could potentially include such strings as "over a redirect", "without leaving a redirect" or both. --Redrose64 🌹 (talk) 16:28, 12 January 2018 (UTC)[reply]
Soon the limit will be raised to 1000 Unicode characters. But you'll still have to take that 162 characters into account if you're writing that much text in the move reason. Anomie⚔ 00:49, 13 January 2018 (UTC)[reply]
Templates that fetch data from wikidata
Hello. Do we have templates that fetch data from Wikidata? Xaris333 (talk) 10:19, 12 January 2018 (UTC)[reply]
This was pointed out on the template's talk page, but it seems to have gone unanswered, so I figured I'd bring it up here instead. In {{div col}}, the default is to use cols=2, despite that being deprecated. I most often see this template used in "See also" sections, and whenever I see cols used explicitly, I tend to change to to colwidth= something between 20em and 30em, but I'm probably not consistent with which. Is there a good solution so articles are consistent? Maybe just a basic wrapper for "See also"s that picks a reasonable default width? It almost never needs to be changed from some reasonable default anyway. –Deacon Vorbis (carbon • videos) 17:39, 12 January 2018 (UTC)[reply]
It might be worth looking at Template talk:Reflist/Archive 29 and some of the work done there by RexxS and others. A fixed number of columns (too narrow on smartphones, too wide on big screens) has been deprecated by this community for years. Whatamidoing (WMF) (talk) 18:40, 12 January 2018 (UTC)[reply]
I'm not quite sure what I'm supposed to be looking at exactly. I realize that setting a fixed number of columns is deprecated, but that's exactly what the template does by default (with 2) despite that. Would a {{See also cols}}/{{See also end}} wrapper be reasonable? This could just pick a reasonable default (say, 30em), and would be easy to update. This would help avoid inconsistent column widths, as is currently the situation. Even better would be to use something like this on most every page, and enable columns if there are more than some minimum number of entries, but I don't know if that's possible to check for with a pair like above. –Deacon Vorbis (carbon • videos) 19:16, 12 January 2018 (UTC)[reply]
I have added some discussion to Template talk:Div col, which has only 38 watchers. Feedback from technical folks is welcome. – Jonesey95 (talk) 21:22, 12 January 2018 (UTC)[reply]
Strange vandalism
Sorry if this is the wrong place to post this, but on several pages, Human and Barack Obama are specifically the ones I know of but I've been told there are more, there are transparent images covering the entire page that link to a YouTube stream. These links don't show up in the source code or the edit history of the pages. FrederickE♠♣♥♦ 04:35, 13 January 2018 (UTC)[reply]
Also it appears that the pageXinjiang conflict has the same issue linking here https://www.youtube.com/watch?v=oYntVKsbvFM has this page been hacked?? I know this is not the right place to report this but i do not have the ability to to sign up for a phabricator account right this moment Thanks Sassmouth (talk) 04:42, 13 January 2018 (UTC)[reply]
There was vandalism to Template:Excessive citations inline, I'm running a purge job against pages it was on and have increased its protection. The vandal has been blocked. — xaosfluxTalk 04:42, 13 January 2018 (UTC)[reply]
@FrederickE: and @Sassmouth: the purge job is done, please let us know if you still see issues. — xaosfluxTalk 04:54, 13 January 2018 (UTC)[reply]
Additionally, I've added this to the spam blacklist. SQLQuery me! 04:45, 13 January 2018 (UTC)[reply]
Template:Panorama
I made this template defaulting to center in focal area, to get proper width, I used width: min-content; to calculate box width. But there is a problem that Microsoft Edge does not support this property, so this template cannot get desied width on Edge if this template including very small image. I hope Microsoft fix it soon. Is there anyway to contact them? --Great Brightstar (talk) 14:22, 13 January 2018 (UTC)[reply]
This value is described in MDN Web Docs. According to MDN, this is defined in CSS basic box model 7 September 2016, and currently available in Chrome (without prefix), Firefox (with -moz), Opera and Safari (with -webkit). --Great Brightstar (talk) 10:25, 14 January 2018 (UTC)[reply]
That doc is an Editor's Draft, so will be highly fluid - don't rely on it. Indeed, the big yellow box states "This draft is undergoing changes and many parts are not consistent with other modules of CSS. Please, refer to CSS level 2 [CSS21] instead for the definition of the basic box model." --Redrose64 🌹 (talk) 21:38, 14 January 2018 (UTC)[reply]
Could the empty fields be hidden in templatedata tables?
When setting up template data, the preview on the template doc page ends up showing reams of this:
Default
empty
Example
empty
Auto value
empty
There often isn't any reason to fill these fields in, but they do make it quite hard to scan the tables for what's actually been specified. They also often mean the tables are too big to be a sensible replacement for existing parameter tables, which means the parameter list ends up being written out (at least) twice on template pages. Would it possible to just get rid of them when empty? User:GKFXtalk 19:59, 13 January 2018 (UTC)[reply]
Yep. Using CSS one can only hide the fields, but not the "label" using something like dd.mw-templatedata-doc-muted { display:none} until they add that class to the sibling dt tag (https://phabricator.wikimedia.org/T176956). It is possible to hide all of it entirely using javascript. 21:27, 13 January 2018 (UTC) — Preceding unsigned comment added by 197.218.83.2 (talk)
That CSS should really be put into the site-wide stylesheet. I've been adding quite a bit of templatedata recently and it's frustrating that the tables are just too unwieldy to become the primary source of parameter information on all but the simplest templates. If these tables were actually readable on doc pages, they could be used as a replacement for existing information more often. On the DRY (don't repeat yourself) principle, that would make both maintaining and reading doc pages easier. User:GKFXtalk 10:04, 14 January 2018 (UTC)[reply]
I've tweaked that code a bit to match the style of doc pages on the English Wikipedia, and Template:FormatTemplateData is now working very nicely. User:GKFXtalk 15:01, 20 January 2018 (UTC)[reply]
Method to flag names
User:Theopolisme/Scripts/adminhighlighter.js is a useful script to know who is an admin, it highlights the signature in a blue bar. I'd like to expand this with the ability to highlight other designated names with custom colors. For example, highlight User:Theopolisme with the color red so whenever I come across Theopolisme in the future, it reminds me this is someone I wanted to remember for whatever reason (I could keep a separate "key" or list with notes). Is there any tool like this available, or would it be easy to expand adminhighlighter.js? (Theopolisme has not logged in since September..) -- GreenC 21:23, 13 January 2018 (UTC)[reply]
It will ensure that it only matches the user name and not subpages or other random page that may also contain that string.
Creating that custom firefox css seems like overkill. Tampermonkey or greasemonkey or "stylish(?)" extensions would achieve the same thing.
It is simpler just add it to wiki User:XX/common.css as you're a registered user. 23:29, 13 January 2018 (UTC) — Preceding unsigned comment added by 197.218.83.2 (talk)
(Section heading changed to remove template call, see comment in the wikitext.)
Can someone help me with this? I'm trying to force said template to appear in the centre of a table cell. |style="text-align:center" doesn't work.--Nevé–selbert 22:08, 13 January 2018 (UTC)[reply]
@Neveselbert: It generates a <div>...</div>-type block element, which won't respond to inline styling placed outside itself. Where are you trying to do this? --Redrose64 🌹 (talk) 22:11, 13 January 2018 (UTC)[reply]
@Redrose64: I am editing a draft. Here are the contents of the cell I would like to have centred:
|center=yes does not appear to work in this situation.--Nevé–selbert 00:28, 14 January 2018 (UTC)[reply]
Try it without width="195px" --Redrose64 🌹 (talk) 09:53, 14 January 2018 (UTC)[reply]
@Redrose64: Is that the only way to fix the problem? It's just that the table I'm editing uses fixed widths, so I'd rather not. Do you know of any way to insert the treeview lines without having to transclude {{Tree list}}? I've looked and I have only seen {{hr}}, which only inserts a straight line.--Nevé–selbert 19:50, 14 January 2018 (UTC)[reply]
I've been testing out different values, parameters, and what not, @Neveselbert:, and I think you'll be satisfied with my findings, which can be seen below.
The problem seems to arise when there is only 1 row width setting in the main table. I do find that odd, but it's not the only reason. The 1st column is too small in order for the machine to "centerise" it. So, now I'm proposing a change in the row parameter, using
And it centers better using higher | width= paremeter. For extra long trees, try 500 or higher. Now, I think that should solve all your problems. Questions? Feel free to come back and ask them. We won't get annoyed.
If I doubleclick the "Publish changes" button I can get an editconflict with myself. Why don't we disable that button in Javascript for a second after it has been clicked? (((The Quixotic Potato))) (talk) 22:22, 13 January 2018 (UTC)[reply]
Pointless comment I know but this has been a thing for like 4-5 years however it's never been an issue well not for me anyway so don't see much pointing changing stuff. –Davey2010Talk 23:01, 13 January 2018 (UTC)[reply]
How does one generate a proper link to: [[c:Commons:Village_pump/Copyright#{{Dw_no_source_since}}_pettifogging]]?
The problem is that the section title has a template name in it and Mediawiki disrupts the link in other to look for the template, i.e. [[c:Commons:Village_pump/Copyright#Template:Dw no source since_pettifogging]]. Dragons flight (talk) 14:02, 14 January 2018 (UTC)[reply]
Thanks. Funny, I tried to do that before posting and it didn't seem to work. I guess I got the encoding wrong somehow. Thanks again. Dragons flight (talk) 14:23, 14 January 2018 (UTC)[reply]
What's the best syntactically correct way to do the list and column formatting in "Don't Stop the Music" (Rihanna song) § Track listing and formats without changing the layout too much (e.g. without making the line spacing too small, without splitting the numbered lists across columns)? Would a helper template be needed to do custom formatting? Currently it's syntactically ten separate lists inside {{col-start}}/{{col-2}}, which are probably deprecated by something somewhere. On some articles I've also seen things like *; (as well as * ;, which doesn't actually work) instead of the bold formatting in this article, which passed FA despite having these formatting issues. Jc86035 (talk) 16:28, 14 January 2018 (UTC)[reply]
@Jc86035: Good morning, I'm currently only at level-3, so I don't know super specialized layouts. However, I can tell you that when I went to look at the problem, an organized, understandable, list (shown in the box below) appeared, so I don't know if it should really be messed with. However, you may insert a wikitable.[1] Hopefully this helps some, and don't be to hard on yourself.[2]
@Zanygenius: It's not syntactically correct, however, since if it were correct it would be nested (*, *#), it wouldn't be ten separate lists in the rendered HTML (the newlines should be removed but I'm not sure of the best way to make it look nice) and it wouldn't be split in the middle with {{col-2}}, since this splits the list unnecessarily into two table cells (help page · Manual of Style).
You've only been here for less than a month, so I don't know if it's the best thing for you to go around giving other editors advice yet. It's also probably best to avoid extraneous bold and italic formatting (even in your comments), since it can distract from the words. Jc86035 (talk) 00:51, 15 January 2018 (UTC)[reply]
Main questions:
Is it possible to mark within a list that an element shouldn't be split between columns?
Is it stylistically correct(?) to use margin-left: 1.6em (default seems to be 3.2em) to reduce the indent of a numbered list?
Do these things require changes to MediaWiki:Common.css or the creation of a template/Lua module for these sorts of lists to make them correctly formatted? (In any case, indenting an <ol> inside a <li> would require a template for either the outer list or the inner lists to add styling or CSS classes.)
Are {{col-begin}} and other column templates using tables (instead of divs) deprecated? Should they be deprecated?
The markup in the collapsed box above creates bad lists partly because of the blank lines, but mainly because it switches from one style to the other without nesting. A format like this would be better (refs omitted):
Promotional remix singles
"Don't Stop the Music (Solitaire's More Drama Mix)" – 8:04
"Don't Stop the Music (The Wideboys Club Mix)" – 6:38
iTunes EP
"Don't Stop the Music" – 4:27
"Don't Stop the Music (The Wideboys Club Mix)" – 6:38
"Don't Stop the Music (Instrumental)" – 4:19
which gives a single unordered list, into which are nested some ordered lists. To Jc86035's first question (element shouldn't be split) though, this is within the scope of CSS Fragmentation Module Level 3 but be warned, this is only a W3C Candidate Recommendation so is not yet finalised. (CSS 2.1, which is a full W3C Recommendation, only has provision for break control in paged media such as hardcopy printout). --Redrose64 🌹 (talk) 11:03, 15 January 2018 (UTC)[reply]
Template:Free-content attribution evaluates to wrong HTML with icon floating in apparently disconnected locations
Resolved
– Fixed incorrect formatting in the template. Jc86035 (talk) 01:52, 15 January 2018 (UTC)[reply]
I tried moving Draft:Nancy_Wilson_(basketball_coach) into article space, but when I click the Move option, it didn't seem to allow "article" as a choice. (Possibly related, I can see the word "talk" highlighted and almost interfering.) I tried selecting some other options such as Category and Book (obviously, not carrying out the move, and those seemed to work. Am I missing something?--S Philbrick(Talk) 14:19, 15 January 2018 (UTC)[reply]
What browser and what version of your browser are you using? You can try clicking on the dropdown box to where it is highlighted (but the dropdown doesn't show) and then type ( to make it appear as a temporary workaround. Nihlus 14:21, 15 January 2018 (UTC)[reply]
Same here on Chrome 63, but typing ( and clicking enter allows selection. Galobtter (pingó mió) 14:29, 15 January 2018 (UTC)[reply]
A technical fix (phab:T182602) has been made, and should be resolved this week here. — xaosfluxTalk 15:03, 15 January 2018 (UTC)[reply]
Thanks for the feedback that it is a known problem, and scheduled to be fixed. Thanks also to Galobtter and Nihlus - I had to try a couple times, but that worked as a temporary workaround.--S Philbrick(Talk) 15:35, 15 January 2018 (UTC)[reply]
I've added help text to MediaWiki:Movepage-summary regarding this, any admin feel free to delete that message once this is resolved. — xaosfluxTalk 16:05, 15 January 2018 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Bureaucrats on Wikimedia wikis where the Translate extension is installed can now add and remove the translation administrator permission by default. Administrators of wikis where this extension is enabled can add and remove this permission to or from themselves. Wikis that used a different configuration before have not changed. [3]
There is a new Discourse test support channel for Wikimedia developers. You can ask questions or answer others questions about MediaWiki and Wikimedia software development. [4]
Problems
Last week's MediaWiki update was rolled back. This was because of a bug that changed non-ASCII characters when a page was edited. [5][6]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 January. It will be on non-Wikipedia wikis and some Wikipedias from 17 January. It will be on all wikis from 18 January (calendar).
Meetings
You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 16 January at 19:30 (UTC). See how to join.
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 17 January at 16:00 (UTC). See how to join.
Future changes
A few hundred wikis with less than ten high-priority errors in Linter categories will switch to use the Remex parsing library. This is to replace Tidy. It will happen on 31 January. Other wikis will be recommended to switch soon when they have fixed the errors that must be fixed. Tidy will be removed in the middle of 2018. [7][8]
There are a lot of things I do here that I find enjoyable, but logging in to find the pictured notification is not one of them. It's times like these that make me wish that the 2FA extension were available for all accounts. I see we have a tracking Phab task for this (T166622) but of course it's had no serious activity since August last year. The Phab project also seems low-activity to me. What's the status on this, and is there an estimate for when we can have it? Enterprisey (talk!) 22:03, 15 January 2018 (UTC)[reply]
At least you can log in. If 2FA were enabled, there would be a dozen complaints every month from people with a fouled-up system that did not allow them to log on. No one can guess a password in a thousand attempts providing the password is reasonable (WP:STRONGPASS) and providing the editor does not reuse their password on various sites. Does anyone know what the rate limit of guessing passwords is? It is likely that the IP of the person attempting to log on will be displayed in the alert to the targeted user fairly soon (phab:T174388) and that will at least be interesting. Johnuniq (talk) 22:19, 15 January 2018 (UTC)[reply]
@Enterprisey: if you REALLY REALLY want this, you can have it already (see your talk page). Please note, as far as I can tell - it will not stop those errors - they will still have invalid logon attempts. — xaosfluxTalk 22:34, 15 January 2018 (UTC)[reply]
If your password is secure and unique to Wikipedia, or you have 2FA enabled, you can safely disable the "Failed login attempts" notifications in your preferences. This particular notification is intended only as a wake up call that your account should be secure. If it is, you have nothing to worry about. — MusikAnimaltalk 02:10, 16 January 2018 (UTC)[reply]
I wouldn't say nothing to worry about but rather no immediate cause for concern. One should always be at least cognizant that someone is assaulting their account--if the hacker is determined & targeting you they could try other vectors beyond just brute-force. Can't hurt to be cautious :) FACE WITH TEARS OF JOY[u+1F602]15:55, 18 January 2018 (UTC)[reply]
Re my rate limit question above, mw:Requests for comment/Passwords (2014) says the default allows one guess per minute per IP, with possibly a captcha every few attempts. A person controlling a bot with access to 1000 IPs could perform 1000 attempts per minute to guess the password of a single account, or could attack several accounts concurrently. I don't see any recent information about the current requirements for a password or the enwiki rate limiting settings. Johnuniq (talk) 09:32, 16 January 2018 (UTC)[reply]
Wikimedia error
Resolved
Just for documentation, I got a Wikimedia error when I tried to post a few minutes ago, saying the site was under maintenance.— Vchimpanzee • talk • contributions • 22:26, 15 January 2018 (UTC)[reply]
Greetings, @Vchimpanzee: So your problem is on Wikipedia, or one of the other Wikis? Leaves a bit of confusion. Thank you in advance,
Thanks for reporting, but if it's just a one-off error that didn't repeat and you didn't copy the message, there's precious little that can be done to track it down. Please let us know if you see it again though. FACE WITH TEARS OF JOY[u+1F602]15:46, 18 January 2018 (UTC)[reply]
Weird text cursor / insertion point behaviour when editing source box, iPad Safari, iOS; Windows 10
I was trying to edit a Wikipedia article using Safari ios 11.2.2 on an iPad Pro 12.9" and I got into a state where no text cursor was visible. Then when I clicked in the textvat some point and made some changes the text edits were actually happening at a different point in the text, not at the point corresponding visually to the point where I had clicked. It was as if it had somehow got the offset into the text wrong, speculation :- perhaps by getting font widths wrong?
Has anyone ever seen anything like this?
I had to give up and close the browser and lose the edits. I tried editing the same page using a different browser, iCab, and it was all good.
CecilWard (talk) 19:16, 16 January 2018 (UTC)[reply]
@CecilWard: Happnes to my computer sometimes, and my tablet other times. This past month has been better. I recommend typing slowly. But I seriously can't wait for the day they correct that. Also, this seems to happen after 20 mintues of straight up typing, so do bits at a time.
Do you have the syntax highlighting beta enabled ? —TheDJ (talk • contribs) 11:09, 17 January 2018 (UTC)[reply]
I have the same problem, possibly worse and almost immediately on attempting an edit. Its random when it happens. Mine is a PC/Windows 10 problem as opposed to ios though. Does it on chrome, Edge, and IE. If I paste in text and then position the cursor, and then hold down the shift key to capitalise, the cursor jumps to the very start of the edit. I have to right arrow back to where the cursor was placed. Hope that makes sense. Very irritating. --BeckenhamBear (talk) 02:18, 19 January 2018 (UTC)[reply]
Update: I seem to have sorted out the edit box problems I was having by disabling the "syntax highlighting beta" I was using. --BeckenhamBear (talk) 17:25, 19 January 2018 (UTC)[reply]
Editor font size
At some point since my last edit 29 minutes ago, the font size in my wikitext editor window dramatically increased, roughly doubling. What happened? ―Mandruss☎ 21:27, 16 January 2018 (UTC)[reply]
I have the opposite problem, as shown in the [sub-]section below. Emir of Wikipedia (talk) 21:33, 16 January 2018 (UTC)[reply]
I have the same thing as User:Mandruss. I searched throughout the preferences on a way to change it back but have come up empty so far. Adamtt9 (talk) 21:45, 16 January 2018 (UTC)[reply]
It happened to me too, at the same time. It's happened before - anyone know how to fix it? Hawkeye7(discuss) 21:52, 16 January 2018 (UTC)[reply]
For some reason the font has been changed to a Monospaced font in the wikitext editor in both Firefox and Chrome. --Bamyers99 (talk) 21:54, 16 January 2018 (UTC)[reply]
The latter sources says "This will shrink the height of the characters, by a barely noticeable 2.5%, for editors using Chrome, IE, and Edge", I certainly noticed. It also says " Editors using Safari or Chrome on OS X/mac OS (about 12%) will notice a significant increase, which should improve accessibility", which would explain the case in this section. Emir of Wikipedia (talk) 22:08, 16 January 2018 (UTC)[reply]
(Firefox) I got back to my preferred size by changing 150% to 110% in my common.css.[11] I assume any editor can get any size they want by copying the last 3 lines there and setting the percentage as desired. I hope this is the last time I have to change it. ―Mandruss☎ 22:20, 16 January 2018 (UTC)
[reply]
Thanks for that Mandruss. I think that for Chrome, IE, and Edge 95% works better. Another suggestion I have is to make this at Meta in your global common.css, because as I documented below this change affects other projects but obviously if you don't use other projects then disregard this. Emir of Wikipedia (talk) 22:33, 16 January 2018 (UTC)[reply]
I wish the tech guys would stop "improving" the default text editor and NOT making it opt-in. As in, I would like to be able to use the original pre mid-2017 change UI. Now I'm stuck with various preference changes which barely negate it or having to change my CSS as demonstrated above. Safari& Chrome MacOS L3X1 Become a New Page Patroller! (distænt write) 01:37, 17 January 2018 (UTC)[reply]
You might want to change the line-height (stylesheet-only) and the font-family (possible in Preferences). Jc86035 (talk) 16:50, 19 January 2018 (UTC)[reply]
Text is smaller in source editor
I have suddenly come across a very strange problem. The text is my source editor has suddenly gone small. I use the Vector skin and I have many scripts as shown at User:Emir of Wikipedia/common.js. This is not a browser specific I have tested in on multiple browsers. It is also not a display or scaling issue as this is the only thing affected. Commons also seems to be affected by this issue. Looks like I am not the only one having this type of problem as shown in the above section. Emir of Wikipedia (talk) 21:33, 16 January 2018 (UTC)[reply]
This issue has been resolved due to the content in the above section. Emir of Wikipedia (talk) 22:34, 16 January 2018 (UTC)[reply]
Font size in source text editor
For me, the font size in the source text editor (what I am typing into now) has got noticeably smaller, and is now rather too small for comfort. Nothing has changed at my end, that I am aware of. Has it been changed at the Wikipedia end, and, if so, is this a change that has been generally asked for? For me, I would like it put back to how it was, please. 86.191.166.249 (talk) 03:12, 20 January 2018 (UTC)[reply]
Press either the command-plus or control-plus key combination on your keyboard (depending on what type of computer). -A lad insane(Channel 2) 03:32, 20 January 2018 (UTC)[reply]
Huh? I know how to use Windows Magnifier, if that's what you're suggesting. I also know how to change the browser zoom. That's not the point. Windows Magnfier is very inconvenient to use in this case, for numerous reasons. I already have the browser zoom set to my liking for general use, and I do not wish to increase it just for Wikipedia. My question remains. Has the font size been decreased at the Wikipedia end? If so, why? Have there been many requests for that to be done? 86.191.166.249 (talk) 11:42, 20 January 2018 (UTC)[reply]
OK, thanks, I didn't notice that it had already been reported. By the way, moving my comment made it very hard for me to find. Only by chance did I notice it. Perhaps you could have left the original section in place and added a link. The change of font size is said above to be "barely noticeable" in Edge. Actually, it is easily noticeable. On a general point, people who decide these things are usually young people with very good vision sitting in front of huge high-resolution monitors. Wait until they get to my age, and then see how they like the absolutely minuscule fonts. All Wikipedia text, and now especially the editor font, is too small for me in Edge at default zoom. 86.191.166.249 (talk) 01:20, 21 January 2018 (UTC)[reply]
How can I remove a display language from the Languages list on the left side of the page?
After recently making contributions to other langwikis, Wikipedia has started to list Deitsch (Pennsylvania German) in the list of languages, even though such an article doesn't exist. I believe this is intended to suggest that I make a new translation for the article. However, I don't speak Deitsch, and would not be able to make useful contributions to that language's wiki. How can I remove Deitsch from my list of languages? {{u|Rey_grschel}} {Talk} 00:20, 17 January 2018 (UTC)[reply]
On which page are you seeing this link? --Redrose64 🌹 (talk) 00:28, 17 January 2018 (UTC)[reply]
You can't remove it. Those aren't a list of languages. They're links to a same-named article at a Wikipedia of another language. — Maile (talk) 01:46, 17 January 2018 (UTC)[reply]
That's exactly what I'm seeing. I'd disable "Content Translation" but it's a useful feature when translating articles. I guess I'll just have to live with it. {{u|Rey_grschel}} {Talk} 02:16, 17 January 2018 (UTC)[reply]
I don't mean to sound rude, but I know that this list normally contains links to articles on other langwikis, however, this language is at the top of the list and is greyed out (perhaps something I should have mentioned, even though I said the article already existed). PrimeHunter has exactly what I'm looking for. {{u|Rey_grschel}} {Talk} 02:16, 17 January 2018 (UTC)[reply]
I'll make sure to do that in the future, sorry about that. {{u|Rey_grschel}} {Talk} 04:03, 17 January 2018 (UTC)[reply]
On various pages throughout the enwiki, particularly on Teisterbant and several of its related articles. {{u|Rey_grschel}} {Talk} 02:16, 17 January 2018 (UTC)[reply]
I tried enabling content translation at beta features, and went to Teisterbant but I don't see any mention of Deitsch. --Redrose64 🌹 (talk) 17:23, 17 January 2018 (UTC)[reply]
Deitsch is an example for Rey_grschel. I see svenska, Ελληνικά, dansk (Swedish, Greek, Danish) without knowing any Greek. mw:Help talk:Extension:ContentTranslation#Removing the gray interwiki links says: "the list is determined based on certain criteria like your browser preferences, past languages you have translated into, geographical location (if shared) etc". I'm in Denmark with Danish in my browser. Swedish is very similar to Danish. Don't know where Greek came from. I did make one edit to the Greek Wikipedia in 2011. PrimeHunter (talk) 18:25, 17 January 2018 (UTC)[reply]
Template syntax + wikidata question
Someone added some category to wikidata, and then set up a popular infobox to automatically display that information when it is available. The problem is, it's not especially important information (in my opinion). I want the template to by default NOT display this information (even if it's available on wikidata), with a way to override that and display the wikidata information in any particular article.
The status quo (which displays the information no matter what) looks like:
How would I edit it so that it is possible to display this wikidata information, but it is not displayed by default? Is that even possible? --Steve (talk) 00:46, 18 January 2018 (UTC)[reply]
I don't know whether there is any practice for how to handle this but you could for example say that dimension = wikidata means pull from wikidata. Any other value is displayed, with empty or undefined meaning nothing will be displayed. Untested code:
Then in an article where you want to display dimension, add |suppressfields=none to the infobox. It may be worth studying the WikidataIB documentation to see other ways how you could use it for these sort of cases.
One caveat: it displays plain text, not Math markup because it was expressly designed for use in infoboxes, not normal article text. You would have to add the Math markup around the #invoke if you really wanted that. --RexxS (talk) 18:14, 18 January 2018 (UTC)[reply]
"A link was made from x"
Is there any way to disable these notifications on a page-by-page basis? I understand it can be disabled entirely, but I was just wondering if I could only disable it for a few popular pages that get used in references, etc. Anarchyte (work | talk) 09:51, 18 January 2018 (UTC)[reply]
Not as far as I know. There are a number of preferences which it would be useful to have set on a page-by-page basis, such as categorisation - I want to know when articles are added to certain maintenance categories but I generally don't care when articles are added to most content categories. If I turn off "Hide categorization of pages" at Preferences → Watchlist, I get a watchlist flood, and with the new 1,000-entry maximum, I could easily miss out on edits more than a day or so earlier. --Redrose64 🌹 (talk) 12:21, 18 January 2018 (UTC)[reply]
Media Viewer still showing incorrect dates on photographs
When the source description page gives only a month or year, e.g. only "July 2010", or only "2010", the Media Viewer is STILL incorrectly showing the date as the first of the month. This was raised months or even years ago, and seems to have incorrectly been given a "never bother to fix" priority. Showing a spurious "1st" date is just WRONG. It needs to be FIXED. 86.191.166.249 (talk) 02:39, 19 January 2018 (UTC)[reply]
This appears to be phab:T58794. You can follow the development at that link. — xaosfluxTalk 03:47, 19 January 2018 (UTC)[reply]
I've since proposed a direction for solving this, but as MMV is not currently an actively developed product, there are no developers assigned to it and thus unlikely to be fixed any time soon. This is not unusual, almost every part of the software has a couple of hundred outstanding problems with the same severity. Patches are always welcome... —TheDJ (talk • contribs) 09:42, 19 January 2018 (UTC)[reply]
It probably didn't take much time for developers to realize this limitation. So it isn't due to resources, it is simply due to lack of interest. Anyway, the so-called "community" doesn't care much either way, it would take less than 30 seconds to create a CSS to override it:
span.mw-mmv-datetime {
visibility : hidden;
}
span.mw-mmv-datetime::before {
visibility : visible;
content: "Click 'more details' to see date";
}
Or alternatively read the "one true date" from the file metadata API and overwrite whatever the software adds. In any case, in a few updates of the library it will eventually turn into an exception, so both sides may get what they want:
Deprecation warning: value provided is not in a recognized RFC2822 or ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions. Non RFC2822/ISO date formats are discouraged and will be removed in an upcoming major release. Please refer to http://momentjs.com/guides/#/warnings/js-date/ for more info.
Arguments:
[0] _isAMomentObject: true, _isUTC: false, _useUTC: false, _l: undefined, _i: 1926, _f: undefined, _strict: undefined, _locale: [object Object]
This bug is worse than many others that are just presentational or cosmetic, or cause inconvenience, since it results in the display of INCORRECT INFORMATION. Some photos only have a month or year attached. A way to display these dates correctly in Media Viewer is ESSENTIAL. Making up a false date with spurious accuracy is BLATANTLY INCORRECT. Fixing this needs to be given HIGH PRIORITY. 86.191.166.249 (talk) 03:08, 20 January 2018 (UTC)[reply]
Comment on the phabricator ticket please, there is nothing that we can do about it here. But when you do so, don't shout - they are less likely to give priority if you do. --Redrose64 🌹 (talk) 12:46, 20 January 2018 (UTC)[reply]
Thanks. I have no account there. Could someone possibly copy my comments across? As far as shouting is concerned, normal volume has had no effect for more than four years. Somehow, someone needs to get through to the people who prioritise tasks that fixing this is important. What else do you suggest? 86.191.166.249 (talk) 00:59, 21 January 2018 (UTC)[reply]
Hi, @86.191.166.249:, I just wanted to let you know that I have taken and copied your first comment to phabricator (use task button in top right to reach my post), and I explained it out. Hopefully this makes the process faster.
And, if you need anything, just ask. Now I have a phab talk page.
In consistent with my signature style and color, I want to make my user-page's title that way. I've prepared the displaytitle which is {{DISPLAYTITLE:User:<b style="color:dimgray">Ascetic<span style="color:orangered">Rose</span></b>}}. But the problem is it is bold. I want to remove this bold feature but don't know how to.
Another problem is that is there any way to use é (as in my signature) in the title? When I put é, the warning message says it is not consistent with the original title. Can anyone help? -AsceticRosé 09:21, 19 January 2018 (UTC)[reply]
That's not what that functionality is for... Page titles look the same for every page for a reason, dressing it up like a Christmas tree is not what displaytitle is supposed to be used for, as documented in Template:DISPLAYTITLE#Description. —TheDJ (talk • contribs) 09:36, 19 January 2018 (UTC)[reply]
It's for a user page. Users are allowed to style their username there. <b>...</b> means bold. Use <span>...</span> instead: {{DISPLAYTITLE:User:<span style="color:dimgray">Ascetic<span style="color:orangered">Rose</span></span>}}. You cannot change e to é. The display name must resolve to the real name in wikilinks so it must use the same characters with a few exceptions like space/underscore and lowercase initial letter. PrimeHunter (talk) 11:48, 19 January 2018 (UTC)[reply]
I'd say it's allowed because some people insist on doing it.. But its annoying as hell. —TheDJ (talk • contribs) 12:31, 19 January 2018 (UTC)[reply]
I find the bold red in the signature annoying but don't mind the title on the userpage. PrimeHunter (talk) 21:45, 20 January 2018 (UTC)[reply]
Pathways
In Triglyceride the interactive pathway image, at least for me does not show well, only about half being visible. All the best: RichFarmbrough, 11:12, 19 January 2018 (UTC).[reply]
It says {{StatinPathway WP430|highlight=Triglyceride}} and is supposed to be cropped according to the documentation of highlight: "Where you want to crop the pathway view to center on a particular [something]". I see Triglyceride in bold near the center of the displayed part so I think it's working as intended. PrimeHunter (talk) 11:39, 19 January 2018 (UTC)[reply]
Flagging overwriting of articles
At present, edits that replace most of the content of a page with new content of less than about 1,000 bytes are flagged in two ways: a tag that reads "Replaced" and is named mw-replace, and an automatic edit summary drawn from MediaWiki:Autosumm-replace reading "Replaced content with '.....'". The automatic edit summary only appears when the editor did not enter an edit summary themselves.
A proposal that edits should also be flagged when the new content is more than 1,000 bytes has received support at VP Misc. Would anyone with Phabricator access care to submit the proposal there?: Noyster (talk), 18:59, 19 January 2018 (UTC)[reply]
This proposal seems misguided:
1) It is not 1000 bytes , it relies on size of new revision (90% less than the older rev)
2) The opposite is not as noteworthy. It is normal for a short page to be increased by 90%
3) It will result in massive amounts of false positives (e.g. undo by simply loading old revision and saving)
4) It will just be waste of database space tagging many (potentially millions) of needless changes
It would be way more sensible to use the same query as the one used in special:newpages for size differences. Newpages and recentchanges both fetch from the same table, so it may potentially be performant enough to reuse. Or at worse have one new filter that checks for irregular additions, e.g. edits larger than 100% or 200% or whatever. 23:52, 19 January 2018 (UTC) — Preceding unsigned comment added by 197.218.88.180 (talk)
How is this to be detected? Does it rely on the removal of all existing page content? For example, sometimes I'll add a new line at the start of the list, and instead of inserting a new line at the top of a list, the diff viewer says that I blanked the top line, changed every other line, and added a new line of text below the old bottom line. I'm concerned that adding or subtracting lines could be misinterpreted as replacing all page content with new content. Nyttend (talk) 00:19, 20 January 2018 (UTC)[reply]
As noted, it is not in any way intelligent or anything. It just does pure math using the difference between old and new revisions, something similar to (Newrevsize / oldrevsize < 0.1 ). In any event, this doesn't even need a software change, if users here believe such a strange thing is sensible then tagging can be done using abusefilter. 197.218.91.123 (talk) 00:52, 20 January 2018 (UTC)[reply]
Thank you, we're not concerned here with size difference, but with removal of all or nearly all article content and replacement with something else. To the supporters of the proposal it appears sensible, and not strange, to want to flag such edits for review, as they amount in all but name to creation of a new page. Now as people here have pointed out, flagging would need to exclude such actions as insertion of a small amount of content or restoring a previous version. The questions for this technical board are, whether this is technically feasible and whether someone will help get it implemented?: Noyster (talk), 18:26, 20 January 2018 (UTC)[reply]
That would require doing something like a difference check on every single edit. That of course may cause performance issues. It would also have numerous false positives due to the fact that one can increase content by reducing (or vice versa) using a transclusion. Expanding all wikitext and then running the diff check adds even more time to it. In other words, probably unlikely to be technically feasible. It might be more reasonable to have that in an extension like abusefilter (and there is already a task for that anyway (https://phabricator.wikimedia.org/T36912)). If such a feature were integrated into it, and deemed performant enough then it could tag all relevant edits, as suggested here. 19:52, 20 January 2018 (UTC) — Preceding unsigned comment added by 197.218.91.184 (talk)
It certainly looks as if T36912 would provide the means to detect these edits. That task has been sitting since 2012 with low priority and no-one assigned. Could it be boosted up the priority scale, or do we have to wait to put it on our Santa Claus wishlist coming up to next Christmas?: Noyster (talk), 10:04, 22 January 2018 (UTC)[reply]
Search for word in an AfD close?
Sometime in the past few weeks, I remember closing an AfD (or possibly it was a DRV?) and using the word "obit" in my close. Scanning my contributions history, I can't find it. Is there some way to do a search for something like "namespace:Wikipedia user:roysmith content:obit" — Preceding unsigned comment added by RoySmith (talk • contribs) 19:11, 19 January 2018 (UTC)[reply]
@RoySmith: Something like this should do you. You can mux with the search phrasing if you don't find it at AFD. --Izno (talk) 19:32, 19 January 2018 (UTC)[reply]
That makes two of us, @RoySmith:, in the fact that you remember putting something that wasn't there. According to this edit diff, I'd say there's nothing embarrassing to worry about! Have a great day, and enjoy your weekend. Here's a weekend quote for you:
Dear Rest/Napping/Weekend, I'm sorry I was a jerk to you as a kid. I can't live life without you now.
While I'm sure there are other ways, I go to my contributions and see which recent ones are not the latest edit. If there is a tag such as on a redirect (I create a lot of those), I think something has been done and go there and find out mine was the last edit. This wouldn't happen if "current" was on the right.— Vchimpanzee • talk • contributions • 23:06, 19 January 2018 (UTC)[reply]
It'd be kinda nice if we swapped (current) for like C and put it next to the N for new page indication. The whole line could use condensing.... FACE WITH TEARS OF JOY[u+1F602]05:53, 20 January 2018 (UTC)[reply]
It was worth a shot. Obviously this is of such low importance we can't change the software.— Vchimpanzee • talk • contributions • 17:15, 20 January 2018 (UTC)[reply]
It's not that it can't be done; it's that it can't be done on wiki. We'd need a dev, and the way to get a dev is to bribe User:😂 or Moriel with Stroopwafels file a Phab task that explains the goal and hope that someone will decide that it's a very simple change.
Step one: Does anyone think this would be a bad idea? If not, then we can file the task – it's just a matter of filling out this simple form – and maybe it'll happen. Whatamidoing (WMF) (talk) 20:11, 22 January 2018 (UTC)[reply]
Making such an arbitrary change will not help with a single thing (as far as usability goes). It will just be superficial. In any event, making it look as requested here is certainly possible without server-side software changes. Instead of changing the html this can be changed using CSS, the simplest approach is probably float: "right". 09:53, 23 January 2018 (UTC) — Preceding unsigned comment added by 197.218.83.173 (talk)
.mw-uctop {float:right;} in your CSS will float "(current)" at the right margin. Some users may prefer it but I don't recommend it for site-wide css. Depending on window size, font and zoom I get results like a line ending with "(Tag: (current)", and then "New redirect)" at the start of the next line. PrimeHunter (talk) 11:20, 23 January 2018 (UTC)[reply]
As noted above, that was a simpler approach. It goes without saying that the changelist formatting is quite badly structured. It would simpler to make such changes if that wasn't the case. Anyway, here's an approach that is a bit more complex, but works in a similar manner:
I have a script (User:R'n'B/dplupdate.js) that loaded the module mediawiki.action.history.diff. Apparently, this module no longer exists, since the script will not run unless I comment out the reference to it. Is there a replacement for it? --R'n'B (call me Russ) 13:53, 20 January 2018 (UTC)[reply]
I think they changed mediawiki.action.history.diff to mediawiki.diff.styles. -- GreenC 20:27, 20 January 2018 (UTC)[reply]
{{Convert}} template and range measurements: "adj=on" doesn't work?
Is the {{convert}} template's "adj=on" parameter intended to be used with a range measurement?
Currently, if you try it, the "adj" formatting is turned on for the initial range but not for the converted range (see example below). The documentation for that template describes the "adj" parameter in Section 3, but makes no mention there of its potential functionality with ranges. "Ranges" are covered in Section 7, but, again, there's no explicit mention there of the "adj" functionality with ranges. Here is an example I came across.
PROBLEM EXAMPLE
The coding:
The electronic license plate has a {{convert|12|by|16|inch|cm|adj=on}} digital display.
Displays as:
The electronic license plate has a 12-by-16-inch (30 by 41 cm) digital display.
Notice how the hyphens are correctly placed in the first range, but hyphens have not been added in the converted range.
One workaround is to omit the "adj=on" parameter after rewording the sentence to make the range measurement into a noun.
WORKAROUND EXAMPLE
The coding:
The electronic license plate has a digital display measuring {{convert|12|by|16|inch|cm}}.
Displays as:
The electronic license plate has a digital display measuring 12 x 16 inches (30 by 41 cm).
Perhaps the "adj=on" parameter is not expected to work with a range measurement, but perhaps the documentation should be amended to specify that (lack of) functionality?
Thanks to those who may be able to shed light on this.
Timbuk-2 (talk) 22:09, 20 January 2018 (UTC)[reply]
In the future, please discuss {{convert}} issues at Template talk:Convert. My reading of MOS:HYPHEN is that convert is working correctly. The following shows that hyphens are inserted when units are not abbreviated:
{{convert|12|by|16|inch|cm|adj=on}} → 12-by-16-inch (30 by 41 cm)
@Home Lander:, personally, this sounds like template vandalism, so I'd check the hidden templates, but I'll mention this to some admins and see what they say.
<includeonly>[[File:White x in red rounded square.svg|16px|link=|alt=Delete]]'''Closed discussion''', see [[Wikipedia:Redirects for discussion/Log/2018 January 19#1516392921|full discussion]]. Result was: </includeonly>
which means that it's only visible when transcluded. --Redrose64 🌹 (talk) 23:41, 20 January 2018 (UTC)[reply]
This is unrelated to the template vandalism link by Zanygenius. I think popups looks for an image name in the source without caring whether it's displayed on the page itself, when the page is transcluded, or not at all. Except it ignores images in comment tags <!-- ... -->. And I think popups can both detect file links in the source and images in some common template parameters like |image = example.jpg, but not image names in running text like "A common example file name is example.jpg". You would have to examine MediaWiki:Gadget-popups.js or make more tests to figure out the details (or find somebody who already knows them or has written them somewhere). PrimeHunter (talk) 00:02, 21 January 2018 (UTC)[reply]
Hi Home Lander. Navigation popups uses a very naive JS based wikitext parser from 2004 to achieve it's results. Problems like these are expected as many new features were added to MediaWiki since that time. There are currently no plans to replace the parser. —TheDJ (talk • contribs) 17:34, 21 January 2018 (UTC)[reply]
@TheDJ: Interesting, I wouldn't have expected that because its operation is so fluid; it never seems to produce errors. Guess it shows that while some things change, others never seem to. Home Lander (talk) 21:21, 21 January 2018 (UTC)[reply]
@PrimeHunter: Per your idea, I inserted File:Example.jpg into the Sandbox with an <includeonly> tag in front of it, and sure enough, the image did not display on the page, but hovering over any link to the Sandbox generated the image in popups. So it apparently happens any time the <includeonly> tag is used with an image. It also doesn't appear to care whether an image is on the MediaWiki:Bad image list; I put this image in instead and popups had no issue displaying it either. Something to be aware of, particularly when linking to problematic images on noticeboards. Home Lander (talk) 21:37, 21 January 2018 (UTC)[reply]
Popups looks for file syntax in the wikisource. <includeonly> is one of many ways to have file syntax without displaying an image. Another way is an ignored template parameter. User:PrimeHunter/sandbox6 contains {{void|[[File:Example.jpg]]}} which produces nothing. Popups displays the image. PrimeHunter (talk) 22:51, 21 January 2018 (UTC)[reply]
Erroneous "no pages in this category" message - can we fix it locally?
When you click on a link in a category table of contents (TOC) near the end of the alphabet, and there are no pages in the category that start with that letter or a letter that is later in the alphabet, you get a misleading message: "There are no pages or files in this category." See, for example, this link, which currently shows the erroneous message. If you click earlier in the alphabet in the TOC for the same category, you get a message like "The following 102 pages are in this category, out of approximately 702 total. This list may not reflect recent changes."
On the "no pages" page, there are also no "previous page / next page" links, even though there should be at least a "previous page" link.
Are these things that we can fix locally, or will I need to submit a Phabricator request? I searched phab for related search terms and did not come up with anything. – Jonesey95 (talk) 01:57, 21 January 2018 (UTC)[reply]
It's MediaWiki:Category-empty, so yes we could easily resolve the issue you're talking about. The problem is that the same message appears in categories that really are empty — we can't change one locally without similarly modifying the other. Therefore, resolving the underlying issue will require a Phabricator request. Nyttend (talk) 05:48, 21 January 2018 (UTC)[reply]
I think we could do some trick using {{PAGESINCATEGORY:{{PAGENAME}}}} to see if the category is empty - the code would look like:
{{#ifeq:{{PAGESINCATEGORY:{{PAGENAME}}}}|0|Content for empty category|Content for non-empty category}}
MediaWiki messages don't have access to url parameters so we cannot make a "(previous page)" or "(next page)" link. We also don't know whether the problem is that we are after the last page. Clicking "0-9" in the category TOC at Category:CS1 errors: invisible characters and then "(previous page)" gives [14] which displays MediaWiki:Category-empty because we are before the first page. Can we do much else than replace "There are no pages or files in this category" with something like "There are no pages or files in this category satisfying the parameters" in the case "Content for non-empty category"? We could add a link to the whole category. This link is already on the "Category" tab but users may not realize that. The link might need an anchor or url to avoid the bold selflink feature. I don't know how reliable PAGESINCATEGORY = 0 is. Wikipedia:Village pump (technical)/Archive 46#Incorrect counts from PAGESINCATEGORY function from 2008 mentions false 0 results. A false non-0 on an ordinary category view without parameters would cause a misleading message if we say "satisfying the parameters". PrimeHunter (talk) 13:39, 21 January 2018 (UTC)[reply]
Added "or within your selection" to the description for now. There already was a ticket for this problem. —TheDJ (talk • contribs) 17:13, 21 January 2018 (UTC)[reply]
Math rendering behavior change
Since Wikipedia seems not to support \operatorname* in <math>...</math> mode (the starred version is to make a following subscript display under the operator name, as with \lim, as opposed to a usual subscript), I discovered a workaround at some point in the past, which was to use \operatorname{foo}\limits instead (which I added to the fourth paragraph at Help:Displaying a formula#Rendering). However, this appears not to work anymore. I'm not sure exactly when this changed, but I don't think it was too long ago. Can anyone offer any insight to what's going on or how to proceed? Thanks, –Deacon Vorbis (carbon • videos) 14:33, 21 January 2018 (UTC)[reply]
This sounds like something that belongs in the regular Village pump, or Incident board, and I recommend taking it there.
However, @JSH-alive: I would probably revert the edits manually then notify the user. I'll check to see if the edits match our manual of style for you.
A history merge is needed, see this section. I'll act on it once I checked whether the rename is warranted. Please don't revert blindly, that makes messes put of the history. Jo-Jo Eumerus (talk, contributions) 15:58, 21 January 2018 (UTC)[reply]
OK, now done. If it should be renamed to something else, use a move request or just move. Jo-Jo Eumerus (talk, contributions) 16:03, 21 January 2018 (UTC)[reply]
@Jo-Jo Eumerus: Thanks for fixing the move for us :).
Hello, folks. Perhaps this is not the right place to ask this question, so feel free to point me to somewhere else.
Earlier today, one of my edits had been reverted, but I found out about it only from my Watchlist and not from the usual "red number at the top of the screen" notification system. When looking into it, I saw that the edit summary for the revert used the same "Undid revision ###### by ..." language that is used for reverts done with the "Undo" function, but the edit wasn't tagged as an "Undo". Instead, it was tagged as a "Visual edit".
I've checked the User Guide for the VisualEditor, but found nothing relevant. And so, I've come here to ask -- does the VisualEditor bypass the notification system? And if so, does anyone here know whether this is a deliberate feature?
Thank you for any assistance you can provide. NewYorkActuary (talk) 16:28, 21 January 2018 (UTC)[reply]
@NewYorkActuary: The visual editor doesn't do undo's. Maybe someone initiated an undo and then switched to visualeditor and finished it there ? Not sure. How about asking the person who made the edit ? —TheDJ (talk • contribs) 16:57, 21 January 2018 (UTC)[reply]
@TheDJ: Thanks for the prompt response. And yes, that's probably exactly what happened, because the edit wasn't a pure revert -- it also added a source. But that raises a different question. Although I don't use VisualEditor, I sometimes do use the "Undo" button to initiate a revert, but then restore some portion of the material that would otherwise have been removed. So, now I'm wondering whether I too have been inadvertently by-passing the notification system. No need to look into that -- I'll just check the edit history to see how the edit gets tagged the next time I do it. Thanks again for the prompt response. NewYorkActuary (talk) 17:23, 21 January 2018 (UTC)[reply]
Tags don't show whether a notification was sent. If you use the undo link and stay in the source editor then a revert notification is always sent, tested in [15] where the default undo summary was changed and no revert was actually made. PrimeHunter (talk) 18:28, 21 January 2018 (UTC)[reply]
@PrimeHunter: Thanks for that. The edit in the link you provided does show a "Tag: Undo", so that seems to address my second question -- if that "Tag: Undo" notation appears in the edit history, then a notification has been sent. And it also seems that the opposite is true -- if you click "Undo" and then switch to VisualEditor, you have indeed by-passed the notification system. Please correct me if I'm wrong about either of those two conclusions. Thanks again. NewYorkActuary (talk) 18:53, 21 January 2018 (UTC)[reply]
NewYorkActuary, I'm interested in this. Feel free to undo a of my few edits in my sandbox and then leave a note on my talk page about what you did. Let's see if we can figure out how to reproduce this reliably. Whatamidoing (WMF) (talk) 20:19, 22 January 2018 (UTC)[reply]
@Whatamidoing (WMF): Thanks for following up on this. I've made two edits to that page. The first was a simple "undo". The second was an "undo" combined with some editing, both done within the basic (standard?) edit window and both done before clicking "Save". Becuase I don't have the VisualEditor installed, I was unable to demonstrate what would happen if I clicked "Undo", but then switched to VisualEditor before saving. NewYorkActuary (talk) 20:48, 22 January 2018 (UTC)[reply]
P.S. I just went back to your page to check that both of my edits did have "Tag: Undo" attached to them. But I also saw that you have VisualEditor installed. So how about undoing the most recent edit on one of my pages (this one), but switching to VisualEditor mid-process? We'll see if I get a notification of that edit. NewYorkActuary (talk) 21:03, 22 January 2018 (UTC)[reply]
You have two accounts so you should be able to make tests by using one account to revert the other. That's what I did in [16] and [17]. The second edit switched to VisualEditor before saving so the edit was not tagged with undo and the reverted account was not notified. PrimeHunter (talk) 21:15, 22 January 2018 (UTC)[reply]
@PrimeHunter: You might want to re-try that second test. You seem to have edited the alternate account's test page using that same alternate account. NewYorkActuary (talk) 21:58, 22 January 2018 (UTC)[reply]
That was intended. I had edited it with my main account earlier and swapped accounts for the second test. I used PrimeHunter2 to revert PrimeHunter in VisualEditor so I could see if PrimeHunter would be notified. He wasn't. PrimeHunter (talk) 22:07, 22 January 2018 (UTC)[reply]
"WikiProject Bridges" has changed its name to "WikiProject Bridges and Tunnels." Now we need help changing the template to work with the new name. Please have an experienced template editor make the change.
I don't know what's going on with the revert,@Redrose64:, though it was me who annexed the forementioned comment, as I tried to do it myself, a d found it was protected.
The left photo displays a Redlink to a page I have created (this has happened a few times before), which can be seen on the right.
@Admin:(s), I find (2 times) that I'll create something, say on my userspace, {if--the link was there to start with, then I create it} and find it's redlinked for 5-10 minutes. I find that a little weird. I mean, I can live with it, but it is something of interest that this can even happen. (Yes I've tried purging the page). Any thoughts?
Sincerely, User: Zanygenius(talk page) 05:07, 22 January 2018 (UTC)[reply]
I almost figured that would be the case, and yet I didn't know. Well, it's a grateful thing that you let me know. So, I'll keep that in mind, though yeah, I wasn't to bothered anyways. Thanks again!
Asking for the Central Kurdish Wikipedia: on the English Wikipedia, when you protect a page with one of the options, there is a different-in-color lock icon (appearing in the right side of the pages) for each of those options. I was wondering what module/template causes these locks to appear? Because on the CKB wiki, it is not working properly. Is there anything we can do about it locally or should we talk about the issue on Phabricator? Thanks in advance.--◂ épinetalk♬ 11:26, 22 January 2018 (UTC)[reply]
It's not for Phabricator. The lock icons are added by local protection templates like {{pp}} which uses Module:Protection banner. A protection template has to be added manually (or by a bot if you have it) to protected pages at ckb:Special:ProtectedPages. You do have some protection templates at ckb:Special:PrefixIndex/Template:Pp and you have ckb:Module:Protection banner but the module is currently only transcluded on one mainspace page and that page is not protected. It seems to be working on some non-mainspace pages. PrimeHunter (talk) 12:12, 22 January 2018 (UTC)[reply]
Just a bit more: There is a feature request to add this to MediaWiki. --Izno (talk) 12:41, 22 January 2018 (UTC)[reply]
@PrimeHunter: what can I do so it will work properly on all the namespaces? Also, since we're at it, we don't have the feature where the protected pages give you the option to submit an edit request either. How can I fix that one?--◂ épinetalk♬ 15:50, 22 January 2018 (UTC)[reply]
I don't know the language and don't have administrator rights or even an autoconfirmed account there so some things are difficult to test. I'm not aware of errors. Just try adding the templates to protected pages and see what happens. PrimeHunter (talk) 20:59, 22 January 2018 (UTC)[reply]
Is there any way when using "what links here" to exclude those incoming links which are the result of a template in an article? DuncanHill (talk) 21:43, 22 January 2018 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Filters on Special:RecentChangesLinked will get the new look similar to on the recent changes page. Special:RecentChangesLinked will also get some new features. [18][19]
Problems
With the new OOUI look menus and popups can open upwards instead of downwards. This was meant to make long dropdown menus easier to use. Sometimes these menus have been overlapped by other things. This is now fixed. [20]
Changes later this week
There is no new MediaWiki version this week.
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 24 January at 16:00 (UTC). See how to join.
Future changes
irc.wikimedia.org will be rebooted on 22 February. Some bots use this to get the recent changes feed. They need to be able to reconnect automatically or they will not work until they have been fixed. Most bots can reconnect automatically. [21]
I couldn't find it easily, but a while ago, people were talking about having proper Special:Tags on AWB edits. Thanks to User:Reedy, this may get done sooner rather than later. Two things:
It looks like users will have to update their AWB software to get this tag, so it won't be 100% (and it's almost nobody right now). If you're familiar with AWB and/or the .NET Framework, and you would like to help get an updated version out the door (including, but not limited to, this particular feature), please look over Wikipedia:AutoWikiBrowser/Technical and then pitch in.
It looks like the tags need to be created at each AWB-using wiki. This doesn't look hard, but it does require action by an admin at each wiki. If that's you, please check phab:T111663 for the instructions.
I'm not sure (perhaps the AWB team can confirm this), but I believe there is a mechanism built in to AWB to allow them to prevent using versions which are too old (presumably defined by the content of some web page). עוד מישהוOd Mishehu 07:41, 23 January 2018 (UTC)[reply]
There is a new Discourse test support channel for Wikimedia developers. You can ask questions or answer others questions about MediaWiki and Wikimedia software development. [4]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 January. It will be on non-Wikipedia wikis and some Wikipedias from 17 January. It will be on all wikis from 18 January (calendar).
Resolved
The left photo displays a Redlink to a page I have created (this has happened a few times before), which can be seen on the right.
.jpg)
