Jump to content

User talk:King of Hearts/Archive/2013/12

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

filter 225 considered harmful

[edit]

Hello KoH, been having some trouble with your uber-aggressive regex. While I understand you are trying to help protect wikipedia, you are 'protecting' her by preventing good-faith edits. Strongly suggest you change 225 from prevent, to warn. It is impossible for me to discuss policy with a beginning editor, because when I try to link them to WP:SO CK PUPP ET your filter stops me.

No, before you ask, I do not consider tweaking the regex to permit this *one* particular specific problem through. That's what happened the *last* time I was stopped by a filter. Wikipedia is the encyclopedia anybody can edit. Enforcement of WP:NICE through bots that cannot read english, is counterproductive, and harms wikipedia. Soft security, with logging and later followup, is the correct approach methinks. Please ping my talkpage when you have a chance to reply, thanks. p.s. In the meantime, I've found a workaround which let me advise the beginner, but I would like to get this 225-prevention-thing fixed permanently, so I still want to bend your ear even though I forced my way past the filter yet again. Thanks. 74.192.84.101 (talk) 18:51, 21 November 2013 (UTC)[reply]

I have remove SOCK(PUPPET) from the list. Everything else is a swear word in all caps. This is a significant difference from "sockpuppet" which is a legitimate word, so I do consider tweaking this specific instance to be meaningful. -- King of ♥ ♦ ♣ ♠ 01:51, 22 November 2013 (UTC)[reply]
Sure. Meaningful tweak. Improves the filter. But this is the second time the filter has bitten me. The first time I was talking about how sometimes I suck at doing certain sorts of editing, which of course was written in allcaps. Wikipedia is not censored. WP:NICE is something I'm a nazi about, but the bot is not enforcing WP:NICE, it is enforcing WP:InherentlyBuggyUntilStrongAI. Twelve kilobyte table, trying to take over the wikiverse. "your harmful action has been blocked". No way to know what it was. Second time, same problem. I finally eliminate absolutely *everything* in allcaps... and figure out the filter is blocking me based on *policy* links that are traditionally in allcaps. Sigh.
  The point here, the root of the problem, is not whether any particular instance of WP:BITE can be repaired. The point is, somebody is going to make a mistake in the future. They're going to add something to the regex list, which will block somebody. But note well, even if the regex never changes from here on out, sooner or later filter#225 will strike again, because there will be a newly-created policy shortcut which accidentally triggers the existing keywords. WP:OMG, right?
  So at the end of the day, I still want to see the filter changed from prevent, into warn. It is too bitey. There is no way it can be made safe, until skynet's knowledge begins to grow at a geometric rate. Alternatively, failing that, I'd also be satisfied if you want to leave the regex-matches exactly the way they are... but apply them equally to every user, no exceptions, no caste-system, even admins are prevented from saving an edit which matches. Then, we would still have the encyclopedia that anyone can edit. But anything less, and methinks we're doing it wrong. 74.192.84.101 (talk) 03:09, 22 November 2013 (UTC)[reply]
This is not about enforcing WP:NICE. This is about stopping vandalism, and targets only edits where the false positive rate is sufficiently low: the string must match one of the regexes and the user must be not autoconfirmed. And like it or not, this "caste system" does exist already regardless of this filter; non-autoconfirmed users cannot edit semi-protected pages, for example. I find it odd that you are complaining about this filter when semi-protection is a much greater restriction because of how often it is applied. This is why we strongly recommend people to create accounts, but if you do not wish to do that, then unfortunately you'll have to accept some inconveniences. -- King of ♥ ♦ ♣ ♠ 04:08, 22 November 2013 (UTC)[reply]
TLDR?
Everything you say is correct.  :-)   Yes, the caste-system exists. I'm attempting to overturn it, slowly and gradually. Yes, wikipedia is no longer the encyclopedia anyone can edit... and page-protection is certainly high on my list of problems. But obviously, the *fact* of page-protection is not really the problem, right? The problem is admins that, as a knee-jerk reaction, slap on page-protect-indef without really thinking it through in terms of encyclopedia-anyone-can-edit, because after all who cares about anons, they are low-caste. So yeah, filter#225 is hardly the biggest windmill that I could be tilting at. But it's a small part of the problem... maybe small enough I can manage to convince you my crazy approach is actually not-all-that-crazy.
  The real difficulty here, the difference in our thinking, is the phrase "sufficiently low". How are you measuring that, percentage or absolute-count? How are you deciding what is "sufficient" and what is "too bitey"? This boils down to, what is the value of an editor, that is bitten... and their potential future contributions, were they not. p.s. Inability to edit wikipedia, seems more like a fundamental flaw, striking at the heart of our mission, than an inconvenience. By contrast, not having a watchlist is a damn inconvenience, but one which I can correct by writing my own local javascript wiki-tools... whereas the only way to 'correct' a bitey filter is by modifying the filter itself.
  And methinks we *can* modify it in a way that is wp:nice to the editors it inconveniences, with a friendly message, and a quick workaround, if they *are* one of the few false-positive-folks. Instead of assuming vandalism, we can assume false-poz. But before we go down that pathway, I have to kinda figure out if you personally approve of the implicit caste-system, as opposed to merely recognizing the fact that it exists... because why should you do any work to tweak the filter, if you don't agree with the goals I have in mind. Hope this clarifies. 74.192.84.101 (talk) 13:04, 25 November 2013 (UTC)[reply]
Lemme try the nutshell version.  :-)   Agree the caste-system exists. Definitely don't like it. Nothing odd about starting small, though yes, I also plan to tilt at the semi-prot windmill someday. But first things first; I'd like to change filter#225, and have specific suggestions how to have our cake and eat it too, and to enact *that* change, I only need to convince you, personally.
  But before trying, to avoid wasting the time of either one of us, I kinda need to know, do you *personally* like-or-even-just-tolerate the implicit caste-system? Your user-page does not say. I also dislike vandalism... but, ought enWiki have 100% semi-prot for all pages all the time, like deWiki? Methinks not. 74.192.84.101 (talk) 12:56, 28 November 2013 (UTC)[reply]
I disagree with a blanket policy on all edits by new users as dewiki does. However, I feel that for measures designed to target specific patterns of behavior, it is OK to restrict them to just new users. -- King of ♥ ♦ ♣ ♠ 01:18, 29 November 2013 (UTC)[reply]

Okay, we agree. But as you can see, I'm not a new user. Yet I'm prevented from editing, from time to time, by filter#225. That makes me, personally, a false-positive. No harm, no foul, I understand how to get around the trouble. I'm here for the other false-positives, who are not savvy about regex limitations, the *actual* beginners. WP:RETENTION concerns mean we ought to treat them without WP:BITE, if at all possible.

couple paragraphs about when statistically-motivated user-profiling is okay, and when it is not
  If we change filter#225 from prevent, over to warn, it will still target new users, statistically speaking. I'm fine with that; we do not have the personnel at present to handle a truly fair approach. Filter#225 is like demographic profiling: very effective, but has to be done very carefully.
  Now, if you were to change filter#225, to block all users with GeoIP indicating they were from Countries Formerly Known As Yugoslavia, but permit western Europe and also North Americans to edit freely, *then* you would be doing it wrong, the equivalent of racial profiling, agree? Even worse, if filter#225 auto-checked on userpages, and only blocked somebody if they had this-user-is-a-muslim on their page, *that* would be a Very Bad Thing, eh? Those are in stark contrast to something perfectly valid, which is separating usually-new from usually-experienced by the autoconfirmed technology, is a-okay, we both agree.

The question is, what is the filter's behavior, when a false-poz happens? Right now, the behavior is block, with no info on how to get out, and requires "inconvenience" on the part of the beginner: they have to learn how to contact KoH directly, or navigate the sea of abuse-filter-bureaucracy, when they may not have ever even used a talkpage before. I'm asking that we change the behavior to warn (or perhaps block-but-allow-manual-override which I believe is technologically possible). This shifts the inconvenience to the folks who monitor the filter-alert-logfiles, all of them long-standing wikipedians that know the system well, and away from the beginning editors. That is a good tradeoff... as long as we don't overburden the guardians!

  You know 225 better than me; what sort of burden are we talking about? What sort of guardian-wikiStress do we currently operate under? What evidence do we have for false-poz folks, besides my own two incidents, if any? If it turns out that the math is against us, and we have to stay with 'prevent', what can we do. Not much... but we could change the message, so that beginners understand that allcaps 4letter badwords are why they got blocked, and ideally, the error-message can also suggest bold as the correct workaround. But the message should presume the editor is a false-poz, even when statistically-speaking 9 out of 10 turn out to be Bad Eggs. Or even 999 out of 1000, tempered by and depending on the math of guardian-burden-ness. — 74.192.84.101 (talk) 16:26, 30 November 2013 (UTC)[reply]

By "new user" you know what I mean: unregistered users and new accounts. This is why we highly encourage people to create accounts, and why most regular editors do so. Wikipedia was not designed with anons becoming regular editors in mind. So if you wish to continue editing as an IP, you will have to accept the inconveniences. -- King of ♥ ♦ ♣ ♠ 18:36, 30 November 2013 (UTC)[reply]
Absolutely. But, as I try to point out above, this is not about me. I already accept the inconveniences. I already know the workarounds. My goal here is a discussion about not driving away actual beginners. Do you disagree that filter#225 has false positives, not counting myself? Of course, creating an account doesn't, by itself, help beginning editors avoid making mistakes. Wikipedia *is* designed with encouraging anybody to edit firmly in mind; my point is that filter#225 tends to counteract that design goal, in the actual-beginner-false-positive-scenario. 74.192.84.101 (talk) 19:25, 30 November 2013 (UTC)[reply]
Yes, being hindered by a filter can deter beginners. But what about going to a page and seeing profanities in all caps written all over it? That fuels the "anyone can edit so Wikipedia is unreliable" mentality, the avoidance of which is about as important as attracting newcomers. And not only that, newcomers might be in fact deterred by that, thinking that Wikipedia is a hostile or immature place where people randomly deface pages for fun or out of spite. -- King of ♥ ♦ ♣ ♠ 05:22, 1 December 2013 (UTC)[reply]
KoH my friend -- wikipedia is a place where Some People randomly deface pages for fun or out of spite.  :-)   The truth hurts! And although I could reply by saying that subtle vandalism is more deadly to perceived reliability, I won't, because bot-prevented vandalism keeps the guardians from needing to mess with obvious stuff, and theoretically at least gives them more time to search for the subtle attacks. Anyways, yes, your point is well-taken. There are some engineering tradeoffs here: if we prevent by default, some good-faith beginners will be bitten (the false-poz count BEFP). Alternatively, if we only warn-with-override, some *smaller* number of good-faith beginners will *still* be bitten (the ones mortally offended by the warning-text aka BEFP2). Plus, more "W1K1PEdia iz 4 A2Z W1P3S" ... uh oh ... <grin> manually redacted this since the bot missed it stuff will get through our bohts, and unless we have enough guardians with the filter-alerts on their watchlists, to revert it quickly, then the readership will start to get a bad opinion about wikipedia's reliability, and this could conceivably drive away potential editors (BEFP2+BPENR).
 But this is all one big ball of wax methinks: we have to start retaining more editors, so we have enough guardians to revert bad stuff, but also, so we have enough content-contributors to maintain-and-create the good stuff, reliably-factual reliably-neutral reliably-sourced encyclopedic articles. Anyways, do you have some ballpark numbers for how many prevents that filter#225 has made? Is there a log of the texts that were blocked, so I can do some analysis on how many were good-faith false-poz, and how many were on target? We can only guesstimate BPENR, methinks, but we *can* calculate an approximate BEFP.
  p.s. Figuring out the vandalism that filter#225 *misses* is much harder, of course, since we would have to analyze All Accepted Edits which is orders of magnitude larger, but for my purposes I'm willing to assume that is zero. As the maintainer, of course, you're prolly pretty interested in that number.  :-) But we don't need it for this discussion, although if you have some kind of wiki-tool that analyzes such things, maybe we can repurpose it to estimate false-poz BEFP. Is there such a tool?
  p.p.s. Here is my proposal for some kind of recent-edit-post-it-note-colorization,[1] to help improve perceived reliability, which I agree is incredibly important. You can also see portions of my metaWiki battles with *their* AbuseFilter config, compared to which the enWiki filter#225 is a walk in the park. But perhaps that will help explain my motivations here,[2][3] a bit more clearly. TLDR warning strongly applies, though; sorry about that. 74.192.84.101 (talk) 01:11, 2 December 2013 (UTC)[reply]
Yes, here. You ought to be able to see it since 225 is a public filter. -- King of ♥ ♦ ♣ ♠ 09:41, 2 December 2013 (UTC)[reply]

Ah, cool, I'd looked earlier but not been able to see some filters (not 225). That helps, thanks. But srsly, now, for the love of the Great Jimbo, how can anyone say that *this* edit was not in good faith?[4] Oh wait. Wait a minute. *Not* that one. Um, that one is very scary.  :-)

  I clicked about a dozen of them from today, and then cheated, and used the manual-by-eyeball-sorting-device of looking for blue-linked-usernames. (See, I do believe in statistically-effective profiling.) This editor was a false-poz.[5] They were typing some arabic phrases in all-caps, names of the books of some particular religious leader. Now, obviously, they need a lesson in WP:UNDUE, since their ten-kilobyte-essay was too long, and also some manual-of-style assistance, not to mention WP:TONE, but there *is* at least one other editor that was attempting to improve the encyclopedia, right?

  I'll do some stats-analysis, of N randomly-chosen chronological sequences of M edits each, and see how many false-poz events I notice. What's your guess at the ratio? 99 to 1, maybe? I'd like to see how well your expectations as the filter-owner, match the outcome of some empirical checks. I'd guess 200 to 1 as a pessimist, or at best 50 to 1 as an optimist, but I won't be surprised to find 999 to 1 at the end of the day. Care to put forth your own educated guess?

  p.s. But even without doing the analysis yet, there are a *lot* of those dern things in the hit-log. Prolly instead of asking for 225 to be placed on warn, instead I'll end up asking for filter#999 to be created which handles usernames, or ideally, which does some frequency-counting or bayesian-grammar-analysis on the stuff, to decide whether to allow the person to override.

  p.p.s. Of course, that doesn't mean that filter#225 does not need some tweaks. See for instance [6] who made nineteen edits on December 2nd during half an hour of minecraft-related vandalism.

the tale of the 24th visigoth
  1. = 16:45, 2 December 2013 Fluffernutter (talk | contribs) blocked 24.235.102.171 (talk) (anon. only, account creation blocked) with an expiry time of 31 hours (anonblock)
  2. V 16:44, 2 December 2013 (diff | hist) . . (+2)‎ . . Mars Exploration Program ‎ (→‎Topographical challenges)
  3. V 16:35, 2 December 2013 (diff | hist) . . (+59)‎ . . Mars Exploration Program ‎ (→‎Goal 3: Characterize the geology of Mars)
  4. - 16:34, 2 December 2013: 24.235.102.171 (talk) triggered filter 225, Actions taken: Disallow; Filter description: Vandalism in all caps (details | examine)
  5. - 16:34, 2 December 2013: 24.235.102.171 (talk) triggered filter 225, Actions taken: Disallow; Filter description: Vandalism in all caps (details | examine)
  6. - 16:34, 2 December 2013: 24.235.102.171 (talk) triggered filter 225, Actions taken: Disallow; Filter description: Vandalism in all caps (details | examine)
  7. V 16:31, 2 December 2013 (diff | hist) . . (+22)‎ . . Mars Exploration Program ‎ (→‎Goal 3: Characterize the geology of Mars)
  8. - 16:31, 2 December 2013: 24.235.102.171 (talk) triggered filter 225, Actions taken: Disallow; Filter description: Vandalism in all caps (details | examine)
  9. V 16:29, 2 December 2013 (diff | hist) . . (+19)‎ . . Mars Exploration Program ‎ (→‎Goal 3: Characterize the geology of Mars)
  10. V 16:28, 2 December 2013 (diff | hist) . . (+5)‎ . . Mars Exploration Program ‎ (→‎Goal 3: Characterize the geology of Mars)
  11. - 16:27, 2 December 2013: 24.235.102.171 (talk) triggered filter 225, Actions taken: Disallow; Filter description: Vandalism in all caps (details | examine)
  12. V 16:26, 2 December 2013 (diff | hist) . . (-1,957)‎ . . Mars Exploration Program ‎ (→‎Topographical challenges) (Tag: possible vandalism)
  13. / 16:26, 2 December 2013: 24.235.102.171 (talk) triggered filter 432, Actions taken: Tag; Filter description: Starting new line with lowercase letters (details | examine | diff)
  14. / 16:25, 2 December 2013: 24.235.102.171 (talk) triggered filter 432, Actions taken: Warn; Filter description: Starting new line with lowercase letters (details | examine)
  15. - 16:25, 2 December 2013: 24.235.102.171 (talk) triggered an edit filter, Actions taken: Disallow; Filter description: Addition of bad words
  16. V 16:24, 2 December 2013 (diff | hist) . . (-941)‎ . . Mars Exploration Program ‎ (→‎Goal 3: Characterize the geology of Mars)
  17. V 16:22, 2 December 2013 (diff | hist) . . (+6)‎ . . Mars Exploration Program ‎ (→‎Goal 4: Prepare for the human exploration of Mars)
  18. - 16:21, 2 December 2013: 24.235.102.171 (talk) triggered an edit filter, Actions taken: Disallow; Filter description: Common vandal phrases
  19. V 16:20, 2 December 2013 (diff | hist) . . (+10)‎ . . Mars Exploration Program ‎ (→‎Goal 4: Prepare for the human exploration of Mars)
  20. V 16:19, 2 December 2013 (diff | hist) . . (+4)‎ . . Mars Exploration Program ‎ (→‎Goal 4: Prepare for the human exploration of Mars)

Seven times they were disallowed, five of those by filter#225. There were also two warnings. But the first couple edits were not caught (even tagged), and even with filter#225, the vandal quickly figured out the same workaround trick that I used -- breaking up the letter-patterns to get past the filter. Maybe, while I'm trying to research a false-poz detector, we can also improve our false-neg performance. In the meantime, isn't there a "throttle" setting, that could be enabled on 225, which might have helped slow the visigoth above down somewhat? Sorry about the usual walloftext; I'll leave you alone for a bit, while I try to analyze the hit-log for 225. (And in particular, feel free to archive this thread, if you'd like to declutter your talkpage.) Thanks for improving wikipedia, see you around. 74.192.84.101 (talk) 18:50, 2 December 2013 (UTC)[reply]

GAN December 2013 Backlog Drive

[edit]
Hello! Just a friendly reminder that the GAN Backlog Drive has begun and will end on December 31, 2013!

If you know anyone outside of the WikiProject that may be interested, feel free to invite them to the drive!

If you have any questions or want to comment about something regarding the drive, post them here--EdwardsBot (talk) 00:01, 3 December 2013 (UTC)[reply]

Wikimedia NYC Meetup- "Queens Open History Edit-a-Thon" at Queens Library! Friday December 6

[edit]
Queens Library
 Please join Queens Open History Edit-a-Thon on December 6, 2013!
Everyone gather at Queens Library to further Wikipedia's local outreach
for borough articles on the history and the communities.
Drop-ins welcome 10am-7pm!--Pharos (talk) ~~~~~

Requesting info for FAQ/help section

[edit]

Hi,

Seasons greetings, I want to work on a help page that eventualy helps reduce misunderstanding about Edit Filters and builds community confidance.I have listed down few points for myself and would like to discuss one by one over a period of time.(Not all of them at the same time because we have to cope up with other tasks too)

This time say I want to answer a simple question "Why some filters are hidden/private when wikipedia talks about openness ?" I have seen you replying similler question previously in apropriate way on your talk page but I forgot the thread so would appreciate your help.I will also be adding some points to above question.

Why do I feel this FAQ necessay because for an example like at this discussion probably it could have been answered differently without indirectly divulging information under peer pressure.

Mahitgar (talk) 15:30, 4 December 2013 (UTC)[reply]

The Signpost: 04 December 2013

[edit]

Tech News: 2013-49

[edit]

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

This newsletter is now posted using MediaWiki message delivery.

New features

  • The CommonsMetadata feature was added to all wikis. It creates metadata information about multimedia files (like their license) that can be read automatically by computer programs. It not only works for Commons, but for all wikis, and you can use it for files on your wiki by editing templates used to describe metadata. [7]
  • JavaScript code used on Wikimedia sites is now saved locally on your computer to load faster. [8]

VisualEditor

  • You can now paste formatted content copied from external sources (not just as plain text) into VisualEditor; this includes copy/pasting from other VisualEditor windows. [9]
  • You can now open VisualEditor by adding ?veaction=edit to the page URL, regardless of your user preferences. [10]
  • Many bugs have been fixed, and VisualEditor should also look faster, for example when you save a page. [11]

Problems

  • Due to issues, the new search tool ("CirrusSearch") was recently removed from wikis where it was enabled, then added again. [12]

Future

Tech news prepared by tech ambassadors and posted by MediaWiki message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

08:38, 9 December 2013 (UTC)

The Signpost: 11 December 2013

[edit]

Tech News: 2013-50

[edit]

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

New features

VisualEditor

  • The toolbar is now simpler; all text styles (bold, italics, underline, subscript, etc.) are in the same menu, and the "More" menu is called "Insert". [16]
  • You can now use a basic tool to add special characters to your text. You can add more characters (useful in your language) by editing the MediaWiki interface on translatewiki.net.
  • The tool to add and edit mathematical text is now called "formula". [17]

Problems

  • There was a problem with the "Create a book" tool (Collection); books could only be exported to PDF format. The change has been undone. [18]
  • The log-in system for external tools ("OAuth") was broken on wikis that tested the new search tool. It was fixed last week. [19] [20]
  • Because of a bug, this newsletter is delivered to users using the new MediaWiki message delivery, and to community pages using the old EdwardsBot. [21]

Future

  • MediaWiki 1.23wmf7 was added to test wikis on December 12. It will be added to non-Wikipedia wikis on December 17 and all Wikipedia wikis on December 19 (calendar).
  • You will soon be able to select the language of SVG images that have translations using a drop-down menu on the image page. (see example) [22]
  • GLAMToolset, a tool to help GLAM groups (like museums) upload many pictures to Commons, will be added to Commons on December 17. [23]
  • A Draft namespace will be added to the English Wikipedia to make it easier to create new pages. You will be able to use VisualEditor for drafts if you have enabled it. [24] [25]

Other

Tech news prepared by tech ambassadors and posted by MediaWiki message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

08:24, 16 December 2013 (UTC)

The Signpost: 18 December 2013

[edit]

You're invited: Art & Feminism Edit-a-thon

[edit]
Art & Feminism Edit-a-Thon - You are invited!
Hi King of Hearts! The first Art and Feminism Edit-a-thon will be held on Saturday, February 1, 2014 in San Francisco.

Any editors interested in the intersection of feminism and art are welcome. Wikipedians of all experience levels are invited! Experienced editors will be on hand to help new editors.
Bring a friend and a laptop! Come one, come all! Learn more here!

Geoffrey C. Grabowski

[edit]

Hi King of Hearts,

You deleted Geoffrey C. Grabowski after closing the AFD. Do you have any objections to userfication so that I can do some work on it? BOZ (talk) 05:29, 22 December 2013 (UTC)[reply]

 Done - User:BOZ/Geoffrey C. Grabowski. -- King of ♥ ♦ ♣ ♠ 04:54, 23 December 2013 (UTC)[reply]
Thanks! :) BOZ (talk) 13:19, 23 December 2013 (UTC)[reply]

Tech News: 2013-51

[edit]

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

Recent software changes

  • The latest version of MediaWiki (1.23wmf8) was added to test wikis and MediaWiki.org on December 19. It will be enabled on non-Wikipedia wikis on December 31 and on all Wikipedia wikis on January 2, 2014 (calendar).
  • You can now test the new search tool ("CirrusSearch") on all Wikisource, Wiktionary and Wikimedia chapter wikis hosted on Foundation servers. Enable "New search" in your Beta features preferences. [27]
  • There was a bug where notifications were not sent when the signature of the user leaving the message linked to a translated namespace. The problem was fixed in the software and will soon be fixed on Wikimedia sites. [28] [29]
  • You can now use the log-in system for external tools (OAuth) on all Wikimedia wikis that use the unified login. [30]
  • If your wiki adds stars or other icons to interwiki links for featured articles in other languages, you may need to change the JavaScript code. [31]
  • You can thank other users for their edits even if your browser does not have JavaScript. [32] [33]
  • All edits made through Flow, the new discussion system for MediaWiki, are now visible in user's contributions. You can test it on the Flow talk page on MediaWiki.org. [34] [35]
  • You can test a visual tool that shows edits made to an article over time. It only works for English Wikipedia pages for now and is slow on long articles. [36]
  • You can test the first version of the new mobile Wikipedia app for Android and iOS. [37]
  • Translatewiki.net, the site where you can translate the MediaWiki software, now has a new main page for users without an account. [38]

Future software changes

  • There will be no technical changes this week (December 23 to December 29) due to end-of-year holidays.
  • When someone deletes, restores, uploads, or moves a file on Commons, pages on all wikis that use that file will be refreshed. [39] [40]
  • New users will soon have their user and talk pages added to their watchlist as soon as they create an account. [41] [42].
  • The new search tool (CirrusSearch) will not show the text of versions of a page that have been hidden. [43] [44]
  • You will soon be able to see the raw HTML created by some wikitext by using the Special:ExpandTemplates tool. [45] [46]

Tech news prepared by tech ambassadors and posted by MediaWiki message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

08:22, 23 December 2013 (UTC)

Infobox Photo Discussion

[edit]

Hi. Can you offer your opinion in this discussion regarding the better photo for an article Infobox? Thanks, and Happy Holidays. Nightscream (talk) 23:47, 26 December 2013 (UTC)[reply]

A trip down memory lane

[edit]

Hey King, can I ask you to have a look at this old discussion? There seems to be a clear consensus to blacklist Twinkle/rollback abusers, and you remarked that such a list used to exist. Can you maybe restore that list and/or set up the other mechanicals listed by Scottywong in that discussion? We should have taken care of this months ago. Thanks! Drmies (talk) 21:38, 27 December 2013 (UTC)[reply]

Unfortunately, I don't know how to set up a Twinkle blacklist, because IIRC the ability to process the blacklist was removed from the Twinkle source code. I only used it as an end-user. Try talking to a Twinkle developer. -- King of ♥ ♦ ♣ ♠ 22:15, 27 December 2013 (UTC)[reply]
They don't frequent the bars I hang out in--probably because geeks only drink milk. (BTW, I dropped you a line since you seemed to know what you were talking about!...unlike me) Writ Keeper, are you Twinkling these days? King of Hearts, I lost your address so your Christmas card may be a bit late this year, but I hope you got everything you wanted and more. As for me, I got these great Calphalon skillets, so come by tomorrow morning for some well-fried eggs. Thanks, Drmies (talk) 04:21, 28 December 2013 (UTC)[reply]
Well, looking at the source, it should be easy enough to do, but I'm not a Twinkle dev, so I can't do it myself. (Well, technically I could implement it on the live version, but there'd be little point to do that if the baseline code in Git doesn't get updated at the same time.) I don't know whether or not we have enough consensus to start actually blacklisting people, but I don't think at least providing the ability do do so is a bad idea. I've started a thread about it on User talk:AzaToth, who is I guess the head developer of Twinkle (and is a username after my own heart, incidentally), so head there if you are interested in the technical things. @Drmies: what brought this to mind, anyway? Writ Keeper ⚇♔ 06:22, 28 December 2013 (UTC)[reply]
Thanks WK. I assume that AzaToth is the name of a penis in Game of Thrones or something like that. I was asked about this on my talk page by an IP editor, and I think it's worthwhile checking it out. Later y'all, Drmies (talk) 17:57, 28 December 2013 (UTC)[reply]

The Signpost: 25 December 2013

[edit]

Gpt

[edit]

deleted page Gpt could be a link to GPT page — Preceding unsigned comment added by 177.132.87.167 (talk) 09:26, 28 December 2013 (UTC)[reply]

User:Entertainment4u2013‎

[edit]

Given you blocked the above user and their sock puppet User:Runner247 shouldn't their comments at this AfD be stricken out? ★☆ DUCKISJAMMMY☆★ 05:30, 30 December 2013 (UTC)[reply]

I think it's fine to leave them as is; they're clearly labeled with SPA tags and the closing admin will know what weight to give those arguments. -- King of ♥ ♦ ♣ ♠ 06:42, 30 December 2013 (UTC)[reply]
Ok, thanks for the clarification. ★☆ DUCKISJAMMMY☆★ 06:54, 30 December 2013 (UTC)[reply]

Tech News: 2014-01

[edit]

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

Recent software changes

  • You can now see the text of DjVu and PDF files in search results on wikis testing the new search tool (CirrusSearch). [47] [48]
  • With the new version of the Wikibase DataModel extension, you can install it outside Wikimedia wikis. [49]

VisualEditor news

  • Images are now shown inside VisualEditor as HTML5 <figure /> elements. Comments are welcome. [50]
  • You can now test a basic version of VisualEditor on mobile devices; see this article as an example.

Problems

Future software changes

  • CirrusSearch will be added as the second search method for Spanish (es), French (fr), Portuguese (pt) and Russian (ru) wikis on December 30. Wikimedia Commons, Wikispecies and Wikinews users will also be able to enable it in their Beta Features options.
  • AbuseFilter log entries will be visible in CheckUser tool reports. [52] [53]
  • It will soon be possible to search for log entries done by users without an account. [54] [55]
  • It will no longer be possible to globally hide users with more than 1,000 edits. [56] [57]

Tech news prepared by tech ambassadors and posted by MediaWiki message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

08:40, 30 December 2013 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=User_talk:King_of_Hearts/Archive/2013/12&oldid=1139588072"