In T247001#5946511, @matmarex wrote:(Also, this seems like a terrible editing experience in both wikitext and visual mode, and if anyone asked for my opinion, I would suggest never using <section> tags and instead putting the data that must be reused between multiple articles in a template.)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Feb 27 2024
Feb 27 2024
Jack_who_built_the_house awarded T207448: Resetting a custom global preference via API does not work a The World Burns token.
Jan 8 2024
Jan 8 2024
Nux awarded T75714: Update JavaScript syntax checker for gadgets and user-scripts for ES6 and later a Party Time token.
egardner awarded T75714: Update JavaScript syntax checker for gadgets and user-scripts for ES6 and later a Yellow Medal token.
Nov 7 2023
Nov 7 2023
whym awarded T75714: Update JavaScript syntax checker for gadgets and user-scripts for ES6 and later a Piece of Eight token.
Apr 21 2023
Apr 21 2023
Tacsipacsi awarded T213522: Reconsider address bar URL changes done on historical Visual Diff page a Love token.
Apr 16 2023
Apr 16 2023
Jack_who_built_the_house awarded T213522: Reconsider address bar URL changes done on historical Visual Diff page a Party Time token.
Apr 3 2023
Apr 3 2023
stjn awarded T213522: Reconsider address bar URL changes done on historical Visual Diff page a Like token.
Od1n awarded T213522: Reconsider address bar URL changes done on historical Visual Diff page a Like token.
Sep 20 2021
Sep 20 2021
Aug 2 2021
Aug 2 2021
Jan 26 2021
Jan 26 2021
Draceane awarded T108447: File links should be parsed differently from regular wikilinks a Like token.
Dec 13 2020
Dec 13 2020
SlickKilmister awarded T75714: Update JavaScript syntax checker for gadgets and user-scripts for ES6 and later a Pirate Logo token.
Nov 25 2020
Nov 25 2020
AS awarded T75714: Update JavaScript syntax checker for gadgets and user-scripts for ES6 and later a Like token.
Nov 24 2020
Nov 24 2020
Jun 10 2020
Jun 10 2020
Mar 6 2020
Mar 6 2020
Schnark added a comment to T247001: Visual editor breaks labeled sections, invisibly removes line breaks.
Mar 4 2020
Mar 4 2020
• marcella awarded T157956: NWE: Copying tab/newline characters using mouse only (on unixoid systems) doesn't work as expected a Yellow Medal token.
Feb 28 2020
Feb 28 2020
Schnark added a comment to T246434: Firefox: Minor UI glitch in task Subscribers field: Unneeded space at beginning of a line if previous line included CJK characters.
Looks like an issue with floating layout and increased line-height by the CJK characters.
Feb 15 2020
Feb 15 2020
Schnark added a comment to T245274: Real-time indicator that another edit has happened since you began editing.
This has been discussed before, see T137318#2438653 and related pages. As far as I can see and remember, the conclusion was that this needs more research on whether this actually helps users or on the contrary scares them away, and that in a quick prototype 80 % of all users didn't notice the info shown that another user edited the page.
Schnark added a comment to T245328: Disable the {{ (template) sequence when inside a <code> annotation.
Sometimes templates are used inside <code>, see https://en.wikipedia.org/w/index.php?search=insource%3A%2F\%3Ccode\%3E\{\{%2F I think it's easier to just type Ctrl+Shift+6, {, {, Esc in your case then to prevent users from using the template dialog when they really do want to put a template inside code.
Feb 12 2020
Feb 12 2020
Schnark added a comment to T240327: Browser spellchecking broken in VE for words with special characters.
As expected, I'm no longer able to reproduce this issue.
Feb 11 2020
Feb 11 2020
Schnark added a comment to T151671: Find and replace should be able to operate on multiple lines in NWE.
In T151671#5871286, @SUM1 wrote:This means I can't find all spaces that come after new lines, which are the problem in this article. Even if there weren't spaces, I couldn't find all pipes after new lines (like you would see in an infobox, but here they're not appropriate). I also can't replace them.
Feb 6 2020
Feb 6 2020
Schnark added a comment to T243881: en.wikipedia.beta.wmflabs.org not accessible in Firefox, due to something with OCSP.
According to SSL server test it already expired (at Feb 05 09:00:00 UTC 2020), but it seems like Firefox does it's own caching and will accept the OCSP response for a while even after it is expired. Given that it first expired on Jan 09, and issues started only 20+ days later, we probably can hope that the temporary solution works more or less till the end of February.
Feb 4 2020
Feb 4 2020
https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.base/legacy.wikibits.js still includes some more stuff. Especially import{Script|Stylesheet} are "not quite deprecated yet".
Schnark added a comment to T244204: siteinfo api calls should be cached for N minutes on the caching layer.
I see a "time": "<current timestamp>" in the output by siteinfo. I don't know if and how anyone uses that timestamp, but the current time is also available via the curtimestamp parameter with any query (and this is the way suggested by the documentation for action=edit), so after a deprecation period the timestamp in the siteinfo output can probably be safely removed. But it is something to keep in mind when caching the output.
Feb 3 2020
Feb 3 2020
Schnark added a comment to T243881: en.wikipedia.beta.wmflabs.org not accessible in Firefox, due to something with OCSP.
I can confirm that that the beta site now is accessible again, and that images from upload.beta are still missing.
Jan 31 2020
Jan 31 2020
Schnark added a comment to T240327: Browser spellchecking broken in VE for words with special characters.
It says it is fixed in FF 73, which is supposed to be released on February 11, as far as I know. With the current version, the bug is still reproducible.
Jan 29 2020
Jan 29 2020
Jan 27 2020
Jan 27 2020
Schnark added a comment to T243703: Visual Editor should accept pre-formatted references via the Cite tool.
This works for me without any problem, when I paste the copied source in visual mode, the editor accepts it and inserts a new reference, as desired.
Jan 25 2020
Jan 25 2020
Schnark renamed T243606: Inserting a table breaks CodeMirror highlighting in NWE from Firefox: Inserting a table breaks CodeMirror highlighting in NWE to Inserting a table breaks CodeMirror highlighting in NWE.
I can reproduce the same issue in Chromium, so this isn't Firefox specific. The highlight can be fixed by disabling CodeMirror and enabling it again, so it must be something weird that only happens during insertion.
Jan 13 2020
Jan 13 2020
In T239888#5795037, @Ammarpad wrote:I have tried to reproduce this with Firefox but could not; and since apparently no one reported this happening in over a month, I think this bug is invalid.
Jan 9 2020
Jan 9 2020
Schnark added a comment to T242327: QINU appears instead of math in section names in search results.
Given that searching for QINU without math shows up results, too, this probably isn't Math specific: https://de.wikipedia.org/w/index.php?sort=relevance&search=QINU+-postMath&title=Spezial:Suche&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D&ns0=1
Jan 8 2020
Jan 8 2020
Schnark added a comment to T237190: style="overflow:auto" should be applied directly to the <source>.
The idea is to omit the style="overflow:auto", which now doesn't do anything useful.
Jan 3 2020
Jan 3 2020
Schnark added a comment to T154329: NWE and VE should be able to get fully loaded even if the browser tab is not active.
In T154329#5772808, @Pols12 wrote:In T154329#2909581, @Schnark wrote:As far as I understand this actually is caused by MediaWiki-ResourceLoader: It uses requestAnimationFrame to add CSS styles, but using requestAnimationFrame in a background tab can be delayed for a long time. ("The callback rate may be reduced to a lower rate when running in background tabs" MDN) Thus the execution of depending modules may be delayed until you bring that tab into foreground again.
Worst now: MDN indicates “requestAnimationFrame() calls are paused in most browsers when running in background tabs or hidden <iframe>s in order to improve performance and battery life.”. 😢
Dec 30 2019
Dec 30 2019
Dec 20 2019
Dec 20 2019
Schnark added a comment to T241193: Replies with <gallery>...</gallery> tags do not render in preview properly.
You need to add modules to the prop parameter. Then the result will contain something like "modulestyles": ["mediawiki.page.gallery.styles"], which is the module you need to load to get the missing CSS.
Dec 16 2019
Dec 16 2019
Should it be possible to add a short comment to the exceptions? Otherwise, users will ask themselves why they added an exception several years ago and wonder if they still use it. So I think it would make sense to allow adding a short comment like "exception for script foo" along with the exception.
Dec 11 2019
Dec 11 2019
matmarex awarded T229307: Reference numbers wrong in Firefox when following a list a Manufacturing Defect? token.
Schnark added a comment to T240327: Browser spellchecking broken in VE for words with special characters.
Now at https://bugzilla.mozilla.org/show_bug.cgi?id=1602526, so this definitely is a bug in Firefox, not in VE. Do we keep upstream bugs open here until they are fixed?
Schnark added a comment to T240327: Browser spellchecking broken in VE for words with special characters.
I now opened https://bugzilla.mozilla.org/show_bug.cgi?id=1603057
Schnark added a comment to T117279: [EPIC] Core should provide inline diffs as well as side by side (Move InlineDifferenceEngine into core / remove MobileDiff).
My only involvement with VisualDiffs is my user script https://de.wikipedia.org/wiki/Benutzer:Schnark/js/diff which hooks into the UI of VisualDiffs. I don't know who in the VE team currently feels responsible for the diffs, if there is anyone at all.
Dec 11 2019, 8:33 AM · MediaWiki CodeJam Dec 2023, MW-1.42-notes (1.42.0-wmf.1; 2023-10-17), MW-1.41-notes (1.41.0-wmf.29; 2023-10-03), Patch-For-Review, Moderator-Tools-Team, Web-Team-Backlog (Needs Prioritization (Tech)), MW-1.35-notes (1.35.0-wmf.10; 2019-12-10), User-Jdlrobson, TechCom, MobileFrontend (MobileFrontend Special Pages), Multi-Content-Revisions, Technical-Debt (RW-Tech-Debt)
Schnark added a comment to T240327: Browser spellchecking broken in VE for words with special characters.
The DOM has just the plain text (and as far as I can tell there are no invisible format characters, either). The funny thing is: When I copy the affected HTML from VE to another contenteditable page, the spellchecking is broken there, too, even for newly entered text, but only inside the copied list item, not in new ones like it happens in VE.
So this might well be a bug in Firefox, and VE just more easily triggers it than a plain contenteditable. I'll try to investigate further and report it upstream if it turns out that the issue is not in VE.
Dec 10 2019
Dec 10 2019
Schnark added a comment to T117279: [EPIC] Core should provide inline diffs as well as side by side (Move InlineDifferenceEngine into core / remove MobileDiff).
Just to clarify, what I could imagine as UI for diff switching, that would probably work well with VisualDiffs, is this:
Dec 10 2019, 8:11 AM · MediaWiki CodeJam Dec 2023, MW-1.42-notes (1.42.0-wmf.1; 2023-10-17), MW-1.41-notes (1.41.0-wmf.29; 2023-10-03), Patch-For-Review, Moderator-Tools-Team, Web-Team-Backlog (Needs Prioritization (Tech)), MW-1.35-notes (1.35.0-wmf.10; 2019-12-10), User-Jdlrobson, TechCom, MobileFrontend (MobileFrontend Special Pages), Multi-Content-Revisions, Technical-Debt (RW-Tech-Debt)
Dec 9 2019
Dec 9 2019
Schnark added a comment to T117279: [EPIC] Core should provide inline diffs as well as side by side (Move InlineDifferenceEngine into core / remove MobileDiff).
This uses diff-type as URL parameter, while VisualDiff uses diffmode. I think it makes sense to decide on one common interface for different diffs -- both for URL parameters and for UI to switch between different diff styles -- before graduating any of them out of beta.
Dec 9 2019, 9:18 AM · MediaWiki CodeJam Dec 2023, MW-1.42-notes (1.42.0-wmf.1; 2023-10-17), MW-1.41-notes (1.41.0-wmf.29; 2023-10-03), Patch-For-Review, Moderator-Tools-Team, Web-Team-Backlog (Needs Prioritization (Tech)), MW-1.35-notes (1.35.0-wmf.10; 2019-12-10), User-Jdlrobson, TechCom, MobileFrontend (MobileFrontend Special Pages), Multi-Content-Revisions, Technical-Debt (RW-Tech-Debt)
Dec 6 2019
Dec 6 2019
Daimona awarded T75714: Update JavaScript syntax checker for gadgets and user-scripts for ES6 and later a Mountain of Wealth token.
Dec 5 2019
Dec 5 2019
Dec 2 2019
Dec 2 2019
Schnark added a comment to T239550: Copying multiple categories from the bottom of Wikipedia articles and pasting them into source editor (while logged in) breaks all pasting until you switch editors.
This works for me without any issues, both with the HotCat gadget enabled (as seen on the screenshots) and without it.
Nov 23 2019
Nov 23 2019
Schnark added a comment to T238865: [[MediaWiki:Visualeditor-align-desc-center/da]] translation issue.
Link for those who don't have visual diffs enabled: https://test.wikipedia.org/w/index.php?title=User:Matma_Rex/sandbox&diff=409254&oldid=384621&diffmode=visual&visualdiff=1
Nov 15 2019
Nov 15 2019
Schnark added a comment to T153434: Consider using colour/etc. to denote that tabs displayed as arrows / newlines as returns are not the raw Unicode character.
As noted on the merged patch, according to https://caniuse.com/#feat=mdn-css_properties_tab-size Firefox still needs the prefixed property -moz-tab-size.
Nov 11 2019
Nov 11 2019
Schnark added a comment to T237688: Raise MW JS requirement to include ES6 Promise (drop IE11, Safari 5-6, and Android 4.1-4.3).
In T237688#5648031, @Krinkle wrote:In T237688#5647080, @Schnark wrote:Are we already bikeshedding over which polyfill to use? If so, https://github.com/taylorhakes/promise-polyfill is much smaller than https://github.com/stefanpenner/es6-promise.
The size difference is quite significant. Do we know why the other one is so much larger? Is it missing something?
Nov 8 2019
Nov 8 2019
Schnark added a comment to T233649: Stray semicolons in RecentChanges, Watchlist, History and Contributions interface.
Perhaps it is just enough to limit the selector to .mw-changeslist .mw-changeslist-date:before.
Schnark added a comment to T237688: Raise MW JS requirement to include ES6 Promise (drop IE11, Safari 5-6, and Android 4.1-4.3).
Are we already bikeshedding over which polyfill to use? If so, https://github.com/taylorhakes/promise-polyfill is much smaller than https://github.com/stefanpenner/es6-promise.
Schnark updated the task description for T237611: RC: strange format of [sichten] link in recent changes.
Schnark added a comment to T237190: style="overflow:auto" should be applied directly to the <source>.
As far as I understand, the religious fights are mostly about whether pre should allow manual breaks only, or whether browsers may break lines when too long. Since the core CSS already sets white-space: pre-wrap; for pre, .mw-code, this fight is over, and allowing breaks inside words when necessary shouldn't be much controversial.
On the other hand, this means that there should be only very few code blocks that currently overflow anyway. So I can't imagine that this change could have any real influence on any Wikipedia community using or rejecting code examples.
Schnark added a comment to T233649: Stray semicolons in RecentChanges, Watchlist, History and Contributions interface.
In T233649#5646841, @Xaosflux wrote:Instance of multiple extra semicolon/spaces appearing: history view that include a deleted version:
Nov 7 2019
Nov 7 2019
This will be fixed by https://gerrit.wikimedia.org/r/549113, too.
Schnark added a comment to T157956: NWE: Copying tab/newline characters using mouse only (on unixoid systems) doesn't work as expected.
This only fixes pastes inside VE, not into external applications, does it? And these are probably not fixable at all?
Nov 6 2019
Nov 6 2019
Schnark added a comment to T213778: Update link colors in Vector 2022 for improved UX (and consistency).
There are actually more inconsistencies that could and should be addressed:
- External links and interwiki links currently use #36c as color, and #636 when visited. But in edit comments (where only interwiki links may occur) they use the normal link colors instead. This means, currently they are barely distinguishable from internal links, not distinguishable at all in edit comments, and won't be distinguishable after the proposed update, except when visited. I actually don't really see the point in having different colors for them at all (for external links the icon after the link should be enough), so it might be best to remove all those special colors and use the proposed ones for all links. But in any case, the colors for these links really should be addressed here, too.
- Active links (i.e. while you click on them) use #faa700, which has a very poor contrast ratio. Except for external links, which use #b63. (This is also the case for interwiki links, though they have an additional definition with yet another color, but that's overridden a few lines later.) And except for some (but not all) interface links, which don't have a special color. And except for links to missing pages, which don't have a special color for active links, either.
- While we are at it: Links to missing pages use #ba0000, and #a55858 when visited. Except when the missing link is in a vector tab (e.g. link to missing talk page), there always #a55858 is used, even for links not visited.
Nov 6 2019, 9:55 AM · User-notice-archive, MW-1.39-notes (1.39.0-wmf.26; 2022-08-22), Design-System-Team (Design-System-Sprint), Web-Team-Backlog (Kanbanana-2022-23-Q1), Editing-team, DiscussionTools, OWC2020 (OWC2020 Replying 2.0), Desktop Improvements (Vector 2022), UI-Standardization, Vector (legacy skin)
Is this browser depended? I still can reproduce with Firefox. E.g. on https://de.wikipedia.org/wiki/Benutzer:Schnark?veaction=editsource the above code logs 39.
Nov 5 2019
Nov 5 2019
Dvorapa awarded T162337: Document hooks fired by VE via mw.hook a The World Burns token.
Nov 2 2019
Nov 2 2019
Schnark added a comment to T65060: Parsoid should not replace namespace aliases by other translations.
Now I found the recently created and fixed T237040: Visual editor changing automatically something in text while saving. Can we assume that after that change currently no automatic replacement happens, and that this issue can be closed, too, even if the original cause might have been different?
Schnark added a comment to T65060: Parsoid should not replace namespace aliases by other translations.
This happened in dewiki: https://de.wikipedia.org/w/index.php?title=Totengr%C3%A4ber_(K%C3%A4fer)&type=revision&diff=193594417&oldid=191699592
And the funny thing is that some users can reproduce it, and some can't, and sometimes the behaviour just changes. When I tested a few days ago, VE/Parsoid changed every Bild ("Image") to Datei ("File"), but when I tested again today, no such automatic changes occurred, even with the same edits in the same articles.
If I understand https://bugzilla.mozilla.org/show_bug.cgi?id=1592136 correctly, this has been reverted temporarily in FF 70.0.1.
Oct 25 2019
Oct 25 2019
Oct 23 2019
Oct 23 2019
Oct 22 2019
Oct 22 2019
Ladsgroup awarded T219604: Remove unused jquery.ui.* and jquery.effects.* modules a Love token.
This has nothing to do with formatversion=2.
Oct 17 2019
Oct 17 2019
In T218339#5583071, @thiemowmde wrote:As of now, enwiki alone contains more than 200 usages, dewiki about 20.
Oct 16 2019
Oct 16 2019
This looks like T234023, so check your local CSS if there is something like
.mw-collapsible-toggle { text-align: right; }
Schnark added a comment to T233823: Mobile VE edit flow: instrumentation post-deployment data checks.
In T233823#5576379, @DLynch wrote:review-initial-schnark
For that first one, @Schnark is a contributor and may have been doing something with gadgets or userscripts to trigger that.
Oct 15 2019
Oct 15 2019
https://www.mediawiki.org/wiki/ResourceLoader/Core_modules#user.options states: "This module is loaded asynchronously and may depend on a separate HTTP request for the user.defaults module. Always declare the relevant dependencies for your module, or use mw.loader.using()." Assuming this is still true and won't be changed, setting the state of user.options to ready immediately might break scripts.
Oct 14 2019
Oct 14 2019
As far as I can see, the gray is the default background color for buttons, so depending on browser and OS the issue might not be visible. But for me this happens both with Firefox, Chromium, and Konqueror on Linux.
Oct 12 2019
Oct 12 2019
Oh, and I just want to say that I admire the magic with perfectly chosen default values that makes the parser even correctly detect signatures by users that only link to their talk page and sign on that talk page. Even though this doesn't generate a real link, the parser works as expected.
Oct 11 2019
Oct 11 2019
editToken has been deprecated for years and removed recently. See T234576 and use csrfToken instead.
I think this is T55368: Several issues with templated list items.
Oct 10 2019
Oct 10 2019
- I see that there is code for local timezone abbreviations, but it doesn't seem to work: On https://de.wiktionary.org/wiki/Wiktionary:Auskunft (and other pages on de.wikt), which uses MEZ and MESZ instead of CET and CEST, no signatures are found.
- Even minor variations in the timestamp format make the parser fail, e.g. deleting a leading 0 in the hour, missing period after abbreviated month, etc. These variations sometimes happen when a missing or wrong signature is fixed manually afterwords, and for old comments (seems like back in 2006 the format was a little different, which of course isn't a real problem, but probably means the parser will break when the timestamp format is changed again).
- When the name of the user comes after the timestamp, the parser doesn't find it (uncommon, happens mostly when you accidentally click twice to insert 8 tildes instead of 4, https://de.wikipedia.org/wiki/Diskussion:Stra%C3%9Fenbahn_Berlin#Pl%C3%A4ne_f%C3%BCr_Neubaustrecken)
- It's not clear what will happen when a comment has 2 timestamps (E.g. "See my previous comment on <old timestamp> --User <new timestamp>", or "Comment -- User <first timestamp>, modified <second timestamp>"), or even 2 signatures.
Oct 9 2019
Oct 9 2019
According to T226148: Remove `tabindex="1"` from #simpleSearch this was intentional.
Oct 4 2019
Oct 4 2019
Depending on what exactly the requirements are, you probably want to have a look at includes/DiscussionParser.php from Echo (and perhaps old versions of that code to see what alternatives there are and why they don't work).
Sep 28 2019
Sep 28 2019
Is the dependency on jquery.tabIndex used anywhere else? If not, this can be removed, too.
Sep 27 2019
Sep 27 2019
Schnark added a comment to T234023: Page history filter dropdown on several wiki shows truncated "Expand" label string; "Filter revisions" string on other side (due to local MediaWiki:Common.css).
This is caused by local CSS:
.mw-collapsible-toggle { text-align: right; }
Sep 17 2019
Sep 17 2019
BTW, this doesn't happen for $overlay: true (and the code where I used the body as overlay predates the default overlay), so there is an easy workaround.
Sep 14 2019
Sep 14 2019
I have a script for autocomplete suggestions (not for @user, but for words already in the text): https://de.wikipedia.org/wiki/Benutzer:Schnark/js/veSuggestions.js
(German) documentation (including screenshot) is on https://de.wikipedia.org/wiki/Benutzer:Schnark/js/veSuggestions
If you want to reuse any code from there, feel free to do so.
Sep 9 2019
Sep 9 2019
With a PHP port of babel.js (or some wrapper) this should be possible in theory, but:
Aug 23 2019
Aug 23 2019
In T231031#5432337, @Esanders wrote:what sort of things they scan (presumably: 99.9% books, but let's confirm that)
The tool only reads ISBNs, which stands for International Standard Book Number[0], so...
Aug 20 2019
Aug 20 2019
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