Page MenuHomePhabricator

stjn
Interface admin in Russian Wikipedia

Projects

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Thursday

  • Clear sailing ahead.

User Details

User Since
Oct 7 2014, 2:35 PM (497 w, 55 m)
Availability
Available
IRC Nick
stjn
LDAP User
Saint Johann
MediaWiki User
Stjn [ Global Accounts ]

Recent Activity

Yesterday

stjn added a comment to T185674: Add a 'mw-collapsible-header' class to 'mw-collapsible' scheme.

Interesting. Updated https://ru.wikipedia.org/wiki/Шаблон:Оригинальный_текст to use it, seems to function as intended. I guess this covers all the cases then.

Mon, Apr 15, 8:09 PM · MediaWiki-User-Interface (collapsible elements), JavaScript
stjn added a comment to T361671: Large ext.flaggedRevs.advanced module is loaded for anonymous users.

Another option for ruWP might be to turn on the ‘basic’ experience by default since we don't seem to show the ‘advanced’ version to IP users and I would argue ‘advanced’ option is pretty, for the lack of the technical term, shit for everyone else as well. That whole interface really needs a redesign, but in the case of Russian Wikipedia, I think switching it off might be a proper solution as well.

Mon, Apr 15, 7:30 PM · Performance Issue, MediaWiki-extensions-FlaggedRevs
stjn created T362561: jquery.makeCollapsible functions incorrectly when re-used in other scripts.
Mon, Apr 15, 4:52 PM · Patch-For-Review, Reference Previews, MediaWiki-User-Interface (active libraries)
stjn updated subscribers of T351912: Button semantics in Phonos should be added via JS.

From my own lookup of what causes this, this seems to be caused by the following code in OOUI itself:
https://gerrit.wikimedia.org/g/oojs/ui/+/8e4947086a62a6516df6f2eb125a02d440ebb94b/php/mixins/ButtonElement.php#44

Mon, Apr 15, 4:45 PM · Language-Team, Community-Tech, Accessibility, MediaWiki-extensions-Phonos
stjn added a comment to T362125: Translate extension edit notices should be displayed in visual editor.

‘At least as visibly as in the wikitext editor’, or... not so much :-) I don’t see why the deficiencies of Translate extension in that department should preclude from fixing this task.

Mon, Apr 15, 2:03 PM · MW-1.43-notes (1.43.0-wmf.2; 2024-04-23), Unplanned-Sprint-Work, Language-Team (Language-2024-April-June), Patch-For-Review, VisualEditor, MediaWiki-extensions-Translate

Sun, Apr 14

stjn updated the task description for T362496: ‘Start a discussion’ affordance should also be on existing talk pages that have no discussions.
Sun, Apr 14, 9:14 PM · Regression, DiscussionTools
stjn created T362496: ‘Start a discussion’ affordance should also be on existing talk pages that have no discussions.
Sun, Apr 14, 9:10 PM · Regression, DiscussionTools

Fri, Apr 12

stjn created T362440: Set wgContentTranslationPublishRequirements for Russian Wikipedia.
Fri, Apr 12, 7:52 PM · Patch-For-Review, Russian-Sites, Wikimedia-Site-requests, ContentTranslation

Thu, Apr 11

stjn awarded T362356: Make WikiEditor officially support use outside action=edit pages a Like token.
Thu, Apr 11, 8:23 PM · Editing-team, WikiEditor

Wed, Apr 10

stjn added a comment to T356949: Field: Consider moving errors and hints above the input.

Another argument in favour of putting everything above the input (with an example that is valid for Wikipedia, ‘Stjn’ is not required to be here, it can also just be ‘Manage passwords’ on its own):

image.png (672×387 px, 61 KB)

Wed, Apr 10, 8:49 PM · Design-System-Team, Accessibility, Codex

Tue, Apr 9

stjn added a comment to T362125: Translate extension edit notices should be displayed in visual editor.

Regarding !!FUZZY!!, I think this is a more general issue with Translate extension. See for example this edit: https://translatewiki.net/?diff=12345686 — I think !!FUZZY!! was there at some point and I only ended up seeing it because I went into source code mode afterwards to edit yet again, but nothing was shown upon saving. There might be some other cases where that’s true.

Tue, Apr 9, 6:26 PM · MW-1.43-notes (1.43.0-wmf.2; 2024-04-23), Unplanned-Sprint-Work, Language-Team (Language-2024-April-June), Patch-For-Review, VisualEditor, MediaWiki-extensions-Translate
stjn added a comment to T362125: Translate extension edit notices should be displayed in visual editor.

Is there any way to differentiate page-wide translations like MediaWiki translations from these translation units translations? Because making Translate extension compatible can be limited to page-wide translations then so there’s less confusing code.

Tue, Apr 9, 6:17 PM · MW-1.43-notes (1.43.0-wmf.2; 2024-04-23), Unplanned-Sprint-Work, Language-Team (Language-2024-April-June), Patch-For-Review, VisualEditor, MediaWiki-extensions-Translate
stjn edited projects for T272297: User script on user subpage doesn't work after user rename, added: Security-Team; removed SecTeam-Processed.

This continuously causes issues with user scripts after any rename, I am asking someone from Security-Team to take time to review the patch provided.

Tue, Apr 9, 12:52 PM · SecTeam-Processed, Security-Team, Patch-For-Review, MediaWiki-extensions-CentralAuth, JavaScript, MediaWiki-User-rename, MediaWiki-General, Vuln-DoS
stjn added a comment to T362125: Translate extension edit notices should be displayed in visual editor.

Why do I have visual editor buttons on translatewiki.net in those namespaces then? (And what would be the problem with keeping it?)

Tue, Apr 9, 12:20 PM · MW-1.43-notes (1.43.0-wmf.2; 2024-04-23), Unplanned-Sprint-Work, Language-Team (Language-2024-April-June), Patch-For-Review, VisualEditor, MediaWiki-extensions-Translate

Mon, Apr 8

stjn added a comment to T273635: Check if it is possible to import machine translated strings to translatewiki.net.

This task should really be declined. Most languages do not have machine translations that are well-translated in comparison to original, especially with technical terms, especially in such a narrow field like Wiki(p/m)edia. Trying to engineer a solution that would at any point involve machine translation in interface messages is just plain wrong. In Russian we are frequently having to remove the results of low-effort machine translations from people who simply press some buttons to translate without knowing both languages full well. WMF should not contribute to this. If you want your tools to be translated to different languages, pay Wikimedians to translate them.

Mon, Apr 8, 11:32 PM · Growth-Team-Filtering, Growth-Team, translatewiki.net, Growth-Scaling
stjn updated the task description for T362125: Translate extension edit notices should be displayed in visual editor.
Mon, Apr 8, 11:21 PM · MW-1.43-notes (1.43.0-wmf.2; 2024-04-23), Unplanned-Sprint-Work, Language-Team (Language-2024-April-June), Patch-For-Review, VisualEditor, MediaWiki-extensions-Translate
stjn updated the task description for T362125: Translate extension edit notices should be displayed in visual editor.
Mon, Apr 8, 11:20 PM · MW-1.43-notes (1.43.0-wmf.2; 2024-04-23), Unplanned-Sprint-Work, Language-Team (Language-2024-April-June), Patch-For-Review, VisualEditor, MediaWiki-extensions-Translate
stjn created T362125: Translate extension edit notices should be displayed in visual editor.
Mon, Apr 8, 11:19 PM · MW-1.43-notes (1.43.0-wmf.2; 2024-04-23), Unplanned-Sprint-Work, Language-Team (Language-2024-April-June), Patch-For-Review, VisualEditor, MediaWiki-extensions-Translate

Sun, Apr 7

stjn added a comment to T361940: Imports, moves and protections are not autoreviewed.

Doing this will address the problem for everyone regarding that issue: T359529#9684005

This is a massive change in how autoreview was handled though, if intended. Having one or multiple unreviewed templates on a page shouldn’t lead to requiring to review every single edit on a page.

Sun, Apr 7, 7:46 PM · User-notice, Regression, MediaWiki-extensions-FlaggedRevs

Sat, Apr 6

stjn added a comment to T362010: FlaggedRevs: page moves don't get autoreviewed.

@Zache please comment the same on the other task since this one was closed as a duplicate of T361940: Imports, moves and protections are not autoreviewed

Sat, Apr 6, 6:19 PM · Russian-Sites, Regression, MediaWiki-extensions-FlaggedRevs
stjn added projects to T362010: FlaggedRevs: page moves don't get autoreviewed: Regression, Russian-Sites.
Sat, Apr 6, 5:52 PM · Russian-Sites, Regression, MediaWiki-extensions-FlaggedRevs

Fri, Apr 5

stjn added a comment to T361934: Support CSS variable fallbacks in template styles.

EDIT: actually I think I misunderstood the meaning of "guaranteed invalid" in the spec (https://www.w3.org/TR/css-variables-1/#invalid-variables) and the inheritance won't actually work the way I expected it would. Can someone else double-check my logic and figure out whether this can be done in another way without requiring more custom-property syntax?

Copying the comment: unless you hard-code something to switch it to var( --skin-specific, #fff ), this example would lead to override of #fff to an empty value in all the browsers supporting var() in case --skin-specific is undefined.

Fri, Apr 5, 1:25 PM · Web-Team-Backlog (FY2023-24 Q4 Sprint 1), Patch-For-Review, css-sanitizer, TemplateStyles, FY2023-24-WE 2.1 Typography and palette customizations
stjn added a comment to T360562: CSS sanitizer should support using CSS variables (not setting/creating them) for use in color values in TemplateStyles.

@Mabualruz unless you hard-code something to switch it to var( --skin-specific, #fff ), this example would lead to override of #fff to an empty value in all the browsers supporting var().

Fri, Apr 5, 12:59 PM · MW-1.42-notes (1.42.0-wmf.26; 2024-04-09), Patch-For-Review, FY2023-24-WE 2.1 Typography and palette customizations, TemplateStyles, css-sanitizer, Web-Team-Backlog (FY2023-24 Q3 Sprint 6)

Thu, Apr 4

stjn added a comment to T361767: Don't use padding-bottom for paragraphs.

I had to fix margins yesterday on the main page of Russian Wikipedia because I opened it in new Vector and it had a bunch of spacing problems because of the paddings. I think having only margins to space elements is a reasonable expectation in newer skins (Monobook also has paddings, but, hey) that was broken by the changes described in the task.

Thu, Apr 4, 11:20 AM · Web-Team-Backlog, FY2023-24-WE 2.1 Typography and palette customizations, Desktop Improvements (Vector 2022)

Wed, Apr 3

stjn added a comment to T239609: The N'Ko language cannot be looked up by its English name in the languages search box on Mobile web.

By going to https://en.m.wikipedia.org/wiki/Martin_Luther_King_Jr.#/languages I get this:

image.png (800×600 px, 14 KB)
image.png (800×600 px, 25 KB)

Wed, Apr 3, 9:58 PM · good first task, patch-welcome, Web-Team-Backlog, MobileFrontend
stjn added a comment to T357706: [config] Disable limited width on the home page and associated history page.

Fixing this would also fix T309489: Main Page history is not full width

Wed, Apr 3, 9:50 PM · Web-Team-Backlog (FY2023-24 Q4 Sprint 1), FY2023-24-WE 2.1 Typography and palette customizations
stjn added a comment to T361407: Add short-to-type aliases for <syntaxhighlight> and <syntaxhighlight inline>.

Somewhat of an opinion that <pre lang=""> and <code lang=""> should just function as synonyms to <syntaxhighlight> if the extension is installed. Or something similar to them (language or hlang to differ from HTML lang?). Yes, it is not ‘correct HTML’, but so what? As long as wikitext doesn’t insert the attribute into HTML, we’re fine, I’d say. And <syntaxhighlight> without any lang should be considered an error. (<source> to me is bad since it doesn’t say anything about what the tag does, even if it is less verbose.)

Wed, Apr 3, 12:40 AM · Patch-For-Review, SyntaxHighlight
stjn added a comment to T340705: [performance budgeting] Improve JS payload for projects with gadgets that lead to a 30%+ increase after gzip.

The last note is the result of T282999: Enable Reference Previews on all wikis using the Popups extension, on Nov 21 to which you are privy. We never asked to have ext.cite.referencePreviews enabled, it was done without the community opt-in on an explicit promise that it should not add JS when the project doesn’t want to use it.

Wed, Apr 3, 12:15 AM · Bengali-Sites, Local-Wiki-Template-And-Gadget-Issues, Web-Team-Backlog (Needs Prioritization (Tech))

Tue, Apr 2

stjn added a comment to T345960: Architecture: We should track size of default gadgets loaded on site and present this to users.

It's already a thing for WMF developers: https://phabricator.wikimedia.org/T360590

Are there any metrics showing what contributes the most to the JS payload? I tried to look into that issue in Russian Wikipedia as a result of the T340705: [performance budgeting] Improve JS payload for projects with gadgets that lead to a 30%+ increase after gzip task, but we ended up with an impression that default gadgets contribute far less into the JS size than the default modules did.

Tue, Apr 2, 1:30 PM · MediaWiki-extensions-Gadgets
stjn added a comment to T345960: Architecture: We should track size of default gadgets loaded on site and present this to users.

Small comment: if this becomes a thing, this should also become a thing for WMF developers, since (from the looks of it for me) most of the JS payload on Wikimedia websites comes not from gadgets, but from various default JS modules loaded without any possibility to opt-out. Focusing on gadgets then becomes trying to push the blame onto the gadget developers even though they are not the main contributors to JS payload.

Tue, Apr 2, 1:16 PM · MediaWiki-extensions-Gadgets
stjn added a comment to T358071: [GOAL] Move template override styles from Minerva to WikimediaMessages and allow site editors more control.

See for example in https://en.m.wikipedia.org/?oldid=1215029134

Tue, Apr 2, 1:03 PM · Web-Team-Backlog (Needs Prioritization (Tech)), FY2023-24-WE 2.1 Typography and palette customizations, Patch-For-Review, MinervaNeue, WikimediaMessages

Thu, Mar 28

stjn updated the task description for T361299: Blockquote styles look off in Minerva.
Thu, Mar 28, 8:24 PM · Web-Team-Backlog, MinervaNeue
stjn created T361299: Blockquote styles look off in Minerva.
Thu, Mar 28, 8:18 PM · Web-Team-Backlog, MinervaNeue

Wed, Mar 27

stjn added a comment to T360847: Add uploader user group to az.wiki.

Keep in mind btw that since T280531: Enable partial action blocks on all Wikimedia production wikis and in MediaWiki by default local sysops already can block users from (re)uploading files and that doesn’t require having a user group (via https://www.mediawiki.org/wiki/Anti-Harassment_Tools/Action_Blocks). I see that the proposal removes autopromotion entirely, but just want to make sure that the decision-makers in the community are aware of this opportunity.

Wed, Mar 27, 3:42 PM · Patch-For-Review, Wikimedia-Site-requests
stjn added a comment to T343081: Template:Imagestacks on Commons broken.

See https://www.mediawiki.org/wiki/Figure_migration / T314318: Disable wgParserEnableLegacyMediaDOM on all wikis

Wed, Mar 27, 9:28 AM · Commons
stjn closed T343081: Template:Imagestacks on Commons broken as Resolved.

Changed by MusikAnimal after my request.

Wed, Mar 27, 2:01 AM · Commons

Tue, Mar 26

stjn added a comment to T204201: Extend MediaWiki:Gadgets-definition capabilities.

(I would like to amend the previous comment: I too consider the patch and the merge good for the project, I just think that given the constraints of the current system there should’ve been some amendment that would make possible to use category names with commas in them.)

Tue, Mar 26, 11:40 PM · MediaWiki-extensions-Gadgets
stjn added a comment to T359894: Module:Citation introduces accessibility issue (cs1-visible-error).

This is how it was until T280766. That was enough writing on the wall to ditch the name.

Oof. Maybe if Jdlrobson pinky-promises to not touch that class again, you can use error with cs1-specific class?

Tue, Mar 26, 10:31 PM · FY2023-24-WE 2.1 Typography and palette customizations, Local-Wiki-Template-And-Gadget-Issues
stjn added a comment to T204201: Extend MediaWiki:Gadgets-definition capabilities.

There is no specific template adding a category, it is added via heuristics. So no, it still requires a gadget while Lua support for categories is not there.

Tue, Mar 26, 9:43 PM · MediaWiki-extensions-Gadgets
stjn added a comment to T359894: Module:Citation introduces accessibility issue (cs1-visible-error).

Another alternative is for .cs1-visible-error to implement itself via standard error class while resetting some of its properties.

Tue, Mar 26, 9:28 PM · FY2023-24-WE 2.1 Typography and palette customizations, Local-Wiki-Template-And-Gadget-Issues
stjn added a comment to T320322: Support CSS variables in TemplateStyles.

Encountered another instance where setting a variable on the class level would be beneficial to simpler CSS writing:
https://ru.wikipedia.org/?diff=136900868

Tue, Mar 26, 9:22 PM · Web-Team-Backlog, Design-System-Team, FY2023-24-WE 2.1 Typography and palette customizations, css-sanitizer, TemplateStyles
stjn added a comment to T204201: Extend MediaWiki:Gadgets-definition capabilities.

Other options would rarely contain categories, but this option is very likely to do so in many languages. I think making this change without considering this was bad.

Tue, Mar 26, 9:02 PM · MediaWiki-extensions-Gadgets
stjn updated subscribers of T204201: Extend MediaWiki:Gadgets-definition capabilities.

@Sophivorus @Krinkle can you clarify how this new |categories= syntax can be used with languages that can have comma in category names?.. Currently from looking at the code I see no way to do so, but category names like https://ru.wikipedia.org/wiki/Категория:Персоналии,_умершие_менее_года_назад are entirely correctly named in Russian.

Tue, Mar 26, 7:25 PM · MediaWiki-extensions-Gadgets

Mon, Mar 25

stjn added a comment to T248416: [EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles and MediaWiki:Minerva.css.

…and if I do so, I expect it to work the same way as Minerva on mobile.

That’s not how it currently functions though. You get Minerva without MobileFrontend hacks, not the mobile website.

Mon, Mar 25, 9:47 PM · Web-Team-Backlog (Needs Prioritization (Tech)), MobileFrontend, Epic, User-Jdlrobson

Sat, Mar 23

stjn created T360843: No tag styling in Minerva in Special:NewPages.
Sat, Mar 23, 5:03 PM · Patch-For-Review, Web-Team-Backlog (Needs Prioritization (Tech)), MinervaNeue
stjn added a comment to T358071: [GOAL] Move template override styles from Minerva to WikimediaMessages and allow site editors more control.

Would be great to develop https://ru.wikipedia.org/wiki/Template:Ambox styling that doesn’t look bad and works with the current MobileFrontend hacks in some manner. https://en.wikipedia.org/wiki/Module:Message_box/ambox.css looks very ugly and hacky, especially with ‘Page issues’ menu added in. (This is the last blocker to TemplateStyles conversion of these templates I am currently doing in Russian Wikipedia.)

Sat, Mar 23, 4:15 PM · Web-Team-Backlog (Needs Prioritization (Tech)), FY2023-24-WE 2.1 Typography and palette customizations, Patch-For-Review, MinervaNeue, WikimediaMessages
stjn created T360834: Keyboard shortcuts stop working with MediaViewer after opening share/download popups.
Sat, Mar 23, 1:37 AM · Browser-Support-Firefox, MediaViewer

Fri, Mar 22

stjn added a comment to T360387: Remove styles in hacks.less that no longer apply.

Col-begin still appears to use multicol for columns? (It's another on the list of things to change, but I haven't jumped at this one because there's a lot of articles that could be affected by any div-i-fication.)

Could be easily rewritten into TemplateStyles like https://ru.wikipedia.org/wiki/Шаблон:Столбцы/styles.css

Fri, Mar 22, 11:49 PM · Verified, MW-1.42-notes (1.42.0-wmf.25; 2024-04-02), Patch-For-Review, Web-Team-Backlog (FY2023-24 Q3 Sprint 6), FY2023-24-WE 2.1 Typography and palette customizations, MinervaNeue

Thu, Mar 21

stjn added a comment to T360562: CSS sanitizer should support using CSS variables (not setting/creating them) for use in color values in TemplateStyles.

Btw, keep in mind that CSS variables can have a fallback like var( --color-base, #000 ), maybe that is a good thing to advise in the variable use so that dropping a certain token doesn’t cause too many problems.

Thu, Mar 21, 11:56 PM · MW-1.42-notes (1.42.0-wmf.26; 2024-04-09), Patch-For-Review, FY2023-24-WE 2.1 Typography and palette customizations, TemplateStyles, css-sanitizer, Web-Team-Backlog (FY2023-24 Q3 Sprint 6)
stjn reopened T320322: Support CSS variables in TemplateStyles as "Open".

@CCiufo-WMF this task’s scope is different from that task’s scope.

Thu, Mar 21, 10:02 PM · Web-Team-Backlog, Design-System-Team, FY2023-24-WE 2.1 Typography and palette customizations, css-sanitizer, TemplateStyles
stjn reopened T320322: Support CSS variables in TemplateStyles, a subtask of T355244: Support Codex design tokens in TemplateStyles, as Open.
Thu, Mar 21, 10:00 PM · Design-System-Team, Codex, TemplateStyles
stjn awarded T344835: Activity pane on front page no longer shows New Tasks by default after Phorge migration a Like token.
Thu, Mar 21, 4:33 PM · Patch-For-Review, Upstream, Phabricator (Upstream)

Tue, Mar 19

stjn added a comment to T359529: Future of flaggedtemplates feature.

One other thing I thought of: this would make it so the main pages can no longer expect that the templates included on them would be from stable version. Which might complicate some things in the community side. I agree, I guess, that the impact on the stabilised pages (I am not sure why you keep calling them protect mode?) is less pronounced since it’s not like the big templates on those pages are unprotected. It might be an interesting alternative to limit this feature to pages not protected to a certain level (to help the issue with the main pages), but that might be a bit complicated.

Tue, Mar 19, 7:05 PM · Patch-For-Review, MediaWiki-extensions-FlaggedRevs

Mon, Mar 18

stjn added a comment to T320322: Support CSS variables in TemplateStyles.

To be more precise, if you have var( --wikipedia-color-infobox-bg ) and it gets overridden on template level to some other value, that could affect things outside the template scope, yes. But so can just putting .infobox { background: #dcc } in TemplateStyles, no? That’s not really fundamentally different things. And the nesting behaviour you describe is already possible via .template .infobox { background: #dcc } without CSS variable use. So TS already has those kinds of scoping complications.

Mon, Mar 18, 6:39 PM · Web-Team-Backlog, Design-System-Team, FY2023-24-WE 2.1 Typography and palette customizations, css-sanitizer, TemplateStyles
stjn added a comment to T322482: TemplateStyles does not allow logical CSS properties.

This requires updating upstream component css-sanitiser with the new logical property values. This should be relatively simple.

The whole of css-sanitzer could really do with an update, but its quite a bit of manual labor to go through all the specs and make sure everything is up to date (I started once, but calculated that going through all the specs and checking everything is up to date would take me some 20+ hours. And that is just for updating property names and values, not introducing new units or other more invasive spec changes.

As I’ve described previously in T162379#4173054, using Autoprefixer can maybe speed it up the list generation if one would leverage it correctly.

Mon, Mar 18, 6:33 PM · I18n, css-sanitizer, Vertical-Writing, TemplateStyles
stjn added a comment to T320322: Support CSS variables in TemplateStyles.

As long as defining CSS variables is scoped to .mw-parser-output children as everything else, is there a problem with it if we would allow to use them? (other than sanitisation, but that one seems potentially solvable by code reuse)

Mon, Mar 18, 6:28 PM · Web-Team-Backlog, Design-System-Team, FY2023-24-WE 2.1 Typography and palette customizations, css-sanitizer, TemplateStyles
stjn added a comment to T354577: Create Mediawiki "oversightprotect" action that suppresses usernames of all edits of a page.

(Per the list in Russian Wikipedia, in more than a thousand pages. A code-based solution would be better at protecting privacy at such a number of pages at large, and would make it easier to revert this action when the political situation in Russia/Belarus changes.)

Mon, Mar 18, 6:15 PM · MediaWiki-Revision-deletion, MediaWiki-Page-protection, User-DannyS712, Privacy Engineering, Data-Engineering, Security, Event-Platform, EventStreams
stjn reopened T222883: Create a MW-wide class for screen reader-only content as "Open".

Respectfully, @Volker_E, I don’t think you’ve read the task correctly. I know a mixin is a thing, I am saying that the end-users of Wikimedia projects should have access to the same mixin via an agreed class name since that would improve accessibility and re-usability of code across projects. Currently this sort of thing gets copied across wikis on an ad-hoc basis, whereas it would be better to create a centrally managed utility class.

Mon, Mar 18, 6:14 PM · MediaWiki-General, CSS, Accessibility
stjn added projects to T222883: Create a MW-wide class for screen reader-only content: Codex, UI-Standardization.

Seems like something of an interest for Codex efforts as well, since it could provide an increased use of accessibility text in the projects, which is a net benefit for UI standardisation.

Mon, Mar 18, 1:47 PM · MediaWiki-General, CSS, Accessibility

Sun, Mar 17

stjn created T360276: Post-edit notification is illegible in Minerva skin.
Sun, Mar 17, 11:26 PM · MediaWiki-User-Interface (actions), MinervaNeue (Tracking), Accessibility, MediaWiki-Page-editing
stjn added a project to T360268: Unclosed decorative div tags on talk pages causing problems with rendering on mobile: DiscussionTools.
Sun, Mar 17, 7:32 PM · DiscussionTools, MobileFrontend

Mar 16 2024

stjn added a comment to T334940: All Graphs broken on Wikimedia wikis (due to security issue T336556).

Saying T211881#9425243 here again: The last (before archival) version of graphoid is prone to RCE due to CVE-2020-26296. For a POC, see https://github.com/vega/vega/issues/3018#issuecomment-748929438

I wasn’t strictly talking about making Graphoid available again, I was talking about providing a sandboxed generator of Graphoid-like images. Maybe I am missing something, but I can’t see this being impossible in the same way that container version of Lilypond is able to be used.

Mar 16 2024, 2:44 PM · User-zeljkofilipin, Regression, User-notice, Tech Ambassadors & Translators, MediaWiki-extensions-Graph
stjn added a comment to T359143: Signatures containing score are not recognized by DiscussionTools.

Shouldn’t have there been a follow-up that made these signatures illegal in the current signature parser? Because right now <math display="block"> is saveable into the prefs, and I’m sure <score> is too.

Mar 16 2024, 2:42 PM · DiscussionTools, MediaWiki-extensions-Score
stjn renamed T248416: [EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles and MediaWiki:Minerva.css from [EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles and MediaWiki:inerva.css to [EPIC] Drop MediaWiki:Mobile.css and MediaWiki:Mobile.js in favor of TemplateStyles and MediaWiki:Minerva.css.
Mar 16 2024, 12:09 PM · Web-Team-Backlog (Needs Prioritization (Tech)), MobileFrontend, Epic, User-Jdlrobson

Mar 12 2024

stjn added a comment to T359765: fullurl: works incorrectly if the page name has a semi-colon.

That’s quite long ago. 🙁 I wish it would be fixed (by using URL escapes), but who knows how many templates were built around this buggy behaviour in the past thirteen years…

Ehh. Not sure this should be a justification for keeping the bug in, though. If someone used this buggy behaviour in their templates, let them fix those templates. Should be simple (with wikitext or Lua).

Mar 12 2024, 8:13 PM · MediaWiki-extensions-FlaggedRevs, MediaWiki-Parser

Mar 11 2024

stjn added a comment to T359529: Future of flaggedtemplates feature.

What you're referring is called "protect mode" (i.e. you protect some pages to be reviewed) and that's actually can't be enabled with flaggedtemplates feature at the same time. Protect mode disables a lot of FR features. At least that's my understanding of the code.

If I understand correctly, we are talking about the feature that makes the top-page notice ‘This page has unreviewed templates or files: …’, right? Then the above I am not describing the protect mode, I am describing stabilisation. Protect mode is enWP-only (mostly) thing, other wikis usually do not use FR in the same way. If I am correct about this being related to that top-page notice, it works with any transclusions, but non-FR-ed namespaces (not modules) do not work correctly with it.

Mar 11 2024, 11:43 AM · Patch-For-Review, MediaWiki-extensions-FlaggedRevs

Mar 10 2024

stjn added a project to T359765: fullurl: works incorrectly if the page name has a semi-colon: MediaWiki-extensions-FlaggedRevs.
Mar 10 2024, 1:06 PM · MediaWiki-extensions-FlaggedRevs, MediaWiki-Parser
stjn updated the task description for T359765: fullurl: works incorrectly if the page name has a semi-colon.
Mar 10 2024, 1:05 PM · MediaWiki-extensions-FlaggedRevs, MediaWiki-Parser
stjn renamed T359765: fullurl: works incorrectly if the page name has a semi-colon from fullurl: works incorrectly if the page name has ; to fullurl: works incorrectly if the page name has a semi-colon.
Mar 10 2024, 12:36 PM · MediaWiki-extensions-FlaggedRevs, MediaWiki-Parser
stjn edited projects for T359765: fullurl: works incorrectly if the page name has a semi-colon, added: MediaWiki-Parser; removed MediaWiki-extensions-FlaggedRevs.
Mar 10 2024, 12:35 PM · MediaWiki-extensions-FlaggedRevs, MediaWiki-Parser
stjn renamed T359765: fullurl: works incorrectly if the page name has a semi-colon from Aporoved version system message broken to fullurl: works incorrectly if the page name has ;.
Mar 10 2024, 12:35 PM · MediaWiki-extensions-FlaggedRevs, MediaWiki-Parser

Mar 8 2024

stjn added a comment to T358948: Avoid text truncation where possible in OOUI/Codex.

It is strange to me to close the older task as a duplcate of the newer one, but alright.

Mar 8 2024, 6:38 PM · Design-System-Team, Codex, VisualEditor, OOUI
stjn added a comment to T13555: .mw-editsection links should not be part of the <h#> element.

I'm sorry that this caused work for you. It seems that nothing else was affected and no one else seems to have noticed, so I'm going to leave it like that, until we're ready to change the entire markup.

That’s not true: I had to make a comment here after this being a problem for different people for three times. Autogenerated summaries got affected even if you don’t use CD, and some user scripts and gadgets also were broken by this (see https://ru.wikipedia.org/wiki/Обсуждение_Википедии:Гаджеты/Гаджет_проекта_«Добротные_статьи»#Гаджет_добавляет_слово_"подписаться"_в_список_ДС.).

Mar 8 2024, 6:31 PM · MW-1.42-notes (1.42.0-wmf.23; 2024-03-19), User-notice, Patch-For-Review, Editing-team (Kanban Board), Web-Team-Backlog (Needs Prioritization (Tech)), Technical-Debt, Epic, Accessibility, MediaWiki-Parser
stjn added a comment to T359529: Future of flaggedtemplates feature.

So. The benefit of this feature being present is that the template editors are not necessarily tied too much by ‘template stability requirements’ since MediaWiki would show the previous version of the same template if really needed. The bot run can happen replacing one code with another for whatever reason, and in stabilised articles, it wouldn’t be a problem if the page was unreviewed for a while. The removal of this feature would affect the projects where FlaggedRevs is in ‘stable by default’ mode the most, but at the same time, those projects might have less of a backlog. In the case of ‘stable by default in some articles but not all’ setup, it would definitely affect the stabilised pages, potentially leading to some wrong results from a template change that wasn’t reflected in the stable version of the wikitext of the page. I would say that making the behaviour more performant or maybe affecting the articles where the template versioning is a problem is preferable to removing it outright (although I might be not thinking of the right thing in my comment, clarify if needed, I think this is how it is supposed to work?).

Mar 8 2024, 11:54 AM · Patch-For-Review, MediaWiki-extensions-FlaggedRevs

Mar 7 2024

stjn added a comment to T13555: .mw-editsection links should not be part of the <h#> element.

@matmarex can you maybe comment on the cause of the above?

Mar 7 2024, 4:41 PM · MW-1.42-notes (1.42.0-wmf.23; 2024-03-19), User-notice, Patch-For-Review, Editing-team (Kanban Board), Web-Team-Backlog (Needs Prioritization (Tech)), Technical-Debt, Epic, Accessibility, MediaWiki-Parser
stjn added a comment to T334940: All Graphs broken on Wikimedia wikis (due to security issue T336556).

I personally still think that running something on toolforge and exporting to SVG which can then be uploaded, is the most flexible, easiest to realize and most usable short term way to enable rich creation tools. It creates a hard separation between security contexts and avoids any sort of fragile dependency on MediaWiki and Wikimedia. The uploading can even be automated, OAuth login and commons uploading are commonly implemented things in tools already. You loose interactivity, but interactivity was already pretty rare in graphs.

At that point, you might as well resurrect Graphoid in a more secure way. Which is, by the way, a solution: sandbox Vega JS part on the server, allow users to generate graph SVG or PNG images, and that’s it. No interactivity, of course, but also no security threat to the end-users. Which is what the original removal of Graph extension was about. Tbf I don’t get why the perfect is such an enemy of the good here, yes, maybe Graph extension should be phased out in the long-term, but currently we are serving readers a big pile of nothing for the last year. Surely the WMF, with all of its resources, can develop a short-term solution that would not compromise security and then work on a long-term solution. @MMiller_WMF’s email seems weirdly avoidant of that.

Mar 7 2024, 12:16 PM · User-zeljkofilipin, Regression, User-notice, Tech Ambassadors & Translators, MediaWiki-extensions-Graph
stjn added a comment to T334940: All Graphs broken on Wikimedia wikis (due to security issue T336556).

T336595 feels like a band-aid solution and a bad one at that. It does nothing to adress the underlying security problem or maintenance problem. I personally don't think we should do that except as a last resort.

But, to be clear, having graphs unavailable for a year already feels like there needs to be some last resort solution. I don’t see why Graphs cannot be brought back with tight security requirements about editing them, and then a more comprehensible solution can be worked out by the engineers (maybe even dropping the current library etc., but, eh, not waiting for two years for a new solution). Many wikis have used graphs extensively and therefore require them to be back, even though that might not apply to English-speaking audiences.

Mar 7 2024, 11:52 AM · User-zeljkofilipin, Regression, User-notice, Tech Ambassadors & Translators, MediaWiki-extensions-Graph

Mar 6 2024

stjn added a comment to T321893: Evaluate fullscreen mobile Dialog in Codex.

Hey, just want to say that this work is great. Having buttons at the bottom brings another usability improvement: they are simply closer to the user in terms of finger movement etc. Material design guidelines, I think, are not really representative of actual usability trends: take, for example, their inputs, that have been weird for years now. At the same time, I have a related question: was the right-aligned placement of the buttons in desktop contexts in any way tested for accessibility? Because as far as I know, it is generally preferred to keep the buttons next to the input fields at least for one reason: in magnifier-related context user will be less likely to miss the buttons that are located close to what they are doing/reading (see https://axesslab.com/make-site-accessible-screen-magnifiers/ as an example post to that point). Thanks in advance for the answer.

Mar 6 2024, 10:48 PM · Design-System-Team, Design, Codex
stjn awarded T321893: Evaluate fullscreen mobile Dialog in Codex a Love token.
Mar 6 2024, 10:33 PM · Design-System-Team, Design, Codex
stjn added a comment to T358160: Codex icons in Vector and Minerva are displaying incorrectly.

I see the same issue with

Mar 6 2024, 10:27 PM · Verified, MW-1.42-notes (1.42.0-wmf.20; 2024-02-27), Web-Team-Backlog (FY2023-24 Q3 Sprint 3), Codex, Desktop Improvements (Vector 2022), Design-System-Team
stjn updated subscribers of T336211: Find a solution for handling duplicate access keys and access keys of hidden elements (watchlist, login, contributions, search, edit).

HTML spec and WCAG spec are two separate things. We were discussing the case of the duplicated accesskeys with @sgrabarczuk in Russian Discord server (in English) and the thing is, many of those duplicated ones are just duplicated items in various menus (Edit button also present in Actions menu, etc.). If this is to try to get the elements resized correctly, then yes, probably some JS to move accesskeys around to the element that is not display: none is needed. But the HTML on the page also should not be giving duplicated edit accesskeys etc. by default, because having them duplicated is like having IDs duplicated: wrong for accessibility (and understandability for those who use the accesskeys).

Mar 6 2024, 9:33 PM · Web-Team-Backlog, MediaWiki-Platform-Team, MediaWiki-Core-Skin-Architecture (Menus 2.0), MediaWiki-General
stjn added a comment to T336211: Find a solution for handling duplicate access keys and access keys of hidden elements (watchlist, login, contributions, search, edit).

The solution is to not get two accesskeys onto the page in the first place. It is a WCAG violation: https://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140311/F17

Mar 6 2024, 3:21 PM · Web-Team-Backlog, MediaWiki-Platform-Team, MediaWiki-Core-Skin-Architecture (Menus 2.0), MediaWiki-General

Mar 5 2024

stjn added a comment to T359006: Rollback and other autogenerated summaries potentially missing from mobile apps.

I can’t, that’s why I said ‘possibly’. Things to check can be stuff like redirect/page creations, but I can’t know for sure.

Mar 5 2024, 1:40 PM · Wikipedia-Android-App-Backlog (Android Release - FY2023-24)

Mar 4 2024

stjn added a comment to T358948: Avoid text truncation where possible in OOUI/Codex.

I think button wrapping is valid to handle separately from general truncation. Since in the buttons, there can be some instances where you cannot put entire button text on the available screen space (e. g. the button in the example screenshot above). Though I would argue that in the ideal world even such cases should be handled by adapting design in the languages where the button gets truncated, or fixing the word usage, etc., and not cutting off text that can be valuable to understanding what the button in question does.

Mar 4 2024, 2:58 PM · Design-System-Team, Codex, VisualEditor, OOUI

Mar 3 2024

stjn renamed T359006: Rollback and other autogenerated summaries potentially missing from mobile apps from Rollback and possibly other autogenerated summaries potentially missing from mobile apps to Rollback and other autogenerated summaries potentially missing from mobile apps.
Mar 3 2024, 10:15 PM · Wikipedia-Android-App-Backlog (Android Release - FY2023-24)
stjn created T359006: Rollback and other autogenerated summaries potentially missing from mobile apps.
Mar 3 2024, 10:15 PM · Wikipedia-Android-App-Backlog (Android Release - FY2023-24)

Mar 2 2024

stjn awarded T312315: Random "Confirm before you leave" alerts when browsing Wikimedia Commons. a Love token.
Mar 2 2024, 11:43 PM · User-notice-archive, Structured-Data-Backlog (Current Work), MW-1.42-notes (1.42.0-wmf.22; 2024-03-12), Commons, Structured Data Engineering, WikibaseMediaInfo
stjn created T358948: Avoid text truncation where possible in OOUI/Codex.
Mar 2 2024, 11:15 AM · Design-System-Team, Codex, VisualEditor, OOUI

Mar 1 2024

stjn created T358880: Search for topic feature should support headings with templates in them.
Mar 1 2024, 4:45 PM · DiscussionTools

Feb 28 2024

stjn awarded T13555: .mw-editsection links should not be part of the <h#> element a Love token.
Feb 28 2024, 10:01 AM · MW-1.42-notes (1.42.0-wmf.23; 2024-03-19), User-notice, Patch-For-Review, Editing-team (Kanban Board), Web-Team-Backlog (Needs Prioritization (Tech)), Technical-Debt, Epic, Accessibility, MediaWiki-Parser

Feb 24 2024

stjn added a comment to T340705: [performance budgeting] Improve JS payload for projects with gadgets that lead to a 30%+ increase after gzip.

The current skin has no effect on the result AFAIK? But it's true that the script doesn't filter for skins. If there's a Vector-only default gadget but you're using CologneBlue, well, that gadget isn't loading for you. If there's a Minerva-only gadget but you're using Vector, same. For the purpose of finding low-hanging fruit this doesn't really matter IMHO.

The current skin has no effect, which is a problem for figuring out what contributes to payload on mobile. E. g. I got this in ruWP https://ru.wikipedia.org/?oldid=136342483 but most are gadgets for a namespace/action/etc. or do not load in Minerva.

Feb 24 2024, 11:17 PM · Bengali-Sites, Local-Wiki-Template-And-Gadget-Issues, Web-Team-Backlog (Needs Prioritization (Tech))
stjn added a comment to T340705: [performance budgeting] Improve JS payload for projects with gadgets that lead to a 30%+ increase after gzip.

This isn’t much help because this script assumes that all default gadgets load in the current skin, which isn’t true for Minerva.

Feb 24 2024, 10:04 PM · Bengali-Sites, Local-Wiki-Template-And-Gadget-Issues, Web-Team-Backlog (Needs Prioritization (Tech))

Feb 23 2024

stjn added a comment to T336863: Show diff for rollback action on confirmation prompt page.

It's also very easy to achieve pretty much exactly the same by clicking one of the diff links first before doing the rollback.

This is not true btw because rollback reverts one or more edits, and there is no immediate diff link that provides this info accessibly.

Feb 23 2024, 10:42 AM · MediaWiki-Page-history, Confirmation prompt for rollback action
stjn added a comment to T336863: Show diff for rollback action on confirmation prompt page.

This is just patronising. Sure, don’t improve your software because it might take an hour of your time, WMDE.

Feb 23 2024, 10:40 AM · MediaWiki-Page-history, Confirmation prompt for rollback action
stjn added a comment to T336863: Show diff for rollback action on confirmation prompt page.

Why is it a big investment? I can’t imagine this to be something that will be hard to implement, simply showing an edit that will be reverted would already be better than it is now.

Feb 23 2024, 10:27 AM · MediaWiki-Page-history, Confirmation prompt for rollback action
stjn added a comment to T358303: Consider migrating api.wikimedia.org to mediawiki.org.

The fact that there is also doc.wikimedia.org (justified in its existence btw) kind of points to there being too many weird duplicating websites for this. mw.org and doc.wm.org can definitely fulfill the need for these two.

Feb 23 2024, 12:41 AM · WikimediaApiPortal, API-Portal
stjn awarded T358303: Consider migrating api.wikimedia.org to mediawiki.org a The World Burns token.
Feb 23 2024, 12:39 AM · WikimediaApiPortal, API-Portal

Feb 22 2024

stjn awarded T327006: Bundle Extension:TemplateStyles with MediaWiki core a Like token.
Feb 22 2024, 10:13 PM · MediaWiki-Releasing, TemplateStyles
stjn added a comment to T185674: Add a 'mw-collapsible-header' class to 'mw-collapsible' scheme.

I coded around this issue in https://ru.wikipedia.org/wiki/MediaWiki:Common.js#L-163 because some ruWP templates did not work correctly because of this:

Feb 22 2024, 6:00 PM · MediaWiki-User-Interface (collapsible elements), JavaScript

Feb 21 2024

stjn added a comment to T358071: [GOAL] Move template override styles from Minerva to WikimediaMessages and allow site editors more control.

Was asked to comment: in an ideal world there should be a finer onwiki config on what kind of hacks are and are not needed. While transferring all the hacks to onwiki TS pages is a doable goal, it’s hard to do it right in every single aspect of those hacks at once. Which is why it is not feasible to remove the variable. The lack of an ability to make render-blocking CSS on mobile is also an issue.

Feb 21 2024, 6:23 PM · Web-Team-Backlog (Needs Prioritization (Tech)), FY2023-24-WE 2.1 Typography and palette customizations, Patch-For-Review, MinervaNeue, WikimediaMessages