I assumed Keegan was asking about needing continued CL support.
@Keegan: I would say we're done here, barring any unforeseen events.
Nevermind, I can do it myself! https://toolsadmin.wikimedia.org/profile/settings/ssh-keys
Thu, Dec 14
@dmaza: In the sitematrix, all the wikis are organized as either under a specific language or "special". Wikis like commonswiki, metawiki, wikidatawiki, and sourceswiki are "special" because they are multi-lingual wikis. Specieswiki is English and Neo-latin, but not specifically associated with English as there's only 1 WikiSpecies project.
@dmaza: That looks pretty reasonable. Don't forget to add commonswiki, metawiki, wikidatawiki, specieswiki, and sourceswiki (the "special" wikis that are actually used by the community).
There are lots of gadgets on lots of wikis that use jQuery.ui. Regardless of whether MediaWiki itself uses jQuery.ui, I think it would still be a good idea to make it available as a module for gadgets indefinitely.
One of the problems with pulling from the whole list and sorting alphabetically is that wikimedia comes before wikipedia, so you get wikimedia chapter sites first, which you probably don't want. And you also end up getting wikibooks before wikipedia.
Wed, Dec 13
Made sure everything is as up to date as possible.
Still seems to not be ordering the wikis in a useful way.
This seems to be sort-of fixed now. Results are returned, but only some initial results. It seems to keep making API requests but not display any results beyond the first batch or so. For example, at https://tools.wmflabs.org/interaction-timeline/?wiki=enwiki&user=Missvain&user=Hullaballoo%20Wolfowitz it displays results up to August 2006, but nothing after that. Compare with https://tools.wmflabs.org/sigma/editorinteract.py?users=Missvain&users=Hullaballoo+Wolfowitz&users=&startdate=&enddate=&ns=&server=enwiki.
Supposedly this is fixed by https://gitlab.gnome.org/GNOME/librsvg/commit/c70000117fb6e7dabdb77c1c8cc1067add7da6d9, which landed in librsvg 2.40.19. See https://gitlab.gnome.org/GNOME/librsvg/issues/151 and https://bugzilla.gnome.org/show_bug.cgi?id=587721.
Tue, Dec 12
Otherwise, GlobalPreferences is coming soon. It's been stalled by RfCs (T178449), but I anticipate it will be available in the first half of next year.
@daniel: Thanks for the clarification! Just wanted to figure out what we can actually push forward with in the meantime. I don't want us to add a bunch of technical debt by prematurely moving in the wrong direction just to support GlobalPreferences, but I also don't want us to stall GlobalPrefs if we can actually get it up and running in the meantime (prior to a full prefs overhaul). This probably makes me the kind of manager that you warned about! Honestly, though, I do care about the preferences codebase and know that it needs a complete overhaul. I'm going to push for some attention to this (along with some other critical orphaned features) during the upcoming Annual Planning meetings.
This is based on assumptions that aren't true.
You're correct. My assumption is that this notification is helpful to newbies and not helpful to old-timers. According to the only data we have, it's probably helpful to neither. I do know from personal and anecdotal evidence that at least some users find this notification annoying and spammy. For example, you can easily edit dozens of different wikis just by moving a single file on Commons.
@jmatazzoni: It seems to me that there's an easy way to solve this problem without having to mess with preferences. The basic issue is that this notification is only really useful (if it's useful at all) on your home wiki. People who edit multiple (and in some cases, hundreds of) different wikis aren't newbies and they will only view these notifications as annoying, especially after the 100th or 200th one. For example, I've made at least 1 edit on over 100 wikis and I don't even consider myself a super active editor. The solution would be to only generate these notifications on your home wiki, i.e. if the wiki you're editing isn't your home wiki, don't even generate these notifications at all. That way they will still serve their intended purpose (encouraging newbie) and they won't annoy the old-timers :)
@Keegan: Can you circle back with the Commons community and let them know that the purging issue seems to be resolved (as of last month)?
@dmaza: Tested out the patch, but strangely the pref disabling behavior isn't working for me locally:
@daniel: Basically, we just need to know if https://gerrit.wikimedia.org/r/#/c/389665/is a good jumping off point. Is this something we can build on going forward or do we need to take a different approach? It sounds like most people think the patch is going in the right direction, but we need a bit more certainty before we build all of GlobalPreferences on top of it. Is there anything significant that Sam needs to change about his current PreferencesFactory approach before that could be merged?
Mon, Dec 11
@daniel: Would be awesome if we could get a clear path forward, as this RFC is the only thing currently blocking work on GlobalPreferences.
Sun, Dec 10
This notification should just be removed as discussed in T160446. It's annoying to cross-wiki editors and actually has a negative effect on editing behavior per https://meta.wikimedia.org/wiki/Research:Post-edit_feedback/PEF-2.
@DannyH: Are we still doing this? We would need to write a script to track down everyone's home wiki before we posted them.
Sat, Dec 9
Thu, Dec 7
@matmarex: I'm glad you remember how to read these files! I always forget.
Ü and Ű are also missing, although I have no idea if they're actually useful.
Wed, Dec 6
FYI, if we end up creating our own custom collation class, it should be based on https://ssl.icu-project.org/trac/browser/icu/tags/release-58-1/source/data/coll/se.txt.
@Smalyshev: Last I checked, the intl extension we're using in production is based on ICU 52.1, which doesn't include Northern Sami (se). It is however, included in current versions of libicu. Could we swap out our intl extension for a newer build? If not, I'm fine with creating a custom collation class.
@jhsoby-WMNO: Yes, I believe it would be possible for us to create our own collation similar to BashkirUppercaseCollation.php.
@jhsoby-WMNO: That's correct. Even though MediaWiki now supports collation for Northern Sami, the Wikimedia production servers don't. The steps for that to happen are:
- Get it added into ICU library (done)
- Wait for a new version of the PHP intl extension that has the new ICU code in it
- Upgrade PHP on the Wikimedia production servers
Unfortunately, the last two steps may take several years.
Maybe we could put in a sanity check to prevent people from trying to upload files that are above a certain really large size to keep people from running into the memory limit (at least for now).
Tue, Dec 5
His upload power is over 500!!!
@Niharika: Works for me. I get https://hi.wikibooks.org/wiki/कला_और_संस्कृति#रंगमंच from the table of contents. Where did you get your link from? Note that pages whose caches haven't cleared may still have the old-style links.
Niharika's patch should fix WikEdDiff. I'll create a separate bug for the button-still-functioning issue.
Fri, Dec 1
@Niharika: Ah, I was confused when you said "it'll load CodeMirror for everyone, whether they have the beta feature or not." If you mean it's just loading the module, that's not as bad :) It still seems wasteful to load unneeded JS for everyone. What do you think of the other ideas above?
Thu, Nov 30
We might be able to do something similar to Niharika's solution, but only if the user has actually enabled CodeMirror, i.e. use the API to check the user options before adding the CodeMirror module as a dependency.