In T114432#3707792, @cscott wrote:inside a template and immediately follows a | or = with no whitespace *and* the >>> is immediately followed by a | or }}
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Nov 1 2017
Nov 1 2017
Alsee added a comment to T114432: [RFC] Heredoc arguments for templates (aka "hygienic" or "long" arguments).
Oct 22 2017
Oct 22 2017
Alsee added a comment to T169924: Option to disable notifications about 1st, 10th, etc. edit ("You made your <milestone> edit!").
Oct 21 2017
Oct 21 2017
In T158474#3038300, @matmarex wrote:My patch above only ensures that it's impossible to actually register that username and make real edits using it.
You can document its purpose on its user page, like it was done e.g. for https://de.wikipedia.org/wiki/Benutzer:Maintenance_script.
Note user:Unknown_user already existed on EnWiki (and only on EnWiki). It was created and briefly used for a few days in 2004. It has 126 edits. Any username should always be checked for existence before using it for any system purpose.
Oct 20 2017
Oct 20 2017
Alsee added a comment to T114432: [RFC] Heredoc arguments for templates (aka "hygienic" or "long" arguments).
I believe the proper behavior (meaning the easiest to understand and most expected behavior) is to just protect the wrapped content then behave as if the <<< and >>> don't exist. This does a good job of covering most of the listed edge cases. For example:
{{foo |<<<You know someone's going to do >>> this at some point accidentally. What happens?}}
would be identical to
{{foo |You know someone's going to do this at some point accidentally. What happens?}}
• Elitre awarded T154843: New Wikitext Editor: Major improvement to load time and preview time a Love token.
Oct 11 2017
Oct 11 2017
Alsee added a comment to T171027: "Read timeout is reached" DBQueryError when trying to load specific users' watchlists (with +1000 articles) on several wikis.
In T171027#3673060, @Lydia_Pintscher wrote:This is a hugely political issue.
Oct 11 2017, 10:29 PM · User-notice-archive, Growth-Team, MW-1.31-release-notes (WMF-deploy-2017-10-03 (1.31.0-wmf.2)), MediaWiki-extensions-WikibaseRepository, Wikidata-Former-Sprint-Board, Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), DBA, Wikidata, Commons, Contributors-Team, Wikimedia-production-error, MW-1.30-release-notes (WMF-deploy-2017-08-08_(1.30.0-wmf.13)), Russian-Sites, WMF-General-or-Unknown, Performance Issue, MediaWiki-Watchlist
Oct 3 2017
Oct 3 2017
Many people experience this. Using Visual Editor for previews is often absurdly slow, upwards of a minute in some cases. From a UX perspective, there is little meaningful difference between:
- freezing for over thirty seconds then successfully showing a preview;
- freezing for over thirty hours then successfully showing a preview; or
- freezing permanently.
Oct 1 2017
Oct 1 2017
As has already been demonstrated, running two parallel systems to track the same information is unreliable. And you acknowledge that more work would be needed (T131896) trying to fix the span method. Given that "Using the category is easy", I'm puzzled why you'd even bother advocating invisible, unreliable, duplicate, currently-broken method which needs repairs?
Alsee added a comment to T175158: Make it possible to manually exclude unsuitable pages from related articles.
There have been a lot of objections to RelatedPages putting pseudo-random links on articles. Putting Islam on Misogyny, fascism on a politician, I think Pig-faced woman ended up on a woman's biography. It just put promotional links for two brands of tissue on the Facial_tissue article, and one of the links literally included an image of an advertisement for that brand. The WMF slapped an advertisement on the article. I'm just waiting for someone to find Pedophilia on someone's biography.
To staff/devs: Thanks for the quick fix here.
Sep 30 2017
Sep 30 2017
• Elitre awarded T177122: Non-free images incorrectly appearing in RelatedPages a Like token.
Sep 29 2017
Sep 29 2017
Alsee added projects to T177122: Non-free images incorrectly appearing in RelatedPages: RelatedArticles, PageImages.
Sep 17 2017
Sep 17 2017
First, a huge thank you for working on showing moves in diff! YEAY!
Aug 27 2017
Aug 27 2017
Alsee added a comment to T6521: Colon (:) & semicolon (;) shouldn't output as HTML definition list when used for indentation, boldfacing.
Some of the comments above suggested treating article pages and talk pages differently. That's a mistake. A generic page should be presumed to contain both article content and discussions. Copying arbitrary article content to any page is a fundamental part of our work.
Aug 9 2017
Aug 9 2017
To put it more succinctly, I want a "mode" where the next&previous links are tied to the user rather than tied to the page. I just can't think of a good place or method in the interface to request that mode.
Aug 5 2017
Aug 5 2017
Alsee added a comment to T57370: [Epic] VisualEditor: Implement some form of auto-save to help with browser crash recovery and accidental tab closing.
@Whatamidoing-WMF
I am admittedly stretching the limits of what I know about javascript, but it appears something like
textarea.on('input', ...
solves that issue. I'm unsure, but a little extra code may be needed to catch cut/paste via right click.
Aug 3 2017
Aug 3 2017
Alsee added a comment to T57370: [Epic] VisualEditor: Implement some form of auto-save to help with browser crash recovery and accidental tab closing.
In T57370#3490603, @Whatamidoing-WMF wrote:Because it isn't actually possible in the older wikitext editors.
Aug 1 2017
Aug 1 2017
Alsee added a comment to T57370: [Epic] VisualEditor: Implement some form of auto-save to help with browser crash recovery and accidental tab closing.
Why is this described as a Visual Editor task? Visual Editor is a minor secondary editor, only used for a small percentage of edits. If auto save is implemented, it's certainly reasonable to also implement it in the secondary editor as well (VE).
Jul 24 2017
Jul 24 2017
Alsee added a comment to T164292: Long search times for combo of “Very likely good” + (“Likely bad faith” OR "V. likely bad faith" OR "May be bad faith").
It would be rare for someone to deliberately search for bad-faith likely-good edits, so this is not a major issue. Perhaps just display a message that the search may be slow.
Jun 29 2017
Jun 29 2017
The website vcard for the author contains an email wrapped in javascript protection. The javascript is getting copied as text, as if it's a list of additional authors. I'm not sure if the problem is on our end, or if their website is doing something invalid.
Alsee added a comment to T155732: Provide a Preview panel that doesn't obscure the wikitext box and maybe the skin's sidebar (?).
In T155732#3377259, @Frigory wrote:In T155732#3377170, @Alsee wrote:With the NewEditor it takes me over half a minute to preview United_States just once, and over five minutes staring at the blue VE-loading-bar if I want to jump between article-text and preview ten times.
Did you try Shift-Alt-P to see preview? This way it loads without the blue VE-loading-bar.
I was a little sloppy, preview shows moving gray stripes instead of a blue loading bar. It's the same problem though. Previews appear to be cached, so if you aren't actually editing then repeat previews "only" takes ~8 seconds (~4 seconds to switch ~4 seconds to switch back). However if you're actually working, each keypress kills the cache. A preview takes ~30-35 seconds to load, plus ~4 to switch back. So ten previews is over 6 minutes. Usually I just use one preview before saving, which is still an appalling and unusable performance. But yeah, sometimes we easily hit ten or more previews while working. Having preview on the same screen as the wikitext matters a lot.
Jun 28 2017
Jun 28 2017
Alsee added a comment to T168638: VE occasionally opens a link within a template instead of the template's settings when clicked.
Based on the video , it looks like the blue box was't fully covering the link. Hypothesis: If rendering of the blue box is delayed or the location is offset, the underlying link is exposed and clickable?
Jun 25 2017
Jun 25 2017
I did a little experimentation. It appears this bug is being triggered by T153315. Instead of doing a normal copy-paste, the NewEditor defaults to trying to convert HTML into wikitext. When it sees the italics it triggers HTML->Wikitext conversion. Then nowikis get spammed into your wikitext.
Alsee added a comment to T155732: Provide a Preview panel that doesn't obscure the wikitext box and maybe the skin's sidebar (?).
With the current editor it doesn't matter how long the article is. Everything is on one long screen. I simply highlight some unique text and use the browser search on it. Pressing F3 then jumps back and forth between article text and the matching wikitext.
Jun 22 2017
Jun 22 2017
Alsee renamed T154843: New Wikitext Editor: Major improvement to load time and preview time from New Wikitext Editor: Major improvement to load time to edit to New Wikitext Editor: Major improvement to load time and preview time.
Jun 9 2017
Jun 9 2017
Halibutt I'd welcome better data, but so far no one has been offering any. The community has abundant collective real-world experience, and I believe most people will find the available data to be sufficiently clear despite the imperfections.
Jun 3 2017
Jun 3 2017
@Deskana thank you for closing this. Prior to seeing you had closed this, I had also come to the conclusion that continued individual-debate here had become an unproductive time sink for everyone involved.
In T159032#3298832, @Deskana wrote:In T159032#3293776, @Alsee wrote:(Polish VE statistics)
Interesting. I would've expected that to be higher. Did you remove all the confounding factors when producing these statistics?
I listed the settings I used. I made a good faith effort to filter out confounding factors and maximize the VE percentage. Any other factors would only shift the results by a few points. The results are clear enough that fussing over a few percent won't alter the conclusions.
May 26 2017
May 26 2017
Alsee added a comment to T154843: New Wikitext Editor: Major improvement to load time and preview time.
Adding report by JAn Dudík:
United States 75 sec.
List of planets 140 sec.
I just collected data using the Recent Changes page, set to display the last 5000 edits. Bot edits and logged actions filtered out.
May 22 2017
May 22 2017
In T144571#2650519, @Jdlrobson wrote:if JavaScript fails to load... going to the file page will happen
Thank you for clearing up why some of the testing gave random results. However that is not directly related to this issue.
May 21 2017
May 21 2017
In T159032#3184818, @Halibutt wrote:The WMF ran a controlled study on the effects of visual editor, showing that it provided zero benefit to new users and finding notable negative effects. Is there anyone here who honestly thinks that a majority of the general global editing community wants VE to be made the default?
Would love to see the study you mention, never heard of it.
Research:VisualEditor's_effect_on_newly_registered_editors/May_2015_study. Results: No change in how many new users made a first edit. No change in new user retention. No change in total contributions. Visual Editing was typically over 6.7 times slower, people were more likely to abandon edits without attempting to save, and attempted saves were less likely to be successful.
May 13 2017
May 13 2017
Alsee added a comment to T68078: Indicate mentions in edit preview and in "Your edit was saved" message.
@Kipod, I strongly disagree.
May 9 2017
May 9 2017
This popup is a useless "click-to-continue" annoyance when it has only one option.
Apr 15 2017
Apr 15 2017
In T159032#3184069, @Halibutt wrote:If you really want to start a format consensus process, use the main BAR rooms, not the technical room used mostly for bug reporting.
Alsee awarded T10681: Do not group changes by day in enhanced recent changes a Like token.
Apr 4 2017
Apr 4 2017
Alsee added a comment to T153306: Have Show preview and Review your changes more directly accessible in the New Wikitext Editor.
- Burying PREVIEW in a menu behind the SAVE button leaves new users lost and scared when they actively avoid touching the dangerous SAVE button.
- Burying the most used button in the editor is disruptive for experienced editors.
The most used button in the entire editor, and second most important button in the entire editor, absolutely warrants direct placement next to the SAVE button.
Mar 28 2017
Mar 28 2017
The discussion was unanimous when I posted it. Now one person has disagreed.
Mar 27 2017
Mar 27 2017
@Halibutt : While the comments were posted "last year", they are not over a year old. They were 3 months old when I opened this Phab, and now 4 months old. Your oppose and the new responses, it looks like 6-1. Would you like to open a more formal consensus-process to get a more formal result?
Mar 25 2017
Mar 25 2017
Alsee added a comment to T154844: New Wikitext Editor: Previews should use the article-view rendering engine.
In T154844#3118613, @Jdforrester-WMF wrote:can you clarify?
Mar 21 2017
Mar 21 2017
Alsee added a comment to T154844: New Wikitext Editor: Previews should use the article-view rendering engine.
I updated the task description to reflect the closure of the RFC on this issue. Also, my understanding is that blocker tasks inherit the priority of the parent task.
Alsee renamed T154844: New Wikitext Editor: Previews should use the article-view rendering engine from New Wikitext Editor: Ensure that previews match article view as much as practical to New Wikitext Editor: Previews use the article-view rendering engine. (Consensus this is a blocker issue).
Alsee added a comment to T154843: New Wikitext Editor: Major improvement to load time and preview time.
I updated the task description to reflect the closure of the RFC on this issue. Also, my understanding is that blocker tasks inherit the priority of the parent task.
Alsee renamed T154843: New Wikitext Editor: Major improvement to load time and preview time from New Wikitext Editor: Major improvement to load time to edit to New Wikitext Editor: Major improvement to load time to edit. (Consensus this is a blocker issue).
Mar 18 2017
Mar 18 2017
Pine awarded T154843: New Wikitext Editor: Major improvement to load time and preview time a Manufacturing Defect? token.
Mar 17 2017
Mar 17 2017
Alsee added a comment to T154843: New Wikitext Editor: Major improvement to load time and preview time.
Note that the Minor Planets page has been split. Anyone wanting to test that load time should use the link in Samwalton9's post above.
Mar 16 2017
Mar 16 2017
@Jdforrester-WMF, it's been almost three weeks since I opened this bug. Can I get an answer on this?
You said VE wouldn't be imposed as the SingleEditTab default without asking the community. You said it was a bug that SingleEditTab was deployed with a VE default. EnWiki was fixed to wikitext default, per discussion with the community. And now PolishWiki has a unanimous consensus asking for SingleEditTab to have a wikitext default.
Mar 13 2017
Mar 13 2017
Alsee added a comment to T114432: [RFC] Heredoc arguments for templates (aka "hygienic" or "long" arguments).
@jayvdb's suggestion looks like the best concepts here. I'd suggest a tweak:
Mar 11 2017
Mar 11 2017
Alsee added a comment to T153315: Pasting annotated wikitext results in double encoding and therefore <nowiki>s.
I'll add another voice to the chorus saying that CTRL-V needs to be a plain text paste. The formatted paste behavior is disruptive.
Mar 9 2017
Mar 9 2017
In T99924#1550540, @Jdforrester-WMF wrote:If we let you interact with a template, we let you edit it.
Mar 8 2017
Mar 8 2017
I don't think it's a good idea to start singling out arbitrary section titles. Any empty section is almost never a desired permanent state. However it's not that unusual for sections to be empty while an article is being built, or when it's awaiting content, or when there is a debate in progress on what should/shouldn't be there.
I know next to squat about databases, so I apologize if this is incredibly dumb or obvious. Would it help to: Create the new comment table as write-only, fill it at leisure, and switch all reads&writes to the new table after it fully mirrors the existing data? Then increase the comment limit and clean up the old unused data at leisure.
That at least avoids the need to check both places during reads.
Mar 7 2017
Mar 7 2017
The task is a four letter edit.
In T159032#3081337, @Jdforrester-WMF wrote:Can you explain how this is different from T102398?
Can someone please provide some sort of a response here?
Alsee added projects to T159032: Single Edit Tab global default change: VisualEditor, VisualEditor-MediaWiki.
Feb 26 2017
Feb 26 2017
Liuxinyu970226 awarded T159032: Single Edit Tab global default change a Dislike token.
Feb 25 2017
Feb 25 2017
Feb 21 2017
Feb 21 2017
In T63729#3038137, @jeblad wrote:<rant>Sometimes I would really want a more firm standpoint from WMF against people moving backwards… </rant>
Feb 16 2017
Feb 16 2017
@Jdlrobson: I definitely didn't assume any bad faith here, and I didn't mean to "blame" anyone in particular. Consider this my attempt to stir concepts into the idea sessions :)
Why edit in the page when you can edit outside it?
Feb 14 2017
Feb 14 2017
I'm going to re-open this. Based on a Google Translate view, it looks like there wasn't really any opportunity for them to comment on enablement of Hovercards. All I saw were comments indicating they couldn't comment on it because (at that time) testing of Hovercards was disabled.
Alsee added a comment to T154202: Don't show the welcome message unless it has a "switch to visual editing" button.
@Aklapper I expanded the task in the description, and I see that this still hasn't been triaged.
Alsee updated the task description for T154202: Don't show the welcome message unless it has a "switch to visual editing" button.
Alsee added a comment to T7004: Keep the pipe trick ([[Piped link|]]) syntax in wikitext instead of converting it at pre-save transform.
In T7004#1605592, @Magioladitis wrote:I don't really agree with this request. I prefer to see what is about to be saved.
Jan 31 2017
Jan 31 2017
Alsee added a comment to T154843: New Wikitext Editor: Major improvement to load time and preview time.
Summary of load times reported at the RFC:
Alsee: United States 30 seconds. List of Planets 127 seconds.
Daß Wölf: List of planets 114 seconds. Village pump proposals 21 seconds.
Yodin: United States 35 seconds. List of planets 122 seconds.
Fram: Leuchtenberg Gallery 15 seconds. Exposition des primitifs flamands à Bruges 50 seconds.
Whatamidoing: United States 9 seconds. <--- One anomalous report
Alsee added a comment to T154843: New Wikitext Editor: Major improvement to load time and preview time.
In T154843#2982245, @Whatamidoing-WMF wrote:Alsee, are you running Windows?
Yes.
Jan 30 2017
Jan 30 2017
Alsee added a comment to T154843: New Wikitext Editor: Major improvement to load time and preview time.
In T154843#2957459, @Whatamidoing-WMF wrote:why your experience of performance is so different from other people's.
Jan 28 2017
Jan 28 2017
Holy crap. Wikidata should not be linking to our draft space at all. They definitely should not appear on other language wikis, as public links to a supposed English Language version of the article.
Jan 26 2017
Jan 26 2017
Alsee added a comment to T144730: Publication of the Flow Satisfaction Survey results including an analysis and raw data.
Rather than "assumptions", I'd rather call it a concern. Ensuring a good initial publication is a lot better than (possibly) trying to rewrite history after publication.
Alsee added a comment to T144730: Publication of the Flow Satisfaction Survey results including an analysis and raw data.
I'll illustrate the problem:
Jan 25 2017
Jan 25 2017
Alsee added a comment to T144730: Publication of the Flow Satisfaction Survey results including an analysis and raw data.
@Trizek-WMF thanx for the reply, although I think I failed to properly identify my concern. I fear that you may be unaware of a potential incoming trainwreck.
Jan 23 2017
Jan 23 2017
The RFC on Meta has closed with a clear consensus to remove Flow. Note that this was not an RFC to reduce active Flow pages to zero, this was an RFC for the extension be uninstalled as was done on Enwiki. (T148611)
Alsee added a comment to T144730: Publication of the Flow Satisfaction Survey results including an analysis and raw data.
Four months ago I commented here: The analysis needs to clearly note that invitation and participation were heavily biased towards Flow enthusiasts. (Invitations were selectively posted on the user_talk pages of the small minority who converted their user_talk to Flow.) This should be particularly noted in relation to the question comparing wikitext to Flow.
Jan 9 2017
Jan 9 2017
Alsee added a comment to T154843: New Wikitext Editor: Major improvement to load time and preview time.
@Aklapper if you can get the this new editor load time to be comparable to current editor load times, then sure. That will get this Phab listing closed, and terminate the entire discussion here.
Jan 8 2017
Jan 8 2017
Alsee added a comment to T154844: New Wikitext Editor: Previews should use the article-view rendering engine.
The issue was first raised by me 14 weeks ago half way down this thread on Talk:Wikimedia_Product. That was before any project page or documentation even existed yet. "Whatamidoing, can you please please please go to the head of the New Wikitext Editor project and tell them that a new "Wikitext editor" that doesn't have genuine wikitext support is a deal breaker? It has the same Parasoid-based fake wikitext that Flow has. I suspect there would be a consensus against even having it in Beta-features until that "bug" is fixed. I've already saved a screenshot showing the New Editor botching the preview in nine different ways at once, and it's not hard to show lots more. A new wikitext editor that can't give accurate previews is a non-starter."
Alsee added a comment to T154844: New Wikitext Editor: Previews should use the article-view rendering engine.
To avoid a split discussion, see my Technical Collaboration Guideline comment at T154843#2926550.
Alsee added a comment to T154843: New Wikitext Editor: Major improvement to load time and preview time.
P.S. I forgot to mention the Technical Collaboration Guideline. As an individual, I am proposing this as an Actionable Blocker. I would be more than happy to see the WMF close this as cantfix/wontfix, so long as it will be reopened as a blocker if/when the community formally resubmits it as a consensus blocker issue.
What I mean is that the community wasn't quibbling about the exact quantity of work. If you could wave a magic wand and reduce the labor by 90%, it wouldn't have made a difference. People who opposed it still would have opposed it.
Jan 7 2017
Jan 7 2017
Pppery awarded T154844: New Wikitext Editor: Previews should use the article-view rendering engine a Like token.
Alsee added a comment to T154202: Don't show the welcome message unless it has a "switch to visual editing" button.
@Aklapper I just had it happen again. I was able to get a screenshot this time:
I believe I have avoided a "blame" tone in my list below, but I welcome any attempt to improve tone or clarity.
- Pre-development input: This is an old lesson. Early community input has previously been identified as a key factor in the success or failure of a project. For some reason it is still hard to put this lesson into practice. The Gather project was effectively invisible to the community, up to the point it was announced for deployment. Community input during the concept and design phase could have identified significant issues in advance. The idea could have been re-thought, or cheaply canceled.
- Moderation tools: The community has fairly high expectations that any user-generated content is tracked in contribution history, that all of the usual functionality be available for cleaning it up, and that cleanup actions be logged for accountability. Integrating any new non-wikipage user content into our existing systems is a significant undertaking. It should not be done lightly. The community may (uncomfortably) accept bugs or limitations in theses systems in a limited beta-test. However a project team must be prepared to either roll back the product, or to take responsibility for implementing full tracking&moderation functionality if content is left live for an extended period. This issue was addressed by Risker's checklist for content-creation extensions and T126952: Integrate Risker's checklist for content-creation extensions to the WMF product development process.
- Was the maintenance burden underestimated? (Suggested in comment by @JEumerus.) I think it is important to note that this was NOT a significant focus in community discussions. Yes, there would be a lot to review, and yes AFD style keep/delete debates would be ugly, but the critical community concerns were not the what the WMF expected.
- Nature of the content and nature of the work: The content goes against many community policies, and against the very reason that we volunteer. Editors volunteer their unpaid labor to generate publicly-owned content, as a public service to the world. Even user space pages are considered community owned, they are (loosely) expected to serve our global-good mission. Gather content is viewed as essentially "privately owned" social-network style random junk. Any labor greater than zero is like being an unpaid employee policing Facebook content. The community isn't a free labor force to police John Doe's personal junk, for John Doe's personal benefit. The work might seem similar, but community sees a significant difference.
- Terminating a project must be explicitly in-scope for discussion: This issue lead to communication-breakdown and collaboration-breakdown on multiple levels. There were multiple requests from the community to the WMF for a collaborative process to resolve the issue. These requests were made to the liaison, to the project manager, and even to the executive director. All of those requests received evasive non-responses. (Is there some internal WMF policy or culture against responding to those requests?) Multiple requests were made for the WMF acknowledge that ending the project was in-scope for discussion. All of those requests received evasive non-responses. (Is there some internal WMF policy or culture against responding to those requests?) This issue eroded community trust that the WMF was willing or able to participate in good-faith collaborative resolution. It's hard to discuss fixing a project when the WMF can't acknowledge that ending the project might end up being the most appropriate outcome.
- "Community doesn't like/want a product" needs to be considered valid and important feedback. If the community reasons are unclear or confusing, the actionable-response is to investigate and engage. The WMF shouldn't have missed the huge red flag when the Administrator's Noticeboard announcement turned into outright revolt. The community may have communicated its position poorly. The community tends to cite policy-jargon in its reasons. And in this case the community discussion took an odd turn... the community didn't want to engage in an uphill battle arguing against the project. The community basically said "You can keep your project but you'll have to pay staff to do 100% of the labor". This was basically a sarcastic position. The community did not expect the WMF to pay staff to police the content. The WMF was expected to realize that the project was non-viable without community&admin support. In any case, the WMF should have taken the situation seriously.
- Avoid telling the community not to run an RFC. A number of editors wanted to pursue collaborative-resolution with the WMF. Morale for a collaborative process broke down for a number of reasons. Telling the community not to run an RFC is a sore point. This was a "last straw" that caused the final crumble in morale. At that point the community started the RFC, rather than wait for the WMF to announce its internal decision on Gather.
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL