Tue, Nov 29
For the record, someone with global bot permissions also needs to clean up all of the bad code that was added by CX in the meantime (basically, replace everything in https://global-search.toolforge.org/?q="upload.wikimedia.org"&namespaces=0&title= that looks like |skakel=//upload.wikimedia.org/…). If the Language team can find someone to do that themselves, that would be great, since every project was affected by this bug.
insource:"class thumb" prefix:template: lends a rough estimate of 70 templates in enWP and 20 in ruWP, for example.
Coming over from [[mw:Parsoid/Parser Unification/Media structure/FAQ]], I still do not understand why you chose such convoluted CSS for this instead of agreeing on one class that would describe all of these thumbnailed media files equally. Just a baffling decision, especially given that there are classes used in the layout modifiers for this new syntax.
Fri, Nov 18
I don't think my task is asking to unite all the different script lists into one. It's asking to stop breaking lists into columns with HTML. I would appreciate it if you didn't mark tasks as stalled without asking first what the scope of the task is. Thanks.
Thu, Nov 17
So the fact that someone is mad at the WMF in English Wikipedia means that a future default feature would be rolled out in a bad state. Tragic.
Wed, Nov 16
Is this in reference to entire DT mobile experience or just this task? Because it would be weird if it’s the latter.
Yeah, sorry. Didn’t know this is necessary now.
Right now this toggle’s design looks exactly like Kartographer’s ‘Show full map’ toggle, which might prove confusing to the end-users (especially on wikis where Kartographer maps are used more).
Fri, Nov 4
They are accessible, they are just made inaccessible by the editors. I think this is the case where the communities should decide how to solve this themselves, and not something MediaWiki should support in its entirety. If you’re using custom styling, you are responsible for making it work with everything, MediaWiki shouldn’t be. Much in the same way that if you put a weird banner on all pages that moves across the page in an animation, it’s your obligation to make it work with everything else and not developers’. It’s not a ‘purist view of styling’ to say that this task should be declined.
Nov 2 2022
As I’ve said before, British English is not the only problematic language where this happens, so its effectiveness would be fine for British English, but would not solve all of the cases (like Abkhaz → Russian translations I mentioned above).
Oct 27 2022
Yes. Editors should just not use colours that would make the icon disappear. Custom themes like dark mode etc. can invert the icon by themselves, that’s not what this task is about. This task is about the editors using to do the wrong thing for their arbitrary preference. There’s nothing anywhere that says that that table should be in the colours of the university.
Oct 25 2022
Oct 19 2022
I think that is the case for improving the search appearance so this link gets turned into a button that says ‘Create new article’ or something, not the case for removing the ability to create new pages from the search altogether.
Oct 18 2022
Just passing by to say that the vertical misalignment of the Reply button even on devs’ own screenshots should probably be fixed.
Oct 15 2022
Will any attention from the language team be given to this task? I don’t want to have to run a bot every week about this, since this is a bug that is present in all of current ContentTranslation output.
Oct 13 2022
Oct 8 2022
Or not a lot of testing beforehand, as is more or less customary by this point. The fact that every search result is now a table is atrocious. This is why changes are done via beta features.
Oct 3 2022
JFYI: the study’s point on avoiding descender elements of q/p/j is outdated by now, all modern browsers already do that for underlined links.
Sep 24 2022
Sep 20 2022
This is already possible:
function expensiveParserFunction(page) local success, result = pcall(function() return mw.title.new(page).exists end)
(Given what you’ve said on VPT) I think merging [edit source] issue and DiscussionTools issue together is somewhat unnecessary. It should at least read Huile de citron [edit source], the underlying issue here is that DiscussionTools, to work properly with MobileFrontend (?), adds too much stuff into the headings. Fixing both this issue and T13555 at the same time would probably involve too much effort and negotiation (since edit links themselves are a really prominent element of the interface), but there’s no reason why DiscussionTools itself cannot use a more reasonable markup that would have some support from MobileFrontend.
Sep 14 2022
Many editors have ULS disabled, since it previously powered compact links, which wasn’t everyone’s cup of tea. So the answer is yes.
Sep 13 2022
This introduced T314728: In search bar, Home and End keys should move caret, not selection in suggestions regression, btw. Shift+Home/Shift+End especially should always work, which the above implementation did not check for.
Well, merging the text from my duplicate task now:
I think, given what’s said on W3C WAI Authoring Practices Guide about the combobox pattern, that choosing to implement Home/End keys as the means to traverse the combobox is incorrect. Search field is by definition editable, so users should be able to go back/forward to edit whatever they want here. Even Shift+Home/Shift+End combinations, the one that select text, do not work in New Vector’s search, which makes the experience annoying for people who use those keys (like me). Please remove key handling for Home/End keys in New Vector’s search.
Sep 12 2022
Just FYI: this has more than 260 hits in Russian Wikipedia already (which I’ll clean up in the next few days), so this should be a problem that is given more priority given its prevalence.
Sep 11 2022
Going to re-mark this as Stalled so people would at least find this task if they look for it. More than fine if someone objects, but I think this is a valid task for a problem that DI team doesn’t have resources to solve right now.
https://ru.wikipedia.org/wiki/Шаблон:Стиль_столбцов which basically styles any table with specific classes has around 800 uses already. So I’m guessing that any recommendations that can be made should be made sooner than later, since more and more wikis are going to do this because of its convenience.
Sep 9 2022
I mean, if the problem is in encoding and not in <h2>, then it would’ve definitely needed to be fixed, since I imagine ! and ? characters are used quite a lot in discussions. I don’t think that’s the issue, though, since this talk page experience works fine:
Sep 8 2022
Shouldn’t inline syntax highlighting be exempted from this (or have higher limit)? I’m not sure whether there are many pages that use inline <syntaxhighlight> that frequently, but I also don’t think that there’s as much threat with the inline tags as much as with, tbh, atrocious page that was linked to above.
To provide some examples, you can sometimes see users in Russian translations doing changes like these:
Sep 7 2022
(Technical note: it’s because they use href="", so all the ‘links’ reference the current page.)
Sep 1 2022
I guess that example makes the initial suggestion somewhat invalid for desktop resolutions, yeah. Though I don’t see how having a hack for it on the resolutions where various float bugs should possibly not be shown (<720px?) would be bad.
Aug 30 2022
It was https://ru.wikipedia.org/wiki/Википедия:Кандидаты_в_избранные_статьи before I fixed it. https://ru.m.wikipedia.org/wiki/Википедия:Кандидаты_в_хорошие_статьи currently has the same issue on some resolutions.
(Oops, no idea why it was posted twice.)
Looks good 👍
Aug 28 2022
That’s because you can’t invert selection with ‘All’ namespace. If you pick a namespace, ‘Invert selection’ is shown again.
Aug 26 2022
I think the prototype in that task is a bit better, but would be even better if the search box expanded only when suggestions are actually visible (right now it expands when typing starts, and only then shows the search results, which makes it two animations if the loading is not quick enough).
Aug 25 2022
Aug 23 2022
For now, this is also achievable through CSS/TemplateStyles: https://ru.wikipedia.org/?diff=125047246&oldid=119611147 (I plan to remove the CSS in question if something more generic comes up, but I think it does the job well enough for now)
Aug 22 2022
Aug 15 2022
Real-life example is something like https://ru.wikipedia.org/wiki/Need_for_Speed:_Most_Wanted#Источники (in some cases, but not here, red links can also be next to blue links, which can make it confusing).
Yeah, I also thought about how red on black can be bad, but strikethrough in my opinion would be worse for accessibility reasons, since it makes the text unreadable for some. The dark mode gadget makes red links like #ff9d9f, but it’s not exactly accessible either (3.09).
Red links can be inside references, for example, if the article about a publisher or an author does not exist yet in a wiki, but someone linked its name because they are definitely notable and someone would create an article some day.
Aug 12 2022
Aug 11 2022
Cool to hear that it can be turned off. At the same time, I still think it’s distracting more generally when the search is something you do often, as many editors do. Especially since there’s also another change happening there at the same time (Search button appearance).
Aug 8 2022
@matmarex ‘Worse’ is kind of an understatement here. 'Edit' is one word, however annoying, in most languages (though there's also the fact that we put two links in most wikis, so...), DiscussionTools adds 12 minimum both before and after the heading. Whatever issues there are with MobileFrontend probably don’t justify this. To me, in the ideal world, this is where developers should step in and say to designers ‘this cannot be done because of technical reasons without harm’, in DiscussionTools’s case that applies to, I guess, mostly just to ‘Subscribe’ button being at one level with the heading and showing the info about the collapsed discussions on mobile, if MobileFrontend does not allow wrappers around heading elements.
Aug 6 2022
Aug 4 2022
Stopping the forced language suggestion altogether (option A) seems like what needs to happen to get this to stop. For variants, you could also do something like A1 which would be suggesting English if someone has British English, but that won’t stop the problem of someone translating in Chechen but ending up changing Russian messages (that is a common problem, btw, and one I forgot to mention earlier when I said to you that placeholder wouldn’t cut it).
Aug 2 2022
Jul 29 2022
Jul 18 2022
Jun 30 2022
It’s still incorrect markup, though. That is one of the reason it is not used in Russian Wikipedia, and the styling tweak you’re proposing is not going to change that.
Jun 19 2022
As I noted in T117754#8013510, the form should just not be collapsible. There is practically no benefit to it, and it makes using the page a bit harder. If the developers listen to this, then this task could be resolved for all intents and purposes.
The form shouldn’t have been collapsible in this case. It makes a number of regular use cases of What links here, such as ‘go to the template, see where it’s used’, a bit harder to do without much benefit on mobile viewports (since this form is not long, like on Special:Contribs).
Jun 7 2022
Yeah, that’s true actually. I guess I just thought that it’d be better since they put a lot of thought into their link styling (more into focus styles, I guess).
Jun 6 2022
It is not the question of ‘not understanding accessibility’. It is the question of picking the wrong colours for the job. Both blue and red coloured links that are proposed (and red is already used) have lower contrast against background, and only conform to the lower ends of AA level (5.37 for blue/white, 5.09 for blue/sidebar, 4.57 for red/white; 4.5 is bare minimum). As it stands, they are simply worse choices, even if they differ to the text around them a bit better (but also barely because it is dimmed for no reason, reducing contrast).
May 25 2022
(Just a note that this part wasn’t fixed, and this warning still pushes the page down a bit.)
May 19 2022
Well, the basic example is that the sidebar link to ‘Main Page’ leads to the same page you are on if you are located on the project’s main page.
Minerva does not have navigation portlets per se because it implements its own sidebar, though I think even its mobile menu can benefit from this change. T20465: Tabs in Monobook and Vector should indicate selected state for assistive technology is similar to this, yes, but I am not talking strictly about tabs. As for ‘the only place the link should be to the current page is the tab next to talk page’, it is not strictly true: sidebar links can lead to the same page that we are on, and this should be indicated to screen reader users.
May 14 2022
Apr 29 2022
No, since Simple English is not a separate language.
Mar 16 2022
Just disable images in any browser (I assume), or just latest Firefox.
Feb 25 2022
I was thinking that this change is worth announcing because it is one of the most visible parts of the software and it got a significant design/placement change. But OK.
Feb 24 2022
I believe this should have been announced, as it is a big front-facing change. (And, IMO, an imperfect one, making the notification much less noticeable.) If already-done-previously things cannot go in Tech News, please correct me.
Feb 17 2022
Feb 16 2022
Not sure about SEO, but headings that are completely hidden, like you have recently done a change for, do not get into accessibility tree unless referenced by other elements (such as aria-labelledby). So there is no accessibility problem here, only if there is no <h1> at all when hiding it. I am pretty sure I already described this in T300695 before.
While I am not @Sdkb, I do want to reiterate that this is complete non-starter from multiple different points. Among them:
a) most wikis hide the heading for a reason—because it does not fit into the existing designs, which you as a designer should understand;
b) therefore, this suggestion requires all wikis to work around Vector 2022 in their main page designs since other skins do not require this, which in many cases can and will be a lot of work (what is your suggestion for ru.wikipedia.org, for example?
nevermind the fact that the design looks worse with enforced max-width);
c) there are projects where <h1> is now appropriately set on the page itself, which would need hacks around for new Vector if you enforce the page title on it;
d) there are some multilingual projects that use page structure like Main Page/de for their main page localisation and do not use Extension:Translate, and page title will be bad to show on those projects.
Both? I don’t think styles for ul are different in two skin versions.
Feb 15 2022
I see. Yeah, it seems like it was chosen simply due to its styling. Not sure how to reconcile it without making everyone mad that all the dates will be displayed bigger (add a visually hidden <h2> so the change would be less prominent?), but I’ll open a separate task for it.
I understand that this is already merged, but there are multiple issues with implementation:
a) <h4> level heading is wrong if you have no <h2> and <h3> on the page beforehand, like it is currently on Special:Contributions. The implementation should probably insert different level headings if this is necessary for some pages, so it should be <h2> on Special:Contributions, for example.
b) If desktop skins will hide these headings completely, screen reader users would lose all the information as to why there is a dozen of separate lists on the page, as opposed to just one like before. This should probably be done with visual hiding instead, though I am not sure.
Added ‘Some audio players will become wider after this change’ there since this will be the most visible result of beta feature becoming the default. If someone has better description for this, feel free to change it. [See the difference between Kaltura and Video.js: https://ru.wikipedia.org/?oldid=119991246 or https://ru.wikipedia.org/wiki/Шаблон:IPA_chart/table_pulmonic_consonants_with_audio ]
Feb 5 2022
@Theklan: would you consider this adequately solved if account creation interface (Special:CreateAccount page) had a link to log in in it? (Which it weirdly doesn’t at the moment, so I understand where you are coming from.)
This is something that should be solved by enWP’s editors choosing colours with good colour contrast against those icons, and not by software changes. Your community can require it in its guidelines. According to WCAG 2.0/2.1, minimum colour contrast between icons and the surrounding backgrounds should be at least 3:1, which would be visible (cannot provide a link right now, but can probably find it).