Wikipedia

Wikipedia talk:Wikipedia Signpost/Single/2023-01-01

< Wikipedia talk:Wikipedia Signpost | Single

Comments

The following is an automatically-generated compilation of all talk pages for the Signpost issue dated 2023-01-01. For general Signpost discussion, see Wikipedia talk:Signpost.

Arbitration report: Arbitration Committee Election 2022 (689 bytes · 💬)

  • Sorry to the newly elected arbs, and congrats to those retiring from the committee! Thanks for your service to Wikipedia. —Ganesha811 (talk) 13:34, 1 January 2023 (UTC)
  • Welcome to the New Year for the team of The Signpost! And thank you for reporting jounalistic accurately about the factual results and some quaint details of the recent Arbitration Committee election course of events. -- Just N. (talk) 16:54, 8 January 2023 (UTC)

CommonsComix: #4: The Course of WikiEmpire (1,979 bytes · 💬)

The terminal cancer would much rather become a mere parasite than face chemotherapy. The patient was swayed away from chemo, as they seem to think the cancer isn't lethal or might, in fact, be good or useful. Chris Troutman (talk) 22:00, 2 January 2023 (UTC)
  • This gave me a good laugh given the old wording made it seem like it truly was Doomsday on Wikipedia (sometimes it does feel like it). ― Blaze WolfTalkBlaze Wolf#6545 20:29, 5 January 2023 (UTC)
  • Cute, but I think that text would have worked even better on a picture of Ukraine.

    We humbly ask you to support Wikipedia's independence, in the name of Ukraine and preventing Putin from blowing up these children. And that box of kittens the kids are holding too. You don't want the children's starving parents to have to eat the dead mangled kitten remains, covered in their children's blood, do you? Alsee (talk) 02:18, 15 January 2023 (UTC)

Essay: Mobile editing (46,046 bytes · 💬)

  • I've always used the desktop view on mobile, because, well, that's what does everything. I tried the mobile view once; some functions I couldn't find at all, some didn't work well, and others worked completely differently than I was used to. I've never understood the appeal of putting "apps" for websites on my phone. I already have an "app" for use of websites. It is called a browser. Seraphimblade Talk to me 04:44, 1 January 2023 (UTC)
    In my experience, a lot of websites perform poorly on a web browser. Wikipedia is a somewhat bizarre exception in that its app has many reduced capabilities. Even if it isn't your personal preference to use it, I think it is important that the app is improved for the people who do. More people than ever have access to a smartphone compared to other forms of technology and the app has more than 50 million downloads (and that's just the Google Play Store's count). There's dedicated WMF staff for the app. My opinion is that since people are using it, it should be more usable. Clovermoss🍀 (talk) 05:35, 1 January 2023 (UTC)
    I'd also like to note that there is a difference between mobile view, desktop view and the app. If you don't switch to desktop while browsing Wikipedia on a browser, you're typically using mobile view. This doesn't have the same capabilities as the 'standard' Wikipedia but it is more within the norm for what you would expect for a mobile version of a website. My understanding is that using mobile view is more common among experienced editors than even trying to use the app. Clovermoss🍀 (talk) 07:17, 1 January 2023 (UTC)
    I'm one of the experienced editors who use desktop view when editing on mobile devices, because the other methods lack functionality. What I find, irritatingly, is that on IOS devices my bookmarks to Wikipedia pages get redirected to the 'mobile' version of the page every so often. Clicking the desktop link at the bottom of the page then, bizarrely, jumps to the app not the desktop version of the page! I have to close everything down to get things working again. Neiltonks (talk) 10:15, 4 January 2023 (UTC)
  • I couldn't agree more with Seraphimblade. And I had a, err... very limiting device up until recently. — L10nM4st3r / ROAR at me! 10:58, 1 January 2023 (UTC)
  • WikiAddict tip: I've never looked at or used the internet on a phone, a way of not carrying the addiction around with me. Randy Kryn (talk) 13:28, 1 January 2023 (UTC)
  • I use the app when I want to look something up on the move because it's easier on a small screen. It has some nice features, like putting images prominently at the top of the page and previews of other articles when you tap a link. I make the odd trivial edit through it like fixing a typo (also recently found out that I'd been logged out and my IP was blocked!) but it can't support much else. I profoundly dislike typing lengthy text on a phone keyboard so any heavy-duty article work or anything involving templates or references has to wait til I can get to a proper computer or at least a tablet with a Bluetooth keyboard. I do also use the "Cullen method" (@Cullen328:) of desktop view on a mobile device, mostly for watchlist scrolling and adminning. With a few extra tools, it's surprisingly easy to clear an AIV backlog. HJ Mitchell | Penny for your thoughts? 14:38, 1 January 2023 (UTC)
    @HJ Mitchell: It's nice to hear I'm not the only one whose tried to use the app. I will say I have done more than fix typos. Once the text scrambling issue and app crashes through line break were fixed, I was able to do stuff like this even if tended to be inefficent:
    However, the majority of my edits through the app were general replies to conversations I was involved in or relatively small phrasing changes in articles. Which is basically what you were saying. If you're curious, you can actually filter my contributions to show only my app edits [1]. I've done slightly over 500, technically. I tried to do different things to see how they would work out. I believe I cited a reference based off memorized parameters at one point but I haven't been able to find that edit. Clovermoss🍀 (talk) 20:45, 1 January 2023 (UTC)
    Interesting. How did you access rollback in the app? I didn't even know that was possible. HJ Mitchell | Penny for your thoughts? 21:00, 1 January 2023 (UTC)
    @HJ Mitchell: It depends on who you're reverting. If it's a registered account, it's right next to the 'thank' button in a diff. If it's an IP, you have to go to the three dots at the top and click 'rollback'. I've mentioned why this isn't ideal in the discussion on my talk page. Clovermoss🍀 (talk) 21:04, 1 January 2023 (UTC)
  • The mobile web experience feels clunky and dated when doing anything beyond basic article viewing and simple edits, especially in a day and age when most websites have been switching seamlessly between mobile and desktop view with no difference in functionality for over a decade. A few peeves of mine:
  • Mobile pages use a different URL (m.wiki.x.io) which complicates things such as sharing a link in a discussion or viewing a bookmarked page on a desktop computer. Unlike other sites, checking the "View desktop site" box in Chrome brings up a zoomed-out version of the mobile site instead of switching to the actual desktop version.
  • Rendering issue:
Expand to see rendering issue
  • H
e
a
v
i
l
y


i
n
d
e
n
t
e
d


t
a
l
k


p
a
g
e


c
o
m
m
m
e
n
t
s


r
e
n
d
e
r


o
n
e


c
h
a
r
a
c
t
e
r


p
e
r


l
i
n
e
.
  • Talk page templates are hidden, buggy or missing entirely. Looking at one example:
  • None of the templates are visible unless you click the "About this page" link.
  • The entire Talk Header section is missing entirely, including talk page instructions and archive links.
  • The "Remedy instructions and exemptions" section is missing from the Arbitration Remedies template, and there's no big orange exclamation point.
  • "Daily pageviews" shows a blank box
  • "Section sizes" is missing
  • There's a random "This edit request has been answered" message, apparently from a section further down the page.
  • This means that new editors working from mobile devices have no access to talk page instructions or archives and have to click through to see important arbitration notices, some of which are incomplete. Given the amount of thought that goes into the wording and formatting of these notices, the fact that some editors see a different or incomplete version is concerning.
Bringing the mobile version up to modern UI standards should be an urgent priority. It's not just an aesthetic issue; mobile-based editors literally do not have access to the same information or notices as desktop users. –dlthewave ☎ 17:00, 1 January 2023 (UTC)
  • Mobile pages use a different URL (m.wiki.x.io) which complicates things such as sharing a link in a discussion or viewing a bookmarked page on a desktop computer. To save having to click "View desktop site" every time you use your smartphone to connect to Wikipedia, you can put mw.loader.load("https://en.wiki.x.io/w/index.php?title=User:%C3%9Ejarkur/NeverUseMobileVersion.js&action=raw&ctype=text/javascript"); in your Username/common.js directory. Maproom (talk) 11:17, 7 January 2023 (UTC)
Agreed. There is sort of a dark humor in our typical thinking: "this shit is really important, so we need to put it in a message box template". But the very act of doing that means that most readers can't see it! It makes absolutely no sense to me. jp×g 17:37, 1 January 2023 (UTC)
I wasn't aware that the mobile version of the website had many of its own technical issues, dlthewave. Thank you for bringing attention to them here. I was just going off of some of the experiences I've heard from other people, but it's important to hear another perspective. Clovermoss🍀 (talk) 20:24, 1 January 2023 (UTC)
It'd actually be more correct for me to say that I wasn't aware of this specific issue. dlthewave, if you're curious (or maybe you already know) the mobile technical issues I'm more familiar with is what's listed at Wikipedia:Mobile communication bugs. I'm like you in that I can't speak code but I know enough from hanging around on this website about why certain things mentioned there are vital and should not have the issues that they have (or used to before they were fixed). Clovermoss🍀 (talk) 15:26, 2 January 2023 (UTC)
Dlthewave, before the DiscussionTools project, there was no way to deal with the quite-indented issue you illuminate because of how unstructured our talk pages are (Flow would have solved this a decade ago...). It might be possible now with how DiscussionTools works, but there is some chunk of UI work that needs doing (I would guess this ends up something like how reddit works). That is phab:T116686.
Mobile having the same URL is phab:T214998. Maybe we'll get it another 5 years down the road. :')
Regarding "about this page" and the rest of "everything at the top of talk pages", I know that particular machinery is on its way out as a result of DiscussionTools taking over how talk pages work on mobile from MobileFrontend. phab:T319145 is probably the relevant task, though you can see some other children (I linked some below). This mobile link with dtenable=1 should be illustrative of what works in the future, which is most of it. For today, you can click the "Read as wiki page" button that should also show up toward the bottom of your mobile browser and then you'll get most of the reams of wikitext you might prefer at the top of the page -- it's more than you might prefer, even :). Collapsing doesn't work on mobile currently, see phab:T323639 for the mobile talk page solution (side note, I'm sad-annoyed that Matma Rex got some objections to adding mw-collapsible on all of mobile that look to me like perfection being enemy of the good). The WikiProjects are missing there but only at narrow width, probably related to what the stack of CSS related to Template:WikiProject banner shell/styles.css is doing reacting with the CSS on mobile (most likely and specifically the assumptions about tables that mobile makes) and/or the fact mw-collapsible doesn't work on mobile, so that's something to look into (double ping Matma Rex just to draw eyeballs to your user name). Izno (talk) 06:05, 2 January 2023 (UTC)
The WikiProjects are missing there but only at narrow width… It's because of the height: 0; rule at Template:WPBannerMeta/styles.css. I don't know what is the purpose of it. I was going to submit an edit request to remove it after the collapsing is fixed (so that it'd be easier to explain), but feel free to remove it now since it seems you already understand it better than I do and don't need my explanation ;) Matma Rex talk 13:22, 2 January 2023 (UTC)
Testing on Template:WikiProject banner shell/testcases by just removing the height in console with a banner both inside and outside the shell does seem to indicate that there isn't any value to the rule, indeed. I can't think of another reason for it to exist, and it was suspect when I moved these over to TemplateStyles (which is why I know how these work :). Put it down to unmarked Internet Explorer legacy. I'll make the adjustment. Izno (talk) 18:26, 2 January 2023 (UTC)
Izno, I'm glad to hear that a solution is in the works. I'm more concerned about ensuring that new editors are seeing these notices on the default version of the page, rather than finding a workaround for myself. The dtenable=1 version looks much better and perhaps this should appear on the main Talk page rather than the "learn more" click-through. –dlthewave ☎ 21:24, 2 January 2023 (UTC)
Dlthewave, yes, dtenable is expected to be the final version meaning the default, DT just isn't "live" yet. Hence my linking to the task which I think will be closed when it is, but you can follow the others if you wish. Izno (talk) 21:26, 2 January 2023 (UTC)
  • Back when I started to edit exclusively on mobile, I did try out the app (on Android) and it was so hard as I can't figure out where things go, so I switched out quickly to edit on browser. You have more patience than me to stick with it. My editing experience on mobile has been quite smooth, except the part where I used to have to switch to desktop version to fully access the settings page, which is just bizarre. I agree with the comment above, it used to annoy me when people randomly archive talk pages to clean up old discussions when it means it becomes inaccessible to me, well, until I figured out I can just type Talk:Articlename/Archive on the search bar to look at it. Nowadays, the template editors people did some work to make the talk page header box thing to appear on mobile, so I can finally just click on the links. Lulusword (talk) 23:25, 1 January 2023 (UTC)
    I just don't try editing WP on the road anymore. I'm generally using WikiShootMe and Commons App, for finding photography targets and uploading the pictures. Sometimes I need more information about the target, and that means reading WP. Sometimes the target isn't at the specified coordinates, so I have to edit Wikidata, which is almost as difficult as editing WP. Seems to me, WD is a technically much simpler Website, unencrusted with Templates and other antiquated weirdness. That suggests that making a good WD app, or combined Commons/WD app, would be easier. But less in demand, I guess. Jim.henderson (talk) 00:22, 2 January 2023 (UTC)
    The template editors people (I am directly implicated) had to wait for WMF to do a couple things, so you can thank them for that too. :) phab:T312309 and phab:T257394. Izno (talk) 05:14, 2 January 2023 (UTC)
    Oddly, I'm still not seeing the talk header and archive links here. –dlthewave ☎ 06:00, 2 January 2023 (UTC)
    See above. :) Izno (talk) 06:07, 2 January 2023 (UTC)
    I can see it, maybe because I turn on the "advance mobile edit" feature? But the wikiproject box does not display properly at all as Izno already mentioned somewhere above. *shrug* Lulusword (talk) 10:38, 2 January 2023 (UTC)
    It seems to be "view as Wiki page" that makes the headers show properly. Perhaps this should be the default view. –dlthewave ☎ 21:28, 2 January 2023 (UTC)
    I can barely follow the conversation on the links you provided because I don't speak code at all T.T but genuinely many thanks all around to everyone who work hard to make wikipedia accessible to everyone :) Lulusword (talk) 10:38, 2 January 2023 (UTC)
  • I don't think it can be emphasised enough how unusual it is to have such a non-functional app with tens of millions of users, run by the Foundation that hosts one of the most-visited websites in the world, which has an eight-figure revenue and expenditure. But, as this essay makes clear, it's not the fault of those who are tasked on working on it—who are often responsive to volunteers. It's the extremely strange direction of expansion of the WMF, which leaves critical technical infrastructure under the purview of a small number of employees. We have a WMF that is obsessed with saying the right things on diversity, and sometimes in pouring lots of money into what they believe the solution is. But the solution is not that complicated: good mobile editing infrastructure is needed for most people in Asia, Africa or Latin America to have any opportunity to contribute to Wikipedia, and skilled editors from these regions would naturally make our articles more diverse in content. — Bilorv (talk) 22:08, 2 January 2023 (UTC)
    If it's not complicated, go and do it. It's easy to critique, go change it. I'll just remind you that WMF added things like mobile uploads and then the community freaked out and told them to turn it off. —TheDJ (talk • contribs) 09:15, 3 January 2023 (UTC)
    Is "then the community freaked out" referring to c:Commons:Village pump/Archive/2013/04#Missing author/source parameters on mobile uploads: fix coming? Anomie⚔ 12:47, 3 January 2023 (UTC)
    No, this was what was sometimes referred to as "selfiegate". Aka, give ppl a button to upload on a mobile device and lots of ppl try it out and make selfies and you get a lot of crap uploads. So many that the community got the feature removed as they didnt want / were not able to patrol it. It was around that timeframe, i'll see if i can find something back in phabricator about it. —TheDJ (talk • contribs) 10:40, 4 January 2023 (UTC)
    In that case, could the button only be shown to autoconfirmed users? (On desktop, too, this would seem advantageous from what I've seen at AFC and NPP.) — Bilorv (talk) 11:43, 4 January 2023 (UTC)
    I'm not sure if it's the WMF, the community or both (that Commons:VPP discussion is eye-opening) but it seems like the people making decisions about the mobile experience are treating it as a casual, non-essential secondary means of access for when we're away from our computers while actual contributors are more likely to use a phone or tablet as their primary device and may not even have easy access to a computer. There seems to be a lot of hand-wringing about working with limited screen space, which doesn't seem to be a problem for organizations like banks that manage to fit complex transactions and lengthy disclosures into mobile apps with no issue. –dlthewave ☎ 17:30, 3 January 2023 (UTC)
  • In my short time here (as a mobile view editor), I find such disconnects in the user experience quite frustrating. I suspect, at this point, most unregistered readers are accessing the site on their phones, but most editors are shoe-horned into a desktop editor that does not actually preview for the mobile reader? (Perhaps I'm not understanding this situation and don't know the actual stats.) This limitation on editing seems exist because none of the desktop skins have editing interfaces that are responsive (flow to screen size)? This seems strange to me, that the "new" skins are so hostile to mobile editing interactions in general. Anyway, again with the caveat that these are just my "impressions" and I don't really know what's going on, I just find it all very strange for such a well-funded site full of extremely smart, "very online" people. — LumonRedacts 04:40, 3 January 2023 (UTC)
    You understand the quantity page views correctly. Last quarter, for 29.7 billion user page views, desktop was 35%, mobile was 63%, and app views were the remaining 2%. Those numbers have held relatively steady for a year or three at this point. Izno (talk) 04:50, 3 January 2023 (UTC)
  • I think the statistics for app pageviews could be inaccurate.

Looking at your talk page natively in the app does not count as a pageview, since we’re using the DiscussionTools API to get the contents of the conversations. We will talk to the Editing team to see if querying the DiscussionTools API should count as a pageview.

— JTanner (WMF), 13:55, 16 August 2022
This was part of a larger response to my observation that changes I had already seen in my watchlist were not "seen" when I switched to desktop/mobile. I would look at my watchlist and see an edit to my own talk page as an "unseen change" (which is what one of the screenshots in this essay demonstrates). I don't know how much this might affect normal pageview statistics but it sounds like it's possible that there's greater visibility on the app than people may realize. Clovermoss🍀 (talk) 12:53, 3 January 2023 (UTC)
For the month of December, talk page views on mobile web were non-existent in the top 100 pages (I turned off the option to consider only main space views). Views are dominated first by the main page (apparently), secondly by search, and then whatever's in the news. I would expect page views for mobile app to follow the same trend. Izno (talk) 17:19, 3 January 2023 (UTC)
@Izno: So is it just talk page views that are affected? It wasn't just my edits to talk pages that would show up as unseen changes in my watchlist, that was just an example I was using. This led to my concern that there may be a broader impact to inaccurate pageview statistics regarding the app. At least on specific devices like the one I was using at the time. There was an issue with my old phone not being able to copy diffs because the option just didn't show up. The response I got was that they test how things work on 10 devices which is apparently above average for similar websites. It sounded low to me, but again, I don't know how this stuff works. Even with my new phone (a Pixel 6a), you can't see diffs when they are linked. They just show up as blank space. This was an issue with my old phone too and I'm wondering if this is what is meant to happen.
The issue with not being able to copy diffs was eventually fixed with my old phone because I brought it up but I guess it prompted this distrust that these things may not be consistent across devices since it worked on her phone and she seemed surprised that it didn't work on mine? I was using a Samsung Galaxy J2 before if that matters. Maybe there's not much to be done to fix technical issues for older devices but it might be worth trying given what Bilorv stated. Not everyone can afford a new phone.
To try and make my thoughts more clear, what I'm saying is that even if talk page views weren't supposed to count for everyone, is it possible pageview statistics are inaccurate even when they are meant to be counted? Or is that a question you can't speculate/give an answer on? Clovermoss🍀 (talk) 01:23, 4 January 2023 (UTC)
@Clovermoss: This led to my concern that there may be a broader impact to inaccurate pageview statistics regarding the app. I don't personally believe that's a significant concern. For a few reasons:
  1. The issues you mention (diff problems, talk page edits, etc.) are editing difficulties, and edits as a whole are a vanishingly small percentage of pageviews. It's a big leap to extrapolate difficulties experienced with mobile editing into difficulties with mobile viewing.
  2. If you turn on the "Show mobile percentages" column of our topviews stats (like the list Izno linked to), some of the most-viewed pages are over ninety-eight percent mobile viewers. (In December, XXX: Return of Xander Cage had 4.93M pageviews, 99% of which were mobile!) If mobile pageviews were being either systematically or significantly undercounted, there's just no way that would be the case.
The mobile editing experience is poorer because it's harder, and because a lot of it comes down to there being no [easy|good] solutions to problems like the ones you've described. For any site, not just Wikipedia. There's a reason web developers in general don't work on their phones much: It's simply a bad platform for editing... well, most things, really, but existing, formatted text or mixed-media content in particular. Sure, we all use our devices to read web content, and we may use them to write site comments, emails, even the occasional letter, report, or blog post. But creating content on a blank page is significantly easier than editing existing content, something rarely done from mobile devices because it sucks to do from mobile devices.
I don't personally believe the solution to that is as simple as improving the tools. There's an implicit assumption there that a device as small as a phone, with no physical keyboard, is capable of providing adequate tools for the task. My counter-argument is: the devices have been steadily improving for fifteen years now. They're endlessly faster, smarter, provide better and better feedback, and at this point even mid-range models have such high-resolution displays that they've long since stopped rendering content at pixel resolution, because it'd be too tiny to make out. Yet, the experience of editing Wikipedia pages, or anything else, on them isn't significantly improved from what it was like a decade ago.
I also definitely don't believe that the issue is in any way that, as you say: This limitation on editing seems exist because none of the desktop skins have editing interfaces that are responsive (flow to screen size)? The desktop edit interface is not suited for a device as small as a phone. It's questionable how useful it is even at tablet sizes. To be useful, a mobile editor needs a radically different interface, not a responsive interface. Responsive content can work for viewing (though I'll be the first to say, Wikipedia's content is definitely still lacking on that front), but it's no solution at all for editing.
Google Docs or Microsoft Word, as two random examples, don't just squeeze their desktop interface down to fit on mobile devices. They have a completely separate application for editing content, built from the ground up as a mobile platform, that bears almost no resemblance to the editing interface they provide on the desktop (or in a desktop browser). Same documents, but completely different editing interface. And despite that, they're also still severely limited in just how much you can do when editing on a mobile device, vs. the full desktop experience. (Plus, neither comes even close to tackling tricky content problems like our citation templates, or editing hidden/auto-formatted content like that in general, really.) FeRDNYC (talk) 11:55, 4 January 2023 (UTC)
@FeRDNYC: I appreciate the breaking down why the pageview scenerio is implausible. What I'm confused about is the second quote that you disagree with me on because I didn't say that. Clovermoss🍀 (talk) 12:08, 4 January 2023 (UTC)
Mobile editing is never going to be as easy as editing from a desktop, and editing from a desktop is disadvantageous to editing with two desktop screens. But the Android app's capabilities are nowhere near the limitations of its medium, not when a single user reporting their issues leads to a dozen Phabricator major tickets. Just as the word processors you've named are redesigned for mobile, we need a redesign with mobile users in mind. — Bilorv (talk) 12:31, 4 January 2023 (UTC)
Hi, @FeRDNYC:: Regarding I also definitely don't believe that the issue is in any way that, as you say: This limitation on editing seems exist because none of the desktop skins have editing interfaces that are responsive (flow to screen size)? The desktop edit interface is not suited for a device as small as a phone. It's questionable how useful it is even at tablet sizes. To be useful, a mobile editor needs a radically different interface, not a responsive interface. Responsive content can work for viewing (though I'll be the first to say, Wikipedia's content is definitely still lacking on that front), but it's no solution at all for editing. This was me. I made this comment because it seems like many (some?) editors are using the desktop view on a smaller device in landscape mode as described in the often-mentioned essay by Cullen328. This suggests to me that the desktop interface could use a little "responsiveness" so that could be used in portrait mode, which for phones is a more natural way to type (IMHO). I did not intend to suggest that the whole mobile editing thing didn't need a "radically different interface," to which I do agree, but I lack the understanding to suggest exactly what in detail (without sounding totally bonkers). Is "making the desktop view flow better" just a band-aid? Oh absolutely, but there doesn't seem to be much political will (again I'm not sure who is "in charge" of this anyway) for a radical redesign of the mobile view editing interface. And maybe it's really this lack of political will that I find perplexing. Still, all food for thought! Cheers! — LumonRedacts 14:14, 4 January 2023 (UTC)
@Clovermoss I think other (non-talk) page views from mobile apps are being counted correctly, even though they use a different method than desktop/mobile web page views, which is why the watchlist doesn't know you've seen those pages. I looked around on Phabricator for known issues and it seems it has been buggy in the past, but it has been fixed – most recently in 2020 in task T256508. Matma Rex talk 14:20, 4 January 2023 (UTC)
  • Thanks for this interesting and useful article. Jahaza (talk) 16:44, 3 January 2023 (UTC)
  • Another thank you for the good article. I've been editing Wikipedia on and off for almost 20 years. There's a marked decrease in my edits somewhere in the middle there when I stopped being a person who sits a computer desk all day. Editing on mobile used to be nigh well impossible. It's better now, but odd and obviously the second-tier priority. I've gotten the hang of it and can now create or edit articles readily. I am a 100 percent mobile editor and expect to be for the foreseeable future. More support for mobile editors please! And a related report while I'm here--I think there is still no mobile option for uploading images to Wikipedia (rather than Wikimedia). I always get shunted to the desktop site which is fine but dang it's hard on my old-lady eyes to navigate around that page when I'm trying to upload a fair-use book cover or what have you. Thanks for surfacing this issue OP! jengod (talk) 20:22, 3 January 2023 (UTC)
  • User:Clovermoss, there are quite a few experienced editors who edit from the app regularly. It's just hard to find each other, if you don't go looking for others. I could name User:Gorrrillla5, User:Epolk, User:Llew Mawr, User:Dhammapala Tan, User:Plorpy, and User:Blainster among the recently active Android app editors. Maybe you all should band together as a new WP:WikiProject? Or all of you put Help:Mobile access or Wikipedia:WikiProject Apps on your watchlists, so it's easier for you to find each other? Whatamidoing (WMF) (talk) 01:15, 5 January 2023 (UTC)
  • I hope some of the people you pinged join in this discussion, then. I'd be interested in other people's experiences with the app, especially if they've been using it longer than the 6 months I have been. Afterall, I'm just one person so there's likely aspects I haven't experienced or perspectives I haven't considered. Clovermoss🍀 (talk) 03:36, 5 January 2023 (UTC)
    Hello Clovermoss, it’s great to hear from you again in this fantastic post!
    This is Amal Ramadan, the community relations specialist; JTannerWMF mentioned me previously in your earliest post, and I am delighted that I have the opportunity to engage with you and those interested in apps in conversations like this one.
    Just wanted to give you an idea of the status of some of the items that haven’t been completed based on your table:
    All of our users' comments and feedback are welcomed all the time; that’s why we are starting a mega chore wheel that will include a summary of the received feedback and suggested features from the users; hoping the above is helpful to you. Feel free to contact us at any time 🙂 ARamadan-WMF (talk) 13:03, 1 February 2023 (UTC)
    Also, we are working on preparing tools and flagged pages where you all can send your feedback and thoughts alongside our support emails and reviews on the play and app store.
    And we will announce the next office hour that will be held with the apps team and users in the upcoming weeks. ARamadan-WMF (talk) 13:11, 3 February 2023 (UTC)
  • Hello all, We're having the first office hour for Wikipedia's apps team on the 24th of March 2023; Please check this link for the full details and information and let me know if you have any questions.
We would love to see you all! ARamadan-WMF (talk) 08:23, 7 March 2023 (UTC)
  • Hello all, Wikipedia's apps now have a newsletter; subscribe for the updated roadmap, office hours, and Wikiconferences news! — Preceding unsigned comment added by ARamadan-WMF (talk • contribs) 14:47, 31 March 2023 (UTC)
  • I prefer editing on a desktop as it gives me access to all the custom editing tools. However, like Jengod, I moved into a career that no longer allows me the hours I had sitting at a desk. The app is very limited in what it can do but it still allows some contributions to be made so I use it to do simple edits such as spelling and grammar changes, adding unit conversion templates, article descriptions, etc. It keep me sane while I am sitting and waiting for things to happen while I am at work. : D. epolk (talk) 04:51, 5 January 2023 (UTC)
  • Thanks for this insightful article and a valuable discussion. I have been accessing Wikipedia on mobile since it was available on WAP via a third party some 15 years ago and am much grateful for the opportunity to edit it with a dedicated Wikimedia app. Currently, I use it when I don't have easy access to a personal computer, which is rather often. I find it more neat than accessing Wikipedia with mobile Chrome (which crashes a lot and also mangles wikitext lines in the edit view), which is why I prefer it for writing text but using the desktop version in Chrome still surpasses it in speed of editing and access to editing possibilities. What I am hardly missing at the moment is the option to view changes (diff) before publishing the edit (there is only the option to preview the article), sometimes there is no option to preview at all, and I also think the 'revert' button should be placed to a standard position. At the moment, it occurs at random positions when scrolling the watchlist or Recent changes so it is easy to misclick it. Some spellchecker would be a nice addition too. I'm also missing some iOS demos or at least printscreens in the documentation to check whether system messages have been translated correctly. Though the latter applies to all Wikimedia software, not only mobile. --TadejM my talk 05:56, 8 January 2023 (UTC)
  • This is a wonderful read! Maybe first time desktop users could be shown a message stating that adapting to mobile editing later on may be difficult or impossible. FacetsOfNonStickPans (talk) 12:33, 10 January 2023 (UTC)

Mobile feature request

Mobile feature request: I would like disambiguation page links to show up in orange font on mobile like they do on the desktop site. Please and thank you. best, jengod (talk) 15:21, 1 February 2023 (UTC)

The apps' online meeting in October 2023

Hello!

Following these productive discussions regarding the utilization of Wikipedia mobile apps, I would like to extend an invitation to you to an online meeting with the mobile apps team. It will take place on the 27th of October at 5 p.m. UTC (check your zone’s exact time).

The host will be Jazmin Tanner, the product manager of the apps team, with a number of our software engineers; you can join the meeting from the following:

https://wikimedia.zoom.us/j/83695206107

Feel free to share your questions and thoughts about Wikipedia’s mobile apps on the Wikimedia Apps/Office Hours page on mediawiki.org. We would love to hear from you. The last date to add your input will be on the 24th of October at 12:00 UTC.

If you’d like a one-day reminder before the meeting, simply add your username, and I’ll send you one.

We will be waiting for you all!

ARamadan-WMF (talk) 10:58, 21 September 2023 (UTC)

Featured content: Would you like to swing on a star? (594 bytes · 💬)

  • The thrush and Gilbert pictures are really exceptional, good to see them! —Ganesha811 (talk) 13:35, 1 January 2023 (UTC)
  • Adam, if there is some way that the FACBot can assist you in preparing the page, I can make the required changes. Hawkeye7 (discuss) 22:56, 1 January 2023 (UTC)

From the archives: Five, ten, and fifteen years ago (0 bytes · 💬)

Wikipedia talk:Wikipedia Signpost/2023-01-01/From the archives

In the media: Odd bedfellows, Elon and Jimbo, reliable sources for divorces, and more (14,127 bytes · 💬)

Russian troops

No doubt many Russian soldiers are suffering from poor or absent training, but the presence of a Wikipedia printout seems rather slim evidence that the carrier of the sniper rifle knew nothing else about the weapon. Alternatives include his being a competent practitioner, and merely curious about what information was publicly available about his equipment. Had similar evidence been found half a century ago on my body, then indeed, I was briefly a soldier of very little military value, but in other parts of life I have been interested in what laymen knew about my areas of competence. Jim.henderson (talk) 07:08, 1 January 2023 (UTC)

Meloni article

The Giorgia Meloni Daily Dot article [2] was interesting. "The difference is especially glaring when compared to the English, French, German and Spanish versions of the same articles." It's not the first time media has noticed similar things. Gråbergs Gråa Sång (talk) 19:38, 1 January 2023 (UTC)

Journalism Competition and Preservation Act

Odd that we don't have an article for the Journalism Competition and Preservation Act at the time of writing. We do have an article on the Australian version of the law, the News Media Bargaining Code – which unlike the US version was implemented. (The US bill was not taken forward at this time, but may make a comeback later this year.)

For what it's worth, The Intercept opined: Google and Meta are pouring money into two, seemingly contradictory messages in an effort to defeat it. The full-court strategy plays on left- and right-wing concerns about social media: According to the messaging, the JCPA is simultaneously a legislative proposal backed by liberals to “silence conservative voices” and a far-right effort that will fund pro-Trump voices that are the source of “dangerous misinformation.” The exaggerated rhetoric was part of a larger campaign to stop any proposal to share advertising revenue, the main source of income for social media and search engine tech companies. The message designed to orchestrate Republican opposition to JCPA is sponsored by NetChoice, and the message designed to whip up Democratic opposition to JCPA is sponsored by the Computer and Communications Industry Association. Both organizations are funded by Google and Meta, Facebook’s parent company, and serve to influence lawmakers and the public on behalf of shared concerns by the two megacorporations.

The Editor & Publisher (linked in our article above) took a similar view: The JCPA represented an acknowledgment that two of the world’s wealthiest companies have made billions of dollars off the work of journalists and their publications. It was a chance to offer an exemption to an antitrust law whose relevance is tied to a bygone era when profitable newspaper empires could threaten the flow of information. Today, the problem has shifted. A duopoly controls the flow of much of the free world’s information. Other countries are changing that. Why isn’t America? --Andreas JN466 20:15, 1 January 2023 (UTC)

Mandel story

Look ma, I made the Signpost! (I am "Wikipedian Hayden Schiff"). I didn't realize she had already attempted a COI request. I can see more clearly now how this one slipped through the cracks; the person responding to her request didn't know that they were talking to Mandel herself, so they couldn't know to provide the information that she could simply post a tweet or whatever. I'd sure like if we could somehow make this process better so a tough situation like this doesn't arise again (imagine if it had been a much less famous figure and/or one who didn't have a well-followed social media account), but I'm not sure what could have prevented this particular situation. –IagoQnsi (talk) 20:44, 1 January 2023 (UTC)

I've been thinking for a while that our instructions to BLPs looking to fix/update their articles leaves a ton to be desired. {{u|Sdkb}} talk 20:58, 1 January 2023 (UTC)
LPs ... articles do not ask to be improved, the people they are about do. Daniel Case (talk) 22:05, 2 January 2023 (UTC)

Speaking as a Wikipedian who has been active here longer than over 98% of the rest of you, I would have handled the matter differently than it had been: the request was reasonably presented & I would have added this information, invoking WP:IAR if needed to quash this stupid editorial decision. Sheesh, how else is the average person supposed to prove to us that they've been divorced? The entire reason use of primary sources is discouraged is to avoid original synthesis or opinion, not to prevent providing a source for falsifiable statements. Someone who does not understand that distinction harms this project more than helps it.

And I would also go further to state that concerning a few details of a person's life -- including date of birth, educational history, marriage status -- the subject should be presumed correct unless proven to be an unreliable source. (Thinking here of George Santos, who may not even be an American citizen.) -- llywrch (talk) 03:15, 2 January 2023 (UTC)

I don't think it was a stupid editorial decision/reply to edit request, since mine would have been much the same, though I like to think I would have mentioned a potentional WP:ABOUTSELF solution, since the requester hinted that they had (at least) some sort of contact with the subject. However, another editorial decision was soon made:[3]. Others followed. I don't know if a WP:VRT solution would have been possible, but the question became moot fairly quickly.
Personally I'm a bit unflexible about WP:BLP, and a suggestion to use WP:BLPPRIMARY is by default probably bad in my head. Others have mentioned that the request in itself made it reasonable to remove the marriage-info at least for the time being. That didn't occur to me, but I wouldn't have opposed it. I think WP:ABOUTSELF sources can be fine for DOB and marriage status, but I'm not at all sure about education. Gråbergs Gråa Sång (talk) 11:11, 2 January 2023 (UTC)
@Gråbergs Gråa Sång and Llywrch: Date of birth is occasionally fraught. As it happens, just last week there was an article in the Frankfurter Allgemeine Zeitung reporting that a lady claimed she was born in 1969, not 1964, and even had a lawyer send Wikimedia a letter saying so, claiming the "wrong" date infringed her personality rights. However, some years back, the FAZ says, she had stated in a CV appended to her dissertation—which in parts allegedly plagiarised Wikipedia—that she was born in 1964, completed school in 1982, and so on.
Still, sources can be wrong. I was reminded the other day of the discussion at User_talk:Jimbo_Wales/Archive_86#"Verifiability_and_truth", which in due course led to the phrase "verifiability, not truth" being removed from the WP:Verifiability policy. As in that case, one possible solution is often to just omit content that is questionable. Jimmy talked a lot of sense there, as he usually does on BLP issues.
"Everything you read in newspapers is absolutely true, except for that rare story of which you happen to have first-hand knowledge." —Erwin Knoll
"What people outside do not appreciate is that a newspaper is like a soufflé, prepared in a hurry for immediate consumption. This of course is why whenever you read a newspaper account of some event of which you have personal knowledge it is nearly always inadequate or inaccurate. Journalists are as aware as anyone of this defect; it is simply that if the information is to reach as many readers as possible, something less than perfection has often to be accepted." —David E. H. Jones, in New Scientist, Vol. 26 Andreas JN466 15:08, 2 January 2023 (UTC)
Sure DOB/whatever can be wrong in sources, WP:ABOUTSELF or not. But per Wikipedia_talk:Biographies_of_living_persons/Archive_48#Tweets_announcing_"Happy_birthday_to_me!_I'm_21_today!", it's not my default assumption that it's wrong. When you show me an article from Frankfurter Allgemeine Zeitung saying that it's wrong, I'll probably change my assumption. Gråbergs Gråa Sång (talk) 15:35, 2 January 2023 (UTC)
I note that the German YOB-thing is mentioned in the German WP-article. Gråbergs Gråa Sång (talk) 15:51, 2 January 2023 (UTC)
The whole de.WP talk page reads like some sort of thriller novel. A source showing the 1964 birth date disappeared from the Internet Archive: "This URL has been excluded from the Wayback Machine." Another is still available here: [4] Tsk, tsk. Andreas JN466 16:18, 2 January 2023 (UTC)
@Gråbergs Gråa Sång:, the three items I mentioned almost always come ultimately from the subject, & in the vast majority of cases the subject has no reason to lie about those facts. An interviewer will ask the subject for these details, if relevant, or ask the subject's PR person -- who will receive the information from the subject. The same for a resume or CV: the subject will have generated the information. As for educational history, maybe an interviewer or researcher will verify the information. Or maybe they won't. And going beyond this source -- say investigating birth & marriage records -- is original research; so we are forced to trust the subject until a third party shows they should not be trusted on this subject. Nevertheless, you can be assured that for academics & politicians, their backgrounds are usually verified before they enter an election -- George Santos (whom I mentioned above) being an exception to this rule, & the truth of his background came out soon after his election. Some celebrities & businesspeople may get away with falsifying their past, but again that is beyond our scope to determine.

In short, unless a secondary source has shown the subject to be unreliable on those details, a person should be trusted on those details.

PS, I read the section Jayen466 linked to above in Jimmy Wales' talk archive, & I'm pleased to find his opinion is close to mine on this matter. The entire "Veracity not truth" slogan arose as a means to quash the objections of cranks who claim "Your published sources are not reliable. I want to include the truth!" As is the case with most, if not all, Wikipedia slogans it is an oversimplification that if followed literally leads to disastrous results. -- llywrch (talk) 07:04, 3 January 2023 (UTC)

If I then approach the education point from another angle. If you are writing a BLP, and come across the subject's education history at their official website (or an uploaded CV etc), would you then think it a good idea to include that history in the WP-article per WP:NPOV? Gråbergs Gråa Sång (talk) 10:32, 3 January 2023 (UTC)
I personally would accept anybody's statement of their own birthday, unless there is a reason that it seems suspicious (e.g. some actors or, with at least some evidence, that the person has misled the public before on any matter). In that case, I'd want to state in the body of the text that, "according to xyz they were born on DATE". But in general, as above, birthdays, education etc, are sourced by journalists to the person themself, with a thorough investigation seldom made. In some cases I'd say "according to xyz's official website (or CV) they earned the following degrees." Many journalist have some sense of when they are being lied to and may check in that case, that's part of the reason we consider their employers to be reliable sources. Or maybe an experienced editor will catch something that a newby journalist wouldn't. The old saying is "If your mother tells you she loves you, check it out." But in practice most journalists just wouldn't have the time for that. Smallbones(smalltalk) 16:05, 3 January 2023 (UTC)
I have been quick to correct reports of incorrect birthdates from the Olympians and Paralympians, as they can take this as Wikipedia accusing them of cheating. Hawkeye7 (discuss) 01:39, 10 January 2023 (UTC)

Interview: ComplexRational's RfA debrief (0 bytes · 💬)

Wikipedia talk:Wikipedia Signpost/2023-01-01/Interview

News and notes: Wikimedia Foundation ousts, bans quarter of Arabic Wikipedia admins (30,744 bytes · 💬)

  • If you want to see changes in the number admins on the English Wikipedia, go look at Wikipedia:Bureaucrats' noticeboard this evening. Liz Read! Talk! 03:49, 1 January 2023 (UTC)
    • I think Liz is referring to the 97 de-sysops today under criterion 2 listed at Wikipedia:Inactive administrators/2023#January 2023. ☆ Bri (talk) 04:12, 1 January 2023 (UTC)
      • Yep. I knew it was going to happen on January 1st but I didn't expect to be watching it happen in process at the stroke of midnight UTC time. Turns out, it's a lot of work to desysop that many administrators so thanks to Xaosflux for spending his New Year's Eve handling bureaucratic work. Liz Read! Talk! 04:35, 1 January 2023 (UTC)
  • Looks like I've gotta keep working as an administrator for another 22 years. If I can make it that long without getting banned by the WMF. LOL Happy New Year wbm1058 (talk) 13:39, 1 January 2023 (UTC)
    Does anyone know who is the longest servibng but still active admin on Wikipedia? Hawkeye7 (discuss) 01:41, 10 January 2023 (UTC)
    Could it be Anthere, admin since 31 May 2002 circa June 2003? That's the first one I could find at the RfA page history. However there may be one or more who predated the creation of that page. ☆ Bri (talk) 04:19, 10 January 2023 (UTC)
    Nope, it must be Deb via that process circa 14 June 2003 [5]. Still, could be someone predating the RfA page. ☆ Bri (talk) 04:39, 10 January 2023 (UTC)
    Found a new candidate via wikien-l, 13 May 2003: The Anome ☆ Bri (talk) 05:35, 10 January 2023 (UTC)
    Found another candidate via NoSeptember's "early admins" list: AxelBoldt – after July 2001? no mail list confirmation. ☆ Bri (talk) 05:55, 10 January 2023 (UTC)
    Found another candidate via the mail list. Tim Starling sysop since 24 March 2003. This is the earliest sysop I can find, who is still active, with confirmation of the sysop date. ☆ Bri (talk) 17:37, 10 January 2023 (UTC)
    Is this list any good for your query? Andreas JN466 01:26, 11 January 2023 (UTC)
    Wow. Thank you everyone! Gosh, that is almost unbelievable. Hawkeye7 (discuss) 01:47, 11 January 2023 (UTC)
    Unfortunately, the machine-generated list doesn't tell you who is currently active i.e. listed at WP:List of administrators/Active. ☆ Bri (talk) 03:06, 11 January 2023 (UTC)
  • There is an easy way of fixing this problem, copy the way Wikipedia in Swedish and Norwegian Bokmål work regarding admins. First, change from electing admins for life-time, to a fixed period. Second, make it easy to be admin. As in Wikipedia in Norwegian Bokmål, the criteria for being elected is quite low (must have participated for at least four months, must have a userpage and at least 1000 edits and being possible to reach by email + general knowledge about how things work). Ulflarsen (talk) 13:59, 1 January 2023 (UTC)
    That would be quite a radical change, Ulflarsen. I'll just say that years (and blood and sweat) have been spent over the last decade to reform the RfA system but there is strong opposition to lowering the bar. Actually, I don't think the technical bar for simple eligibility is that high, it's the standards of what those voting in RfAs require that might be too high. You can change the system but if the editors participating in RfAs require, hypothetically, 20,000 edits and 2 years of active editing at a minimum to support an RfA candidate, then it doesn't really matter what the eligibility rules are. The culture would have to change and I think that is a lot more difficult to do than having an RFC and changing the eligibility requirements. Liz Read! Talk! 23:22, 1 January 2023 (UTC)
    Don't forget the first step, "First, change from electing admins for life-time, to a fixed period." This is the step that makes the second step (no big deal) possible. That first step has been proposed and was overwhelmingly opposed by admins who want it to remain a lifetime appointment. I'm glad we've dropped 100 admins, and if that keeps up, we might get a clean vote on lifetime appointments (that is, a vote not dominated by editors who have a COI because they'd be desysopped if the proposal passes) at some point, and actually be able to make it no big deal and recruit more. Until then, legacy admins will continue to dominate RFA reform RFCs on enwiki. Levivich (talk) 20:25, 5 January 2023 (UTC)
    In the 2021 RfC Wikipedia:Requests for comment/Adminship term length, 54% of commenters were non-admins and as far I recall, never have been admins, 3% were former admins, and 43% were admins. Taking just the non-admin viewpoints, 60% opposed the proposal and 40% supported. (There were 3 former admins; 2 who opposed and 1 who supported.) Looking at the admin viewpoints, 86% opposed and 14% supported. I don't think it's fair to assume that all of the participating admins who opposed were primarily driven by personal motivations, versus concern over the end effect on the Wikipedia community as a whole. All the same, passage of the proposal was not prevented by admins. isaacl (talk) 04:41, 11 January 2023 (UTC)
  • Further details concerning the reasons Admins on the Arabic & Persian Wikipedias were banned would be useful: few of us have any knowledge of events over there. Otherwise, this may degrade into FRAM2. (Note: I am not speaking in support or against this action -- I simply would like to know more details. If their actions were consistently harmful to those projects, then ample examples should be easy to be provided without risking harm to anyone.) -- llywrch (talk) 02:51, 2 January 2023 (UTC)
    It seems like several may have been participants in a Saudi influence operation; I've encountered one of their paid editors here on ENWP, although he declared his COI and, compared to most paid editors, was quite agreeable to work with. That said, I have no more information than you have, and I doubt what I suggest is the full story. —Compassionate727 (T·C) 14:59, 2 January 2023 (UTC)
    This piece could have done with a lot more investigation. Unfortunately, the timing was rather unfortunate ... not the sort of thing people want to do over Christmas. For reference, if anyone wants to dig in, earlier versions of this Signpost page had links to the accounts' contributions histories in various projects (copied in the box below).
The banned accounts' contributions histories across various Wikimedia projects
The following discussion has been closed. Please do not modify it.
As one often finds in such cases, many of their contributions were actually perfectly fine, and valuable. Andreas JN466 15:30, 2 January 2023 (UTC)
I heard about User talk:OsamaK/January 2023#Sad news yesterday. Might be related to this and to the recent MENA news as well. There's your tip for next month, Signpost. Izno (talk) 18:59, 2 January 2023 (UTC)
I'd love to hear more about OsamaK. Please email me here if you have any tips or info. The 1st email is confidential - then we can discuss it. I suppose I'm the best known Signposter for doing such investigations, but I have to tell you that there is a lot of time and luck involved in coming up with a good story, e.g. I did several stories on a Mainland China/Hong Kong dispute like this. I got tipped off early by somebody I'd never expect (not in the WMF or admin corps - they seldom if ever give me good tips!). I did have some contacts from a previous story, but most of the info came from sending emails to people I thought might know somebody who knew something about it, and asking them to forward my email to those somebodies. So I never knew who suggested they contact me. Several people did contact me, but I don't expect that to happen usually. I still had to spend 3 weeks getting the story and wasn't sure I had anything that could be published until the day of publication. In short - it takes a lot of time and luck. There are probably 2 or 3 other experienced Signposters who might be able to do this better. Contact your favorite one if you want. Smallbones(smalltalk) 17:35, 3 January 2023 (UTC)
Unfortunately I am not surprised. While researching this for publication it was apparent to me that there was likely to be some kind of unsettling connection to a Middle East security service. ☆ Bri (talk) 03:07, 4 January 2023 (UTC)
Guardian report today: https://www.theguardian.com/technology/2023/jan/05/saudi-arabia-jails-two-wikipedia-staff-in-bid-to-control-content Andreas JN466 01:48, 6 January 2023 (UTC)
https://dawnmena.org/saudi-arabia-government-agents-infiltrate-wikipedia-sentence-independent-wikipedia-administrators-to-prison/ Andreas JN466 01:48, 6 January 2023 (UTC)
For those watching from the sidelines, it appears that Specialized Criminal Court was involved in the trials; they usually handle state security including terrorism cases. ☆ Bri (talk) 02:04, 6 January 2023 (UTC)
@Andreas, the DAWN press-release claims that Wikimedia had terminated all of the administrators based out of S. Arabia! So, all of the admins, who were from S. Arabia, were agents of the state — ? WOW. I also wonder how did the news about the persecution of Osama Khaled and Ziyad al-Sofiani were hushed for over 2 years!
Besides, ar-wiki is a self-governing community and has many, if not most, editors who are sympathetic to S. Arabia (see the community response to the Office Action); what prevents them from electing some new agent to the admin/CU ranks? How does the Foundation plan to tackle the chilling atmosphere created in the ar-wiki for dissenters to the Saudi regime? This is a ripe topic for further coverage in the next Signpost. TrangaBellam (talk) 07:37, 6 January 2023 (UTC)
@TrangaBellam: That part, about all Saudi-based admins having been banned, was news to me too. At first I thought there must be some mistake. But the WMF will no doubt have realised that all Saudi-based admins are vulnerable to coercion. Given these sentences, it's not like any of them would have had a choice. (According to User:Gnangarra in the Wikimedia-l thread the two jailed admins were arrested in 2020, but only sentenced recently.)
What confuses me is that OsamaK stopped being listed as an admin sometime around 2016/2017 ([6][7]), years before he stopped editing. At the time he was jailed, he was not an admin as far as I can see. User:Ziad too stopped being listed as an admin around 2017/2018 ([8][9]).
This is an awful, heart-breaking situation. :( From the DAWN piece: "It's wildly irresponsible for international organizations and businesses to assume their affiliates can ever operate independently of, or safely from, Saudi government control." JN466 12:09, 6 January 2023 (UTC)
WMF will no doubt have realised that all Saudi-based admins are vulnerable to coercion
This is something that I thought of — the Foundation did not wish to attract scrutiny of the Saudi state on any admin who was not purged. However, if our explanation is correct, the Foundation appears to have defamed (not in a legal sense) atleast some editors in longstanding by accusing them of activities they were not involved in. I am not blaming the Foundation, fwiw; this is a tricky situation to be in.
Khaled appears to have been sentenced in 2021; the increase in the quantum of punishment (from 5 to 32 years) came in August/September 2022. TrangaBellam (talk) 13:11, 6 January 2023 (UTC)
Cryptic WMF statement now being quoted by Ars Technica: A Wikimedia spokesperson told Ars that there are “material inaccuracies in the statement released by SMEX/DAWN” and in a Guardian report. “There was no finding in our investigation that the Saudi government ‘infiltrated’ or penetrated Wikipedia’s highest ranks,” Wikimedia’s spokesperson told Ars. “And there are in fact no ‘ranks’ among Wikipedia admins. There was also no reference to Saudis acting under the influence of the Saudi government in our investigation. While we do not know where these volunteers actually reside, the bans of any volunteers who may have been Saudi were part of a much broader action globally banning 16 editors across the MENA region.” Andreas JN466 17:47, 6 January 2023 (UTC)
  • A few notes on the Coolest Tool awards:
    1. The names for the categories, according to meta:Coolest Tool Award#2022_Winners, are meant to be sentence-cased. ("Newbie friendly" and "Diversity", not "newbie friendly" and "diversity".)
    2. The Honorable mentions for "Created Articles" and "Wikibooks printable edition" were left off, for some reason.
    3. Some of the category names (e.g. Eggbeater - Tools in use for more than 10 years) are kind of impenetrable without the accompanying description. FeRDNYC (talk) 19:40, 2 January 2023 (UTC)
    (Actually I'm kind of confused, because on the Meta page, Citation Hunt and MoreMenu have categories as well — "Newbie friendly" and "Editor", respectively — and the category description for "Newbie friendly" is the same as for "Newcomer". I can assume that CH and MM were "overall" winners at rose from nominations in specific categories, but why would the same category have two different names?) FeRDNYC (talk) 19:58, 2 January 2023 (UTC)
  • FYI: The proposal statement from arwiki community ar:ويكيبيديا:بيان بشأن أحداث 6 ديسمبر 2022, which has a majority of support. --SCP-2000 06:18, 7 January 2023 (UTC)
    A strong majority: 38/2/0. Thanks. Andreas JN466 07:07, 7 January 2023 (UTC)
    Furthermore, the meeting minutes of arwiki community members met with WMF. The main point is: if local community want to have more transparency and insights, what they can do is to set up an Arbcom. SCP-2000 10:35, 8 January 2023 (UTC)
  • In a press release by Democracy for the Arab World Now, a non-profit organization, the ban of arwiki admins is connected to a supposed attempt by the Saudi Arabian government to recruit administrators in the course of prosecuting “those who contributed critical information about political detainees”. A connection is made in the press release to the arrest of two Wikipedians, OsamaK and Ziad in Saudia Arabia. It is interesting to note that at least two of the banned arwiki admins had checkuser privileges: [10], [11]. --AFBorchert (talk) 15:12, 7 January 2023 (UTC)
    Please note that according to the recent WMF response "There was no finding in our investigation that the Saudi government ‘infiltrated’ or penetrated Wikipedia’s highest ranks [...] There was also no reference to Saudis acting under the influence of the Saudi government in our investigation." --SCP-2000 17:31, 7 January 2023 (UTC)

Recent research: Graham's Hierarchy of Disagreement in talk page disputes (3,708 bytes · 💬)

It's amusing to read the sample discussion and see that

  1. It is a lame dispute about whether it should be "a herb" or "an herb"
  2. That the usage had been flipped before
  3. That the first three editors were Usernameistoosimilar, Deli nk and Jytdog who have all been indefinitely blocked for their sins.

So, the main problem is not where we stand on the tactical hierarchy of argument but whether we should be arguing at all. Wikipedia is infested with dysfunctional and unproductive editors – griefers, grinders, obsessive pedants, fanatics and more. In making mountains out of molehills, they are operating at a different level and this analysis fails to capture this more fundamental issue. As usual, further research is needed...

Andrew🐉(talk) 21:39, 1 January 2023 (UTC)

@Andrew Davidson: While the dispute certainly is lame, the correct reference for the conversation used as a sample is Talk:Fenugreek#A_herb/an_herb_2, which was started by Jytdog off of that previous discussion you linked to, and grew quite a bit more involved than that one (though no more productive, AFAICT). Neither Usernameistoosimilar nor Deli nk seem to have participated. It was basically just Jytdog and Porphyro going back, and forth, and back, and forth, and... well, it's long, is the point. FeRDNYC (talk) 14:37, 3 January 2023 (UTC)
That further discussion takes the lame to another level. And then there's a part 3 in which an edit notice is requested. And now, of course, we are digging deeper with this further derivative discussion...
Looking at the actual article, I notice that it doesn't mention that fenugreek was one of the ingredients in the original herbal formula of the famous Lily the Pink. I must edit the article myself and see what further mayhem ensues. WP:INTODARKNESS...
Andrew🐉(talk) 18:06, 3 January 2023 (UTC)
RIP Andrew Davidson, died on An Hill,[a] 3 January 2023. He will be missed.
  1. ^ SWIDT?
FeRDNYC (talk) 06:16, 4 January 2023 (UTC)
I fixed that link to the source discussion. Thanks! Regards, HaeB (talk) 12:15, 4 January 2023 (UTC)
So, I edited fenugreek to add some details of its use in Lydia E. Pinkham's Vegetable Compound. I had researched this reasonably well, finding a book about the history of the compound which detailed the recipe. I cited this but the entire addition was reverted with the edit summary, "Nonsense and WP:FRINGE". This seems to be name-calling at the bottom level of the hierarchy but so it goes. The next step may be to start an RfC... Andrew🐉(talk) 16:51, 7 January 2023 (UTC)

Serendipity: Wikipedia about FIFA World Cup 2022: quick, factual and critical (164 bytes · 💬)

Good page

Technology report: Wikimedia Foundation's Abstract Wikipedia project "at substantial risk of failure" (29,554 bytes · 💬)

Boards approve high level plans not detailed implementation. Doc James (talk · contribs · email) 06:21, 1 January 2023 (UTC)

  • I think the report's critiques of the current progress are fair and useful, but I'm actually glad that the WMF is taking a shot on the project. It might work out, it might not, but it's the kind of interesting, innovative idea that's well worth exploring. —Ganesha811 (talk) 13:21, 1 January 2023 (UTC)
  • For those reading this who might not be aware Doc James has extensive WMF Board experience and knows what he is talking about. Best, Barkeep49 (talk) 16:43, 1 January 2023 (UTC)
    • And in fact he was one of the Board members who approved the resolution in question.
      Speaking of the Board, one of the current trustees who appears to be most informed about the project may be the recently re-elected Shani, she has been conducting several interview-like conversations with Denny about it. This part (from May 2022) is interesting with regard to the question about the scope of Wikifunctions: In response to a question about what Wikifunctions is and why it is needed, Denny spends several minutes explaining the pedestrian Wikipedia-focused use cases like calculating a person's age, but never mentions the expansive vision of democratizing programming, providing a platform "where scientists and analysts could create models together", etc. Regards, HaeB (talk) 19:12, 1 January 2023 (UTC)
      This makes it sound like the full scope of Wikifunctions was somehow obscured or hidden. It never was.
      Here are quotes from the Introduction from the April 2020 paper: "Wikilambda is a wiki of functions. Functions take some input and return an output. [...] Wikilambda aims at making access to functions and writing and contributing new functions as simple as contributing to Wikipedia, thus aiming to create a comprehensive repository of algorithms and functions." Note that Wikilambda was the working name for the project, and was later changed by a community vote to Wikifunctions.
      The project plan which was presented to the community also introduced the new wiki project as "a project to create, catalog, and maintain an open library (or repository) of “functions”, which has many possible use cases." (see the proposal for a new sister project, May 2020 version) You can find the vision described in detail and its full extend already in the May 2020 overview page.
      Also the mostly weekly news updates frequently discuss the scope of functions, e.g. in its second edition, discussing the scope of functions, where we explicitly speak about democratizing functions; when introducing the mission statement, or when talking about inclusion despite math, or diversity and equity in programming.
      I think there are many valid criticisms that can be raised against Wikifunctions, but implying that we were hiding the "expansive vision of democratizing programming", either before the project started or during its ongoing development, is not one of them. --DVrandecic (WMF) (talk) 19:20, 2 January 2023 (UTC)

I'm always disappointed when a response is entirely defensive. It offers a terrible start at a dialog, if nothing else, and will predictably divide responses into polarized sides. I sympathize more with the critique than the response, myself, and so perhaps this isn't a neutral reaction, but I really wish the official foundation response had found opportunities to embrace criticism and a few opportunities to admit that a change in direction might be warranted. Ie, a "these are the critiques we feel are more valid" instead of a blanket "none of the critiques are valid". You don't have to agree, but offer a counterproposal at least. Doubling down on the original plan with no changes after the initial years experience seems to indicate management failure, regardless of the technical merits. No project survives initial implementation completely unchanged. C. Scott Ananian (talk) 15:43, 1 January 2023 (UTC)

I agree with you that it would be very disappointing if a response were entirely defensive. If I were to solely rely on The Signpost's reporting above, it might easily seem that way. Fortunately, the entire evaluation is available - and it is lengthy, as The Signpost correctly states. As we write in the response: "We have or plan to implement many of the recommendations the fellows have made regarding security, the function model, the system’s usability, etc. Many of those did not make it in either the evaluation or this answer, as both documents focused on the remaining differences, and less on the agreements."
There are a few recommendations we do not agree with. But with many we agreed, and we either already implemented them, sometimes together with the fellows, or have tasks on our task board to implement them, many before launch. --DVrandecic (WMF) (talk) 19:31, 2 January 2023 (UTC)
Denny, it's very disappointing to see you double down on such deceptive communications tactics here. I'm excerpting below here the full set of recommendations from m:Abstract Wikipedia/Google.org Fellows evaluation#Recommendations:

Wikifunctions

  • Wikifunctions should extend, augment, and refine the existing programming facilities in MediaWiki. The initial version should be a central wiki for common Lua code. [...]
  • Don’t invent a new programming language. [...] It is better to base the system on an existing, proven language.
  • The Z-Object system as currently conceived introduces a vast amount of complexity to the system. If Wikifunctions consolidates on a single implementation language (as we believe it should), much of the need for Z-Objects goes away. If there is a need to extend the native type system provided by the chosen implementation language, it should be with a minimal set of types, which should be specified in native code. They likely do not need to be modifiable on wiki.

Abstract Wikipedia

  • The design of the NLG system should start with a specification of the Abstract Content [...].
  • Rather than present to users a general-purpose computation system and programming environment, provide an environment specifically dedicated to authoring abstract content, grammars, and NLG renderers in a constrained formalism.
  • Converge on a single, coherent approach to NLG.
  • If possible, adopt an extant NLG system and build on it. One of two alternatives we mentioned above is Grammatical Framework, which already have a vibrant community of contributors.
  • Alternatively, create a new NLG system adapted to the scope and contributor-profile of Abstract Wikipedia, as previously suggested by Ariel Gutman
As far as I can see, you have dismissed every single of these 8 recommendations (three for Wikifunctions and five for Abstract Wikipedia). What's more, a CTRL-F through the entire document shows that these are the only statements that the authors refer to as "recommendations" (or where they use the term "recommend").
So Cscott seems quite correct in describing your reaction to the evaluation's criticism as a blanket rejection, at least with regard to the the resulting recommendations. The "many of" handwaving to obscure that fact and the goalpost-shifting (nobody had claimed that you had disagreed with every single thing the fellows had said outside this evaluation) really don't look good.
Regards, HaeB (talk) 21:20, 3 January 2023 (UTC)
@HaeB: Apologies. You are right, we indeed reject these eight recommendations. To explain what I meant: throughout the evaluation the fellows give many suggestions or proposals and raise many a good point, and of these, we accepted many. We have implemented many, and others are currently open tasks and planned to be implemented. I did express myself badly. I apologize for using the wrong word here. It is indeed an excellent point that, if a paper calls a section "Recommendations", that if I refer to recommendations, that it should mean the points in the recommendations, and not the generic sense of "things that are suggested throughout the paper". Sorry! --DVrandecic (WMF) (talk) 22:53, 4 January 2023 (UTC)

I feel like the team's response to the criticism kind of missed the mark. The criticism raised some risks, and then suggested some solutions. The response seemed to focus on the suggested solutions and why they didn't go with them originally, which isn't what i would call the meat of the criticism. The meat of the criticism comes down to pretty generic concerns - too much waterfall, not agile enough (e.g Trying to do everything all at once), too much NIH syndrome, too much scope creep, not enough focus on an MVP. These are all very common project management risks to focus on in the tech world, and there are many solutions. The critics suggest one possible thing to do, but certainly not the only things possible. I would expect a response to something like this talk about how those risks will be mitigated (or dispute the significance of these risks), not just talk about how they don't like one potential solution. I also am pretty unconvinced with the appeal to avoid cultural bias. Not because i dont think that is important, but because it is being treated as a binary instead of something to minimize. Yes, its an important thing to try to reduce, but you will never fully eliminate as everything anyone done is informed by cultural context. It is a risk that needs to be balanced against other risks. You can't think of it as something to eliminate entirely as the only way to do that is to do nothing at all. Bawolff (talk) 22:05, 1 January 2023 (UTC)

These are great points, thank you. The response indeed focused very much on the points of disagreement, and not so much on the agreements. A lot of the things we agreed with have already been implemented, or are in the course of being implemented. This particularly includes the project management risks you call out. It is, for example, thanks to the fellows that we refocused, which allowed us to launch the Wikifunctions Beta during the fellowship. The fellows also contributed to our now much more stable and comprehensive testing setup. We have already and are continuing to reduce scope, and to speed up the launch of Wikifunctions proper, to focus more on an MVP given the place we are now.
Some of the criticisms that are raised though are difficult to fix: we would love to have two dedicated teams, one to work on Wikifunctions, one to work on Abstract Wikipedia, but for that, we do not have the resources available. Other criticisms would have made a lot of sense to discuss in 2020 around the original proposal, but seem less actionable now, given the development in the meantime, e.g. the Python and JavaScript executors are already implemented and running on Beta.
I found the evaluation very helpful. I promise that I will keep the evaluation in mind. We will continue to focus to get us to an MVP and to get us to launch. That is our priority. --DVrandecic (WMF) (talk) 19:52, 2 January 2023 (UTC)
Agreed w bawolff on "the appeal to avoid cultural bias." I hope the team finds ways to work w / extend GF or equivalent! And hope a global template repo is still one of the core early goals, since it is mentioned prominently in both the initial design and in this critique.
I am delighted to see this depth and clarity of discussion about the scope and impact of a Project, this is something we have been missing across Wikimedia for some time. Thanks to all involved for tackling new ideas substantive enough to warrant this. – SJ + 16:36, 3 January 2023 (UTC)
  • To find out if something will work, at some stage it is necessary to test it in the real world, but if it fails that does not always prove that the concept was wrong. Shit happens, not all of it predictable. Some flexibility is often useful. I supported this project at proposal stage, not because I knew it would succeed, but because I thought it might succeed. If it works, fantastic. If it doesn't, we might be able to work out why, and not in the superficial "I told you so" sort of way. I wish it success, and the luck these things often need. · · · Peter Southwood (talk): 09:57, 3 January 2023 (UTC)
There are two kinds of cultural bias involved, really. In terms of content, there is a cultural bias built into Wikidata anyway, just on the basis of Wikidata demographics (Western views, interests, preoccupations, etc.). The linguistic bias, in terms of being able to handle agglutinative or ergative grammars etc., is a different one. I think it will have a negligible impact on community demographics and the amount of content bias there is (I don't foresee large number of, say, Niger-Congo language speakers coming in and taking over if their language can be handled well).
Personally, I've always been worried that Wikidata and Abstract Wikipedia will create a sort of digital colonialism, not least because the companies likely to benefit most are all in the US, and multilingual free content is their ticket to dominating new markets currently still closed to them. Andreas JN466 17:00, 3 January 2023 (UTC)
Leaving aside Wikidata (where the Wikimedia approach has basically succeeded with "semantic web" ideas by intelligent selection), I would say that the Silicon Valley approach to language translation is firmly based at present on machine learning, massive corpus computation, and other empirical ideas. What Abstract Wikipedia intends, as can be seen already in painstaking lexeme work, is so different as almost to be considered orthogonal to current orthodoxy. The outputs from the abstract syntax are heavily conditional. If you can give a formal description of how enough sentences work in language L, and can supply enough accurate translations for nouns, verbs etc. into L from abstracted concepts, you can start getting paragraphs of Wikipedia-like content, typically of assertoric force on factual subjects. All this can generate debate and refinement of the linguistic inputs via L; and possibly cultural feedback too. It seems a long way from quick wins such as machine translation offers now, and the time scale is around ten years to see what "production mode" might mean. (I base some of this on conversations around Cambridge with people having relevant business experience.) Charles Matthews (talk) 12:35, 4 January 2023 (UTC)
Charles, according to our article on it, the idea for Abstract Wikipedia was first developed in a Google paper (see also HaeB's intro above) and we're discussing the input of Google Fellows seconded to the project, whose stated aim was "to support the backend of Wikifunctions, enabling the team to speed up their schedule" (see Wikipedia:Wikipedia_Signpost/2022-06-26/News_and_notes). So I wouldn't think that Google and others have no interest in this work. Simple articles in languages like Yoruba, Igbo or Kannada, drawing on Wikidata's vast storehouse of data, would surely be a boon to any search engine maker wanting to display knowledge panels in languages that are currently poorly served and have very small online corpora, and the same goes for makers of voice assistants. (Having said that, I wouldn't discount the possibility that machine translation may advance fast enough to significantly reduce the perceived need for something like Abstract Wikipedia.) Andreas JN466 14:08, 4 January 2023 (UTC)
I wasn't discounting your argument as it applies to Wikidata. I expect Google and other big players (what's the current acronym?) would be interested in AW just because they should "keep an eye on" this part of the field. The approach in machine learning can take decisions well enough from noisy data, can make money and so on. Basically it extends the low-hanging fruit available. Trying to get AW to populate (say) the Luganda Wikipedia in order to create "core" articles in medicine, chemistry and biology is a very different type of project. It is fundamentally about mobilising people rather than machines. Wikimedia should try to get to the point where it is a routine application of known technology.
To get back to the contentious point here: if there was no real need for innovative tech in this area, I would think a rival to AW would have been announced by now (and even a spoiler project started). I would say the type of innovation required probably has unpredictable consequences, rather than predictable ones. It should increase somewhat the connectedness of the Web. By the way, the voice assistant expert I talked to obviously thought the basic approach was wrong. Charles Matthews (talk) 16:06, 4 January 2023 (UTC)
@Charles Matthews I'm having trouble parsing this part of your reply: if there was no real need for innovative tech in this area, I would think a rival to AW would have been announced by now (and even a spoiler project started). If there was no need for innovative tech, someone would have announced a rival?
One interesting example given in the presentation on Meta was the Simple English article on Jupiter (see m:Abstract_Wikipedia/Examples/Jupiter#Original_text. Having CC0 or CC BY-SA (this is a decision the Abstract Wikipedia team has dithered about; last I looked, it was postponed) articles like this available in dozens of languages, spoken collectively by hundreds of millions of people in Asia, Africa, South America and Oceania, would surely be of interest to voice assistant makers. I can't imagine that they would turn their noses up at it, given that they're all over Wikipedia as it is.
The other question is whether articles like this, written in simple English, are actually within reach of machine translation capability today. (DeepL certainly produces perfect translations of that Jupiter article.)
I always thought an alternative – or complementary – approach to serving more languages might be to actually put some energy into Simple English Wikipedia: write texts about key topics in that project that are designed for machine translation and avoid all the things translation engines (and learners of English) have problems with – and then advising users to let emerging translation engines have a go, having them translate articles on the fly, and reviewing what problems remain.
This might be easier and quicker than the WMF and a very limited subset of volunteers coming up with
  • Wikifunctions grammar,
  • thousands of articles written in that grammar – essentially a special meta-language for writing articles only used in that project – and
  • natural-language generators to translate this metalanguage into dozens upon dozens of human languages.
I understand that the idea is to leverage Wikidata content, making ultimately for a far more powerful product; I just fear it might take decades, i.e. so long that by the time it could be done, everybody else will have moved on. Andreas JN466 10:38, 5 January 2023 (UTC)
@Jayen466: Well, you may even be right about the feasibility of "simple English" as a starting point for some progress in the direction of creating "core" content. I was thinking, rather, of the application of existing linguistic theory to provide some substitute for AW: there were mails early on its list saying "you do realise that certain things are already done/known to be very hard" about the prior art in this field. I don't know that prior art, so I can't comment. The approach being taken is blue skies research. It has my approval for that reason: if once a decade the WMF puts resources behind such a project, that seems about right.
The use of lexemes in AW is a coherent strategy. Wikidata has begun to integrate Commons and Wikisource with the Wikipedias in a way I approve of also. What I wrote below about the actual linguistic approach being adopted is something like "brute-force solution mitigated by the use of functional programming in a good context for it". It hasn't been said explicitly, but seems quite possible as an eventual outcome, that the Module: namespace in Wikipedia would, via Wikifunctions, be broadened out to include much more diverse code than is currently used, with just Lua. That is all back-office infrastructure, but promising for the future of Wikipedia (which is managed conservatively from the tech point of view).
There are people asking all the time for more technical attention across Wikimedia, and they will go on doing that. We see some incremental changes on Wikipedia, of the meat-and-potatoes kind. It seems to me satisfactory that there is an ambitious project launched in 2020 which might look pretty smart by 2030. In any case I come down here on Denny's side, rather than supporting the critics, because it seems care and thought is going into the design, as opposed to a race for quick results. My own limited experience of software pipelines suggests that everyone is a critic. Charles Matthews (talk) 11:20, 5 January 2023 (UTC)
  • I am interested in the project Wikifunctions and I hope that it will be easy enough to contribute to it. In the last 2 years I created several scripts to convert a input to source code. I focused on Spreadsheet functions and self defined blocks from visual programming languages Snap and Scratch and hope that Wikifunctions can help democratizing programming.--Hogü-456 (talk) 21:28, 3 January 2023 (UTC)
  • I have been following the AW project with considerable interest from the outset. I have some (entirely theoretical) background in functional programming (FP), but am not in any sense a developer. I come at all of this rather obliquely. For me, there have been a number of "reveals" from Denny, and at some point I felt convinced that what AW was trying to achieve in the language field was worthy if ambitious. FP is well-worn ground in computer science, but in some sense it still feels like a "European" approach (was true 30 years ago, for sure). The assembler-level approach to FP is by combinators, and to "get" the idea you have to understand that combinator to constructor is not a big step, from a purely algebraic point of view. To get a universal view of language translation, you need something of the power of rewriting combinators to other combinators, using rules. Then you have a chance of treating language syntax on its merits, case by case. I think Leibniz might have got that point. Then in order to have an implementation of that rewriting that is modular, transparent, clean, all the good virtues in what will be massively complex ultimate code, you should invoke FP because it is best in breed for those things. (I apologise to Denny if I have misunderstood. FP in itself is not innovative, but the Wikifunctions take is post-Python, to put it shortly, in terms of programming language design.) I can quite see that traditional project management starts by saying "how much of this do you actually need, and what here is just nice-to-have?". The WMF emphasis on linguistic universality argues against premature rationalisation here, is what I also see. Charles Matthews (talk) 12:12, 4 January 2023 (UTC)
  • Other than the sections on asynchronous content rendering speed and issues with support for multiple programming languages (which I don't think I can give a sufficiently informed opinion on), I disagree with a lot of the criticism in the evaluation, and agree with a lot of the team's response. Most critically:
    • I don't think that an Abstract Wikipedia project separated from Wikifunctions with a separate NLG system, would be feasible from a volunteer community-development perspective.
    • I very strongly agree with this line from the team's response: "[E]very step of the process of natural language generation should be visible, defeasible, and subject to participation by the broader community. As much as possible, the line between producer/consumer or technologist/user must be made to evaporate."
  • We can't be dependent on a separated "back-end" away from wiki procedures, and still remain a Wikimedia-style effort. (As an aside: I'm seeing some parallels between this dispute and the argument about whether Wikidata should've had a hard-coded ontology and hard-constrained properties/data structure.) --Yair rand (talk) 03:40, 5 January 2023 (UTC)
  • "would be feasible from a volunteer community-development perspective." Would this new programming language have any non-Wiki uses? If not who would learn it? Wakelamp d[@-@]b (talk) 08:35, 5 January 2023 (UTC)
  • It’s not the case that I “disputed the Foundation's characterization of her concerns”, as if it were a false statement. I clarified and refined it in my comment. A sort of tl;dr of that lengthy comment is that, I do, in fact, state that I agree with the Foundation’s response that the Fellow’s statement of “There are sufficiently general NLG systems which could cover all (written) human languages (for example: Grammatical Framework, templatic system)” deserved to be critiqued and corrected. Those two systems currently won’t do for many languages. I gave a short explanation why they don’t. It is those reasons that are different from those mentioned in the Foundation’s answer. (and, fwiwi: I do have lots more to say about AW as well, but that won’t quite fit buried in a comment to an article. TBC.) Keet10 (talk) 11:32, 9 January 2023 (UTC)
  • allowing the functions in Wikilambda to be called from wikitext - THAT is not happening without consensus, and there's going to be quite a bit of opposition considering the endless disruption and warfare ever since the ability to call Wikidata was added to wikitext. We don't even have consensus on whether Wikidata is acceptable for use in infoboxes, yet Wikidata enthusiasts are constantly wasting time shoving Wikidata calls everywhere else - which inevitably results in more time wasted on RFCs to ban/rollback those deployments and then yet more labor wasted actually preforming deletion or reversal of it all. Alsee (talk) 15:06, 14 January 2023 (UTC)
  • For those interested hearing more about this, I have been interviewed to Yaron Koren's podcast Between the Brackets giving some more context about the evaluation and answering some of the counter-arguments given in the answer. Ariel Gutman (talk) 18:53, 18 January 2023 (UTC)
  • I think that this project is aiming to become the (open) alternative for WolframAlpha. I see some similarities on how the focus on NLP, and creating functions behind it, might be beneficial, but I think the wheel have been invented, maybe try to work together with Stephen Wolfram instead? Hopefully this project doesn't repeat the mistake of Knowledge Engine (search engine) trying to compete with Google. Bennylin (talk) 09:46, 28 February 2023 (UTC)

Traffic report: Football, football, football! Wikipedia Football Club! (0 bytes · 💬)

Wikipedia talk:Wikipedia Signpost/2023-01-01/Traffic report


Retrieved from "https://en.wiki.x.io/w/index.php?title=Wikipedia_talk:Wikipedia_Signpost/Single/2023-01-01&oldid=1130909660"