Not only is this a lot of duplication of existing functionality, it is confusing for new admins to have to different pages to block a user.
Fri, Jul 20
As another example where this would be helpful: in Russian Wikipedia sysops and bureaucrats frequently edit a gadget for showing users with advanced groups so that it would stay up-to-date. If there won’t be a more comfortable solution such as JSON, quite a lot people might argue either for workarounds that undermine security (such as content model change?) or for giving those rights to them by default when they don’t really edit any other pages.
Mon, Jul 16
Sun, Jul 15
Team project tag was added because I need the opinion from the team as they are the code stewards of this extension. Was that really inappropriate?
Fri, Jul 13
About the patch above: since it adds new functionality (and per guide), can someone please tell me if that would be OK? It is a frequently used functionality (adding line breaks) that even more frequently breaks the resulting wiki code and parser because of it (can’t work in lists, frequently breaks even paragraphs etc.). I figured that having it as a handled use case would be less problematic than continuing to advise using hacky HTML code.
Are you telling this after testing the patch? (In theory, it should’ve fixed the task above.) Disappointing, if so.
Flow interface was changed since then, and there is no such bug in new interface, so no point in keeping this task open.
Can’t you just do a gadget please? I seriously don’t understand why all of this development is even needed.
What exactly is, the one in the topic or the one I fixed with it? The one in the topic is still present in wikis, so it’s not in any way an old issue. TemplateData should not display a message about ‘custom format’ on _every_ format, otherwise the message should be removed entirely.
Thu, Jul 12
I haven’t tested the patch above, but it looks to me like the problem is happening because isset( $formats[$data->format] ) was referencing an unknown variable, so it always returned custom. If anyone could check this, it would be more than appreciated.
Wed, Jul 11
Didn’t look into a patch before, some small questions (not arguing against the patch or anything):
- Does it mean that now you should just check the checkbox if you are modifying the TOC with scripts (Ctrl+F ‘TOC hidden’ in Russian Wikipedia’s Common.js)?
- Is CSS-based solution entirely accessible? Here it says that IE11 doesn’t read CSS content.
Mon, Jul 9
Ah, don’t even know how I didn’t notice added lines after clicking on ‘show skipped’. Sorry for misunderstanding.
I don’t know exactly where that happened (doesn’t seem like it is exactly there, but it is somewhere in those patches), but line 9524/9510 in the link should read as +ruwiki, since mentioned tasks are for engineer group in ruwiki, T144599 / T190619.
Hey, I don’t have the ability to point this out in patch, but somewhere in the edits for patches you’ve changed rights from +ruwiki to +quwiki, for example, here:
Fri, Jul 6
Thu, Jul 5
There are also some issue in a more global way with interwiki links, since you can write [[google:test]] and it counts as a ‘local’ interwiki link, so different types of interwiki links are likely to need different treatment in future (but that doesn’t mean that the current approach shouldn’t be used everywhere, just that it could be tweaked consistently).
If such discussion is needed, I personally think that for now links styling should be consistent across the platforms as much as possible.
Wed, Jul 4
Mon, Jul 2
Hi, sorry, two trivial points to not create tasks about simple stuff:
- Interwiki links shouldn’t be marked as external, they are interwiki links for a reason and I don’t think that stuff like links to other projects on the main page should have an icon.
- .plainlinks code for mobile is not good enough, it seems to cancel out every padding instead of the right one.
Such change, if it would be global, must be discussed, see links in:
Tue, Jun 26
This isn’t about subtitle though, this is about the lack of margin between the heading and text in some browsers.
Mon, Jun 25
I don’t want to diminish your work in any way, but do you really think that anyone will or can edit a 839 Kb module other than you if they’d had to do any modifications?
Related issue to this: this message uses some icon that does not exist in OOUI and therefore is invisible in interface and pushes the text off-center. Someone really needs to get to this and fix both issues (since it is a smaller problem, I don’t think it needs a separate task, just that this one should be fixed someday).
Fri, Jun 22
If you don’t mind me asking, since it was brought up, would it be possible to see in the future if there a correlation between heavier page size and negative responses (although, if I see the correct dashboard, the number of responses is quite small)? Until some time earlier this year, article about Russia was 800 Kb long, and it’s still 500 Kb now, so I’d think that naturally people visiting it on desktop should be more inclined to answer about poor performance in it.
Jun 22 2018
Jun 19 2018
Misreading everything for the second time already in the same task, apologies.
Jun 18 2018
This is probably required for accessibility reasons, since there must be some indication of focus.
There’s not a lot of leeway to implement this: either we have to do some additional abstraction for creating a non-prefixed selector, which would allow non-sysops to style anything on the site, or have a page name that is available only to sysops (Template:Name/common.css?) and is non-prefixed entirely. I am not opposed to this idea, but I would guess that developers might be, since they are opposed to restricting TemplateStyles in any way IIRC.
Jun 15 2018
Btw, I’ve tried to come up with some long-term solutions since we switched to Babel for all our userboxes, and mainly ran into additional problems with it.
Jun 13 2018
Could you try to make a fairer description of that topic? It seems unfair to developers to do such survey under a topic ‘Strange portrayal’ and not mention anything at all about the changes they made based on community feedback, incl. yours (lower threshold for responsive layout, accessibility fixes etc.).
Jun 12 2018
That might be true in smaller projects, but in any big project admins are not being elected with the assumption that everyone has the proficiency in JS/CSS. I mean, English Wikipedia has more than a thousand administrators; how many of them were elected with their technical proficiency in mind?
Jun 11 2018
Didn’t follow this task quite clearly, but I must say that the current variant in the description is bad for one major reason: click area jumps. There is a pattern of using expand/collapse types of buttons with mouse staying in the same place (at least for me), and this design would prove that difficult because the button would not stay in the same place after expanding, therefore making it in the same place is always better than having them jump.
Jun 10 2018
Page previews are not the same thing though: their lack is not detrimental to the experience of readers and users. If this development will prove to be good and will be eventually replicated in other skins as well, it would not make sense to have responsive skins turned off by default anywhere at all. However, if there’s a way to make this off only for older users, then it is an OK approach (although I should say that it would limit the ability and willingness of communities to implement more responsive layouts with things like TemplateStyles if majority of older users would not see any changes from this, so that must also be considered).
Jun 8 2018
Yeah, I am not trying to say that the intent behind MobileFrontend, especially when we see the editors react so much about good ideas to do something that other sites did some years ago now, is bad or anything. It is a tool of necessity, but we shouldn’t think that all mobile development should be pushed to mobile as soon as possible (and I think the people that ask this new development to be disabled on their community level are somewhat overreacting).
Jun 7 2018
I think in the long term there is a sense to make this preference skin-agnostic and provide for users the means to disable responsive design on any skin instead of just Monobook, especially since any future efforts would likely go into the same thing.
Jun 6 2018
If this can’t be resolved in 4 years already, maybe it’s time to stop supporting automatic referencing then? At least the error for it is quite visible, when automatic references are being left without any regards to wiki’s rules and frequently have broken numbering because they are inserted in some precarious position.
Jun 5 2018
@Tgr: yes. I don’t object to the idea itself, the more security the better, but the text of proposed guidance did make an impression for me that this new group needs to be like bureaucrats, where no non-sysops can become one, and that is not the future I’d want because projects that have such group already would be harmed by that. Your addition probably solves this.
Groups like RuWP’s engineer (I can’t talk about other ones) were created specifically to have non-sysops that are proficient enough in technical matters but probably won’t have much luck with getting the flag for all ‘fronts’. I am very scared that creation of a new group with an implicit target of ‘make the entry bar higher than sysops’ would lead just to more enclosure of technical rights both on local and on global level.
Jun 4 2018
I mean, breakpoints usually can be set not only for specific layouts, like Timeless I would guess have done, but for specific devices. WikimediaUI breakpoints are set for types of devices, so they can be reused with any specific layout without a problem. Most disagreement that people have found with the new layout is in that it changes into mobile layout too early, so it would make sense to use a mobile-only breakpoint for responsive layout developed by you even if columns are too narrow on 720px, too.
Jun 2 2018
There is one at https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#Новый_вид_стационарной_версии_в_смартфоне, but it’s mostly subjective.
You can use 720px (although it can’t be used as max-width, 719?) from https://github.com/wikimedia/wikimedia-ui-base/blob/master/wikimedia-ui-base.less. I would suggest that using variables already in use is probably wiser than coming up with your own.
Probably what would fix this is visually hiding specific menus instead of hiding them entirely with display:none;. I would guess that they don’t work exactly by that logic: if they aren’t displayed in browser, they aren’t actionable. However the edit button working is definitely strange and can’t be described by this.
There isn’t a special relationship with ‘volunteers who carry out the foundation’s mission’. There is a special relationship with the vocal Anglophone people in English Wikipedia that get the 99% of the attention from WMF and developers despite the global nature of our movement.
There isn’t a way to deploy responsive layout only ‘for mobile’. Our current mobile site is, and I hope no one will hate me for this, a kind of a big hack. It stays here because we can not, at this moment, implement a proper responsive layout due to amount of older templates etc. that would be rendered completely wrong in the desktop version. But it is a same ancient tool like a WAP version of a site was not too long ago, so eventually we should get rid of it.
Jun 1 2018
I’ve already deployed the new main page, I’d guess people on 3G would have to suffer a bit, but this is really rather an unfortunate turn of events so I don’t want to put on brakes just because of this.
May 31 2018
I hope you don’t mind that I raise the priority, I wanted this to happen before June 1 specifically for the reason that it would be easier to deploy the new main page in RuWP today at night (MSK).
May 30 2018
Agree with your analysis. I meant ‘temporarily’ as referring more to the nature of this feature, which is uncertain at the moment until the necessary discussions will happen and something will be decided on a larger scale.
We do already, thanks.
We don’t support browsers supporting neither, so there’s no need to care about that (they can just display one-column layout after all in case of Russian Wikipedia). Bugs with flexbox are also manageable and mostly are concerning older IEs, I don’t see how this is an argument against using it.
May 29 2018
If we have this difference just for the purpose on testing, then it’s even less valuable. I mean, we have Pig Latin English somewhere in the code for testing language variants, doesn’t mean that English Wikipedia should have Pig Latin English as a default variant available in the project. Production should not be used for the purpose of bug-testing.
I was talking more widely. In our case the thing we need is having background change from the get-go instead of after the page render.
TemplateStyles doesn’t have the access to ‘higher DOM’ and it was for a reason (since it is editable by everyone, albeit in Russian Wikipedia we have disabled that in the meantime). TemplateStyles don’t have the support of prefixed properties (see T162379) and don’t have the ability to modify the page on higher level than content (which is, ultimately, good for most pages, but in main page’s case it is not good since, for example, almost every project hides the title via Common.css right now).
May 28 2018
Yes, you can start.
May 25 2018
Some issues (don’t care much about Monobook, but either way): all action buttons are too small for mobile, seemingly no logic in why the top row is marked in orange (isn’t it for current items only?), no branding present at all (how exactly does anyone know if they are still on Wikipedia or somewhere else?).
May 24 2018
May 23 2018
For anyone that will decide to do this task: we got consensus in the Russian Wikipedia to improve the main page using TemplateStyles, and the ability to use prefixed CSS properties would be more than welcome addition to see. Right now I intend to add prefixed properties only directly to Common.css/Mobile.css before pushing new version, which would be less than ideal.
May 22 2018
Done in Russian Wikipedia (no notice, just a banner): https://ru.wikipedia.org/?diff=92816291
Closing this as resolved as the main discussion in Russian Wikipedia will soon halt. Thanks to all the people that decided to provide the feedback.
Same in Russian Wikipedia (from Russia):
Request from […] via cp1054 cp1054, Varnish XID 382637319 Error: 503, Backend fetch failed at Tue, 22 May 2018 13:43:18 GMT
Was thinking about this the other day: was there any data that users don’t like a default <div> animation? <table> ones yes, they are godawful, but <div> animation wasn’t that bad on the second thought. It’s not like we don’t use animations anywhere, so it was a nice addition to .mw-collapsible while it lasted.
May 20 2018
May 19 2018
If this is absolutely needed, it should be an external tool that gets Echo notifications from MediaWiki API (if that is possible). It would be a bad idea to add an integration to an external proprietary service from MediaWiki. (This is not clear enough in the task.)
May 17 2018
May 15 2018
You shouldn’t put such lengthy references there in the first place. This is way beyond and above the norms of fair use, for one part, you could justify putting the entire book in the references the same way.
May 14 2018
May 13 2018
Well, Arabic and Basque Wikipedia already use some fonts from that resource on the site level, and deploying an extension for a font seems a bit uncalled, so I think this is something to consider.
May 12 2018
Commenting so that this would not be lost: feedback round from WMDE proposal  shows that many rollbackers from different projects (although it wasn’t advertised everywhere, just on Meta) overwhelmingly reject having rollback confirmable by default.
May 11 2018
Hi, I saw the announcement on English Wikipedia’s technical village pump and thought that I could ask: is there a way for other projects to chime in on this? Engineers in Russian Wikipedia would’ve greatly appreciated such research being conducted for our readers. I can translate a note to wider community about this if you would give this a green light.