[Wikidata-bugs] [Maniphest] T364539: Protocol-relative URL in sidebar now interpreted as title (Query Service link in Wikidata sidebar broken)

Bawolff added a comment. Also broke the techblog link on mediawiki.org TASK DETAIL https://phabricator.wikimedia.org/T364539 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Bawolff, Nikki, Addshore, WMDE-Fisch, Lydia_Pintscher

[Wikitech-l] Re: Announcing: Path review board

So unfortunately interest in the patch review board seems to have died off I believe when something doesn't work out, it is good to have a retrospective. With that in mind, please add thoughts about the patch review board to

[Wikidata-bugs] [Maniphest] T340201: Use custom language code to find i18n XSS issues

Bawolff added a comment. Creating T347787 <https://phabricator.wikimedia.org/T347787> to brainstorm ideas about the Pager class hierarchy. I didn't create a brainstorming one for LogFormatter, as that case seems pretty hopeless. TASK DETAIL https://phabricator.wikimedia.org/T340201

[Wikidata-bugs] [Maniphest] T340201: Use custom language code to find i18n XSS issues

Bawolff added a comment. This also seems to be really demonstrating the value of phan taint check. So far it seems like most of the found issues are in some corner that phan-taint-check can't analyze - mustache templates (+ some skin stuff which I didn't look too closely at. Not sure

[Wikitech-l] Re: New developer feature: $wgUseXssLanguage / x-xss language code

This is clearly yielding some interesting results. One of the patterns i've noticed is that several of the examples seem to involve mustache templates. I think there are two reasons for this: * mustache templates cannot currently be checked by phan-taint-check * Because they are a separate file,

[Wikitech-l] Re: MediaWiki Extensions and Skins Security Release Supplement (1.35.11/1.38.7/1.39.4/1.40.0)

tion of this issue is incorrect. It is an XSS not just a style injection. -- bawolff ___ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postor

[Wikitech-l] Re: gotointerwiki-external

Ensure that the iw_local field is set to 1. Otherwise the interwiki is not considered safe for automatic redirection. -- Brian On Thu, Jun 1, 2023 at 5:05 AM Bináris wrote: > Sorry for disturbing, but I did not find the answer in the docs. > > I installed a MW 1.39.3 with an automated tool.

[Wikitech-l] Re: Extension! Re: Wikimedia developer satisfaction survey 2023 六‍

Will the results for this be posted soon? It has been more than 3 months. -- Brian On Fri, Feb 17, 2023 at 8:30 AM Tyler Cipriani wrote: > > *Good news—✨you've got another week!✨* > We're extending the deadline to submit your answers to this year's > Developer Satisfaction Survey *until Fri,

[Wikidata-bugs] [Maniphest] T209923: Surface hidden and "undefined" slots via a single slot view

Bawolff added a project: Multi-Content-Revisions. TASK DETAIL https://phabricator.wikimedia.org/T209923 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bawolff Cc: Tgr, Aklapper, daniel, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, Naike

[Wikitech-l] Re: Reflecting on my listening tour

Thank you for this email. I appreciate your effort to tackle difficult problems head on and in recognizing our problems are socio-technical, not just technical. This email is probably one of the most reassuring things I have read from someone in WMF management in a very long time. There were some

[Wikitech-l] Re: FYI - WMF Product & Technology annual planning 2023/24 - snapshot of work in progress

I just wanted to say, that I really appreciate that this is being drafted in the open and providing opportunities for public feedback. Thanks, Brian On Wed, Apr 12, 2023 at 8:46 AM Liam Wyatt wrote: > Dear all, > > Back in February, the first public steps in the WMF's Annual Planning > process

[Wikidata-bugs] [Maniphest] T106367: Generate BCP 47 conform language codes for the HTML attribute `lang`

Bawolff added a comment. Note: there are reports that this causes problem on ubuntu's version of firefox https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2012430 TASK DETAIL https://phabricator.wikimedia.org/T106367 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings

[Wikitech-l] Re: [Proposal] Disable setting the "Lowest" Priority value in Phabricator

On Mon, Feb 27, 2023 at 4:24 AM Antoine Musso wrote: > Le 27/02/2023 à 13:05, David Gerard a écrit : > > Can I just note that however you word it, closing volunteers' good > > faith bugs because nobody is available from the organisation right now > > is an excellent way to get them never to file

[Wikidata-bugs] [Maniphest] T289760: Evaluate Oxigraph as alternative to Blazegraph

Bawolff added a comment. In T289760#7874365 <https://phabricator.wikimedia.org/T289760#7874365>, @DD063520 wrote: > Hi, I saw the document, but I'm a bit confused. Because the criteria are basically checked for the shortlisted solutions. But in which part do you explain why fo

[Wikitech-l] Re: maybe somebody can just review and approve this commit of script conversion?

ou want to have the code merged into mediawiki and deployed to wikipedia, you're going to have to put aside your feelings, or be content with it staying as an unmerged patchset forever. -- bawolff On Mon, Oct 24, 2022 at 9:03 PM dinar qurbanov wrote: > hello > > can somebody help with reviewing tec

[Wikidata-bugs] [Maniphest] T286239: Make tlh-latn and tlh-piqd a valid monolingual string language

Bawolff added a comment. In T286239#7491899 <https://phabricator.wikimedia.org/T286239#7491899>, @Amire80 wrote: > This language code is valid, but Klingon has a history of copyright litigation, so I'd say this should also have some legal advice, which I cannot provide.

[Wikidata-bugs] [Maniphest] T319219: Wikibase gives deprecated warnings on php 8.1

Bawolff created this task. Bawolff added projects: MediaWiki-extensions-WikibaseClient, MediaWiki-extensions-WikibaseRepository, PHP 8.1 support. Restricted Application added subscribers: Base, Aklapper. TASK DESCRIPTION Wikibase gives deprecated warnings on php 8.1. In addition

[Mediawiki-api] Re: Wikimedia REST API

another question, in which way the recent UI enhancements keep the parsoid > untouched ? Will the Rest API in this area remain upward compatible ? (what > I suppose and expect of course) . I am afraid I miss something here ?! > > Dominique L. > > Le mar. 27 sept. 2022 à

[Mediawiki-api] Re: Wikimedia REST API

Most of the docs are at: https://en.wikisource.org/api/rest_v1/ I have no idea what the long term plans are between the "Action" API vs the Wikimedia REST api vs the MediaWiki REST api. Originally the Wikimedia REST API was mostly stuff related to parsoid & visual editor and connecting apis that

[Wikitech-l] Re: Request Timeout

On Wed, Sep 7, 2022 at 3:17 PM Ryan Schmidt wrote: > > > On Sep 7, 2022, at 7:54 AM, Martin Domdey wrote: > >  > Hi, > > it looks like there is nobody who can work on a bug or production error > like this: https://phabricator.wikimedia.org/T316858 > > I don't think, that this is a production

[Wikidata-bugs] [Maniphest] T313564: Bump onoi/message-reporter in vendor.git to 1.4.2 for php 8 support

Bawolff added a comment. Hmm, i know general practice is to require exact version in vendor.git, but I wonder if this is a case where it would be acceptable to `"1.4.2|1.4.1"` since both versions are essentially identical, and its just which version of php they are marked as

[Wikidata-bugs] [Maniphest] T313564: Bump onoi/message-reporter in vendor.git to 1.4.2 for php 8 support

Bawolff added a subscriber: JeroenDeDauw. Bawolff added a comment. This is hard because the commit that added support for php 8, marked it as no longer supporting php 7.2. And we want to support both in these tests :( TASK DETAIL https://phabricator.wikimedia.org/T313564 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] T313564: Bump onoi/message-reporter in vendor.git to 1.4.2 for php 8 support

Bawolff created this task. Bawolff added projects: PHP 8.0 support, MediaWiki-extensions-WikibaseRepository. TASK DESCRIPTION vendor.git currently requires version 1.4.1 of onoi/message-reporter. This is breaking tests on php8, as you need 1.4.2 for php 8 support Wikibase says it needs

[Commons-l] Re: [Wikitech-l] Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery)

Honestly, I find the "not in the annual plan" thing more damning than the actual issue at hand. The core competency of WMF is supposed to be keeping the site running. WMF does a lot of things, some of them very useful, others less so, but at its core its mission is to keep the site going.

[Wikitech-l] Re: [Wikimedia-l] Re: Re: Uplifting the multimedia stack (was: Community Wishlist Survery)

Honestly, I find the "not in the annual plan" thing more damning than the actual issue at hand. The core competency of WMF is supposed to be keeping the site running. WMF does a lot of things, some of them very useful, others less so, but at its core its mission is to keep the site going.

Re: [Wikitech-l] [MediaWiki-l] The Second round of voting for mediawiki logo just started!

are, and that is ok. Cheers, Brian On Thursday, October 8, 2020, Amir Sarabadani wrote: > (Sorry for late response, this email fell into cracks of my messy inbox) > > On Mon, Sep 28, 2020 at 1:53 PM bawolff wrote: > >> TBH, I was under the impression that the second round was going to be

Re: [Wikitech-l] The Second round of voting for mediawiki logo just started!

TBH, I was under the impression that the second round was going to be narrowing down to top contenders (maybe the 3 or so top designs), not choosing the top contender (I guess that's my fault though, it wasn't stated anywhere that that was going to be the case or anything). It was kind of hard to

Re: [Wikitech-l] Ethical question regarding some code

On Sat, Aug 8, 2020 at 9:44 PM John Erling Blad wrote: > Please stop calling this an “AI” system, it is not. It is statistical > learning. > > So in other words, it is an AI system? AI is just a colloquial synonym for statistical learning at this point. -- Brian

Re: [Wikitech-l] Ethical question regarding some code

That's a tough question, and I'm not sure what the answer is. There is a little bit of precedent with https://www.mediawiki.org/w/index.php?oldid=2533048=Extension:AntiBot When evaluating harm, I guess one of the questions is how does your approach compare in effectiveness to other publicly

[Wikidata-bugs] [Maniphest] [Created] T248278: Wikibase doesn't respect Kartographer's addExtraCSPSrc

Bawolff created this task. Bawolff added projects: MediaWiki-extensions-WikibaseRepository, Maps (Kartographer), ContentSecurityPolicy. Restricted Application added a subscriber: Aklapper. Restricted Application added a project: Wikidata. TASK DESCRIPTION In 889716e13798 <ht

Re: [Wikitech-ambassadors] Lua script that needs to look up a big table (phonetic guide automation)

it will be notably faster, because > it runs directly on PHP, and not through the additional layer of Lua. > > On Sun, Mar 15, 2020 at 7:03 PM Deryck Chan wrote: > >> bawolff - Would you be able to point me to an example of mw.loadData? >> >> Also, I've subscribe

Re: [Wikitech-ambassadors] Lua script that needs to look up a big table (phonetic guide automation)

, that lua is not the best place to implement that. -- bawolff On Sun, Mar 15, 2020 at 8:25 PM Huji Lee wrote: > Deryck, > > I am not sure what you mean by "re-sort" articles, but if what you means > is that categories should be sorted differently, then I don't think Lua is >

Re: [Wikitech-ambassadors] Lua script that needs to look up a big table (phonetic guide automation)

Consider using https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#mw.loadData , keeping in mind that lua isn't really made with the usecase of huge data tables in mind, so there might be limits you run into if your data is really big. -- Bawolff On Sun, Mar 15, 2020 at 2:13

Re: [Wikitech-l] Fixing rule via PHPCBF

In theory, you can use the --sniffs option to specify specific sniffs. See phpcbf --help -- Brian On Mon, Mar 2, 2020 at 7:29 AM Zoran Dori wrote: > Hello, > is possible to fix specific rule via phpcbf? > > Best regards, > > Zoran Dori > volunteer, Wikimedia Serbia > s: zoranzoki21.github.io

Re: [Wikitech-l] MediaWiki API pageview issue

On Tue, Feb 25, 2020 at 1:27 AM MusikAnimal wrote: > Unfortunately there's no proper log of redirect changes (I recently filed < > https://phabricator.wikimedia.org/T240065> for this). There are change > tags > that identify redirect changes > --

Re: [Wikitech-l] MediaWiki API pageview issue

attention to the continue parameters) https://en.wikipedia.org/w/api.php?action=query=redirects=2019%E2%80%9320_coronavirus_outbreak=pageviews=pageviews=60=max=2 On Mon, Feb 24, 2020 at 4:28 AM bawolff wrote: > Hi, > > When I tested the api it seemed to work with redirects (e.g

Re: [Wikitech-l] MediaWiki API pageview issue

Hi, When I tested the api it seemed to work with redirects (e.g. https://mediawiki.org/w/api.php?action=query=json=pageviews=MediaWiki%7CMain_Page=pageviews=60= Where Main_Page redirects to the page MediaWiki ) > Then we attempted to use the redirects of a page and using the old page ids to grab

Re: [Wikitech-l] Help Further develop for Spell4Wiki App

If you get an invalid CSRF error, its generally best to just get a new token and try again. > 2. Once successfully uploaded audio not reflected to UN-Audio words API <

Re: [Wikitech-l] A monthly purge

Accidentally replied directly instead of to list like i meant to On Thu, Feb 20, 2020 at 8:15 AM bawolff wrote: > Some back of the napkin math > > If it takes 0.5 seconds to parse a page on average, it would take 289 days > to refresh all the pages on wikipedia (Assuming we aren't p

Re: [Wikitech-l] A monthly purge

Pretty sure the answer is no (Although i don't know for a fact). However, parser cache only lasts for 30 days. So pages will get parsed at least once every 30 days (if viewed). However that's separate from links update (aka categories, linter, etc). I suspect that doing a linksupdate of every

[Wikidata-bugs] [Maniphest] [Commented On] T240884: Standalone service to evaluate user-provided regular expressions

Bawolff added a comment. In T240884#5796687 <https://phabricator.wikimedia.org/T240884#5796687>, @Joe wrote: > I think the main question to answer is "does it make sense to create a safe regex evaluation service?". > I think in a void the answer is "no"

[Wikidata-bugs] [Maniphest] [Commented On] T176312: Don’t check format constraint via SPARQL (safely evaluating user-provided regular expressions)

Bawolff added a comment. Just as an aside, the dirt simple solution here would be to shell out to `grep -p` (or even just to php fed just the preg_match call) and rely on limit.sh to prevent undue resourse usage. TASK DETAIL https://phabricator.wikimedia.org/T176312 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Unblock] T223776: Create Wikidata autocomplete gadget for external entities

Bawolff closed subtask T223840: Can/should *.wmflabs.org be added to the default-src Content Security Policy? as Declined. TASK DETAIL https://phabricator.wikimedia.org/T223776 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Danmichaelo, Bawolff Cc

[Wikidata-bugs] [Maniphest] [Commented On] T238618: Adopt a CSP policy for query.wikidata.org

Bawolff added a comment. So I guess the next question is, where to set the CSP headers. My guess would be in `sub cluster_fe_deliver` of `text-frontend.inc.vcl.erb`, but I'm really not sure if that is the correct place. TASK DETAIL https://phabricator.wikimedia.org/T238618 EMAIL

[Wikidata-bugs] [Maniphest] [Commented On] T238618: Adopt a CSP policy for query.wikidata.org

Bawolff added a comment. So revised suggested CSP header: For everything except in the polestar directory: default-src 'self' data:; style-src 'unsafe-inline' data: 'self'; img-src data: 'self' upload.wikimedia.org commons.wikimedia.org; media-src data: 'self

[Wikidata-bugs] [Maniphest] [Commented On] T238618: Adopt a CSP policy for query.wikidata.org

Bawolff added a comment. Polestar also has a button to load datasets from http://ec2-52-1-38-182.compute-1.amazonaws.com:8753 - which seems a bit suspect from a privacy policy perspective... TASK DETAIL https://phabricator.wikimedia.org/T238618 EMAIL PREFERENCES https

[Wikidata-bugs] [Maniphest] [Commented On] T238618: Adopt a CSP policy for query.wikidata.org

Bawolff added a comment. So if I was ignoring polestar (aka graph builder mode) the ideal CSP would be something like: default-src 'self' data:; style-src 'unsafe-inline' data: 'self'; img-src data: 'self' upload.wikimedia.org commons.wikimedia.org; media-src data: 'self

[Wikidata-bugs] [Maniphest] [Commented On] T238618: Adopt a CSP policy for query.wikidata.org

Bawolff added a comment. So investigating this a bit further: - embed.html would ideally have its script in a separate file - Move the current usages of JSONP with www.wikidata.org to CORS - polestar uses angular, from what I understand, angular can be used to bypass CSP TASK DETAIL

Re: [Wikitech-l] Test Install of MediaWIki for Experimentation

There is also https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page & https://commons.wikimedia.beta.wmflabs.org/wiki/Main_Page test.wikipedia.org is closer to the main site (running basically the version of MW used on wikipedia, and all the user accounts are integrated), and should not be used for

[Wikidata-bugs] [Maniphest] [Created] T238618: Adopt a CSP policy for query.wikidata.org

Bawolff created this task. Bawolff added projects: ContentSecurityPolicy, Wikidata-Query-Service. Restricted Application added a subscriber: Aklapper. Restricted Application added a project: Wikidata. TASK DESCRIPTION As part of the effort to put CSP on all the things, as well as to help

Re: [Wikitech-l] The difference between fileexists-no-change and backend-fail-alreadyexists for action=upload

speculation as I'm not super familiar with the FileBackend code. -- bawolff On Sat, Nov 16, 2019 at 6:51 AM Chen Xinyan wrote: > Hi there, > > Hope I've found the correct list for asking this question. > > I was setting up a CI test case for my MediaWiki Client Library

Re: [Wikitech-l] Wikimedia production excellence (September 2019)

> There were five recorded incidents last month, equal to the median for this and last year. – Explore this data at https://codepen.io/Krinkle/full/wbYMZK Can't help but feel something is missing here, around the 7th... -- Brian On Thu, Oct 24, 2019 at 11:32 PM Krinkle wrote: >  Read on

[Wikidata-bugs] [Maniphest] [Commented On] T208329: Gadget with SPARQL services collides with Content Security Policy?

Bawolff added a comment. In T208329#4727241 <https://phabricator.wikimedia.org/T208329#4727241>, @Smalyshev wrote: > Not sure where that error is coming from - SPARQL responses have `access-control-allow-origin: *`. Maybe it's something in Mediawiki settings? COR

Re: [Wikitech-l] URL parameter fetching (mediawiki)

MediaWiki coding conventions is to use the WebRequest object. In the context of a SpecialPage subclass, you would probably do $this->getRequest()->getVal( 'reason' ); [Note: This combines both POST and GET values] See

Re: [Wikitech-l] Patchsets by new Gerrit contributors waiting for code review and/or merge

Just FYI, both page forms and Cargo are maintained by Yaron. -- Brian On Tue, Sep 10, 2019 at 3:20 AM Andre Klapper wrote: > CR0: Please review and provide guidance if you are familiar with the > code, and decide (CR±1 or CR±2): > > *

Re: [Wikitech-l] For title normalization, what characters are converted to uppercase ?

Apparently that will change in php7.3, which we will move to eventually but probably not anytime soon: https://3v4l.org/W7TiC -- bawolff On Mon, Aug 5, 2019 at 12:32 PM Nicolas Vervelle wrote: > Last question (I believe) : > I've implemented something similar as Php72ToUpper in WPC

Re: [Wikitech-l] For title normalization, what characters are converted to uppercase ?

MediaWiki uses php's mb_strtoupper. I believe this will use normal unicode uppercase algorithm. However this can vary depending on version of unicode. We are currently in the process of switching to php7, but for the moment we are still using HHVM's uppercasing code. There's a list of differences

[Wikidata-bugs] [Maniphest] [Created] T222681: WikidataPageBanner uses a blacklist of skin names to decide 'prebodyhtml' support instead of sane feature detection

Bawolff created this task. Bawolff added projects: Timeless, Wikidata-Page-Banner, Technical-Debt. Restricted Application added a project: Wikidata. TASK DESCRIPTION It appears that wikidata page banner uses an (essentially) undocumented* skin api ('prebodyhtml') that is only implemented

Re: [Wikitech-l] Developer account creation

Hi, I was going to register an account for you, but it looks like there's already a Luca Mauri registered in gerrit (from Jan 13, 2019 [1]). In any case, if all else fails, you can upload a patch via https://tools.wmflabs.org/gerrit-patch-uploader/ . Its also possible to add a patch as an

Re: [Wikitech-l] resource loader; 1.32 alpha; 1.32 stable breaking change loading scripts in widgets

I don't know if its best practise to do this, but core seems to do: (window.RLQ=window.RLQ||[]).push(function () { mw.loader.using('ext.myextension').then(function(){ console.log('library loaded');}); }); You probably don't have many other options if you are using the Widgets extension. --

Re: [Wikitech-l] Question to WMF: Backlog on bugs

On Tue, Mar 19, 2019 at 3:49 PM John Erling Blad wrote: > > > The devs is not the primary user group, and they never will be. An > editor is a primary user, and (s)he has no idea where the letters > travels or how they are stored. A reader is a primary user, and > likewise (s)he has no idea how

Re: [Wikitech-l] Question to WMF: Backlog on bugs

On Monday, March 18, 2019, John Erling Blad wrote: > On Mon, Mar 18, 2019 at 10:52 PM bawolff wrote: > > > > First of all, I want to say that I wholeheartedly agree with everything > tgr > > wrote. > > > > Regarding Pine's question on technical debt. > &g

Re: [Wikitech-l] Question to WMF: Backlog on bugs

First of all, I want to say that I wholeheartedly agree with everything tgr wrote. Regarding Pine's question on technical debt. Technical debt is basically a fancy way of saying something is "icky". It is an inherently subjective notion, and at least for me, how important technical debt is

[Wikidata-bugs] [Maniphest] [Commented On] T218568: Allow CORS from query.wikidata.org to production wikis

Bawolff added a comment. Reading https://meta.wikimedia.org/w/api.php?action=help=shortenurl - doesn't seem to require a CSRF token, so I'm not sure that CORS is needed here? (more specifically, you can use the generic origin=* I think). Although query.wikidata.org is fairly trusted

Re: [Wikitech-l] Question to WMF: Backlog on bugs

Regarding: >My proposal is to begin the discussion here: how can we better relay issues >that are more important to communities than new features? How can we have a >"community whishlist for bugs"? Well fundamentally it starts with making a list. This is basically a lobbying discussion right.

Re: [Wikitech-l] Community-Engineering gaps as defined in configuration

In regards to wgUseRCPatrol - I suspect (but don't know) that originally that was disabled on enwiki as a performance thing. If it was a performance concern, that's probably irrelevant at this point. I generally agree that its good to try an unify config complexity where it makes sense. But I

Re: [Wikitech-l] Question to WMF: Backlog on bugs

"tracked" does not mean someone is planning to work on it. This could be for a lot of reasons, maybe the bug is unclear, maybe its not obvious what a good way to fix is, maybe nobody cares (This sounds harsh, but the simple truth is, different things have different people caring about them, and

Re: [Wikitech-l] Read access to patrolled flag in wikimedia API

Are you sure that patrol status is shown as colour coding on history pages? I'm pretty sure its not. If you mean kind of the dim yellow colour (like in https://en.wikipedia.org/w/index.php?title=List_of_programs_broadcast_by_Adult_Swim=history for the moment, but that will likely change soon),

Re: [Wikitech-l] A potential new way to deal with spambots

ty consensus. I may be wrong about this, but > in my search of historical records I have not found evidence to the > contrary. I think that redesigning the process would be worth considering, > and I hope that a redesign would help to account for the types of needs > that bawolff descr

Re: [Wikitech-l] A potential new way to deal with spambots

matter of "Yes, wishlist, but more of it"? > > - Jonathan > > On Mon, Feb 11, 2019 at 2:34 AM bawolff wrote: > >> Sure its certainly a front we can do better on. >> >> I don't think Kasada is a product that's appropriate at this time. >> Ignoring >&g

Re: [Wikitech-l] A potential new way to deal with spambots

Sure its certainly a front we can do better on. I don't think Kasada is a product that's appropriate at this time. Ignoring the ideological aspect of it being non-free software, there's a lot of easy things we could and should try first. However, I'd caution against viewing this as purely a

Re: [Wikitech-l] Query

Its totally fine for the accounts to be different. (As long as you aren't intentionally using multiple accounts to confuse people, of course) At worse, it might be a tad confusing, but that's totally ok. Putting a note on your user page listing all your accounts is a good idea to prevent

Re: [Wikitech-l] [Engineering] Gerrit now automatically adds reviewers

Umm, No. -- Bawolff On Fri, Jan 18, 2019 at 10:13 PM Pine W wrote: > I'm glad that this problematic change to communications was reverted. > > I would like to suggest that this is the type of change that, when being > planned, should get a design review from a third party b

Re: [Mediawiki-api] Acquiring Traffic logs of a mediawiki API (for example Wikipedia.org)

Hi, It is possible, but you need special permission and to sign an NDA. See https://www.mediawiki.org/wiki/Wikimedia_Research/Formal_collaborations for details -- Brian On Mon, Jan 7, 2019 at 9:24 AM Willem Siers wrote: > Hi all, > > For my research (related to reverse engineering) I am

[Wikidata-bugs] [Maniphest] [Changed Policy] T212787: Wikidata slack channel token in public config file

Bawolff changed the visibility from "Custom Policy" to "Public (No Login Required)". TASK DETAILhttps://phabricator.wikimedia.org/T212787EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: hoo, RazShuty, Greta_Doci_WMDE, Michael, La

Re: [Wikitech-ambassadors] Removal of unblockself rights on wiki

AFAIK there are two main usecases for self-blocks: * Testing different features of blocks. * As a means of self-imposed wikibreak. -- Brian On Sun, Dec 16, 2018 at 8:35 AM Dan Koehl wrote: > > Speaking about self-blocks, why ist this option possible? > > Dan >

Re: [Wikitech-l] Book scans from Tuebingen Digital Library to Wikimedia Commons

Have you seen https://commons.wikimedia.org/wiki/Commons:Batch_uploading ? I think the folks at commons are more likely to be able to give you the help you need than wikitech-l would be. -- Brian On Mon, Dec 3, 2018 at 5:22 AM Shiju Alex wrote: > > > > > Google Drive will do OCR on Malayalam,

[Wikidata-bugs] [Maniphest] [Commented On] T210634: Scribunto test “LuaStandalone: SecurityTests[1]: CVE-2014-5461” failing in Wikibase CI builds

Bawolff added a comment. The gci task is already accepted - we cant force the student to do more work (we can of course ask nicely) In T210634#4782783, @Anomie wrote: Apparently the test added for T209232: Add a unit test to Scribunto testing it is not vulnerable to CVE-2014-5461 is sometimes

[Wikidata-bugs] [Maniphest] [Updated] T208329: Gadget with SPARQL services and the Content Security Policy ?

Bawolff added a comment. Hi, So query.wikidata.org is allowed from the CSP policy. For other domains, we are planning to have a process where individual users can specify that they allow other sources. The details aren't entirely worked out yet, but some sort of solution to this problem

Re: [Wikitech-l] non-obvious uses of in your language

Alas, no longer valid in XML or HTML5. (Although HTML5 will still parse it as an empty comment, but with a "incorrectly-opened-comment" error. -- Brian On Sat, Oct 6, 2018 at 6:57 AM Chad wrote: > > Found it :) > > https://www.w3.org/MarkUp/SGML/sgml-lex/sgml-lex > > Search for "empty comment

Re: [Wikitech-l] [Wikitech-ambassadors] Translations on hold until further notice

Updates from translatewiki will be put on pause. You can continue to update translations at translatewiki, but they won't show up on Wikimedia wikis until the current issues are sorted out. In order to avoid things getting out of sync with translatewiki, we would like to ask that you avoid

Re: [Wikitech-l] My Phabricator account has been disabled

Thank you for your detailed reply. I'm going to respond inline: On Thu, Aug 16, 2018 at 12:12 AM, Amir Ladsgroup wrote: > I write all answers in one place: > > Brian: >> So we are going to magically assume that somehow this block is going to > change mcbride's behaviour when it took a 100

Re: [Wikitech-l] My Phabricator account has been disabled

On Wednesday, August 8, 2018, Ori Livneh wrote: > > > On Wed, Aug 8, 2018 at 2:48 PM bawolff wrote: >> >> MZMcbride (and any other individual contributor) is at a power >> disadvantage here relative to how the foundation is an organized >> group >

[Wikitech-l] Fwd: My Phabricator account has been disabled

On Wed, Aug 8, 2018 at 8:29 PM, Amir Ladsgroup wrote: [...] > 2) the duration of block which is for one week was determined and > communicated in the email. You can check the email as it's public now. Can you be more specific? I'm not sure I see where this is public. > 3) not being able to

Re: [Wikitech-l] My Phabricator account has been disabled

If maximizing effectiveness was the only concern, we could just block all the users. -- Brian On Wed, Aug 8, 2018 at 8:12 PM, Ryan Kaldari wrote: > Are you suggesting that ArbCom does a good job of maintaining a collegial, > harassment-free environment on English Wikipedia? Just wanted to

Re: [Wikitech-l] My Phabricator account has been disabled

On Wed, Aug 8, 2018 at 12:53 PM, MZMcBride wrote: > Amir Ladsgroup wrote: >>I disabled the account and now I disabled it again. It's part of a CoC >>ban. We sent the user an email using the "Email to user" functionality >>from mediawiki.org the moment I enforced the ban. >> >>We rather not to

Re: [Wikitech-l] My Phabricator account has been disabled

s handled this matter. > > Dan > > -- > Dan Garry > Lead Product Manager, Editing > Wikimedia Foundation I disagree strongly with this. Wikitech-l is the traditional place for all discussions about mediawiki as an open source project. -- bawolff ___

[Wikidata-bugs] [Maniphest] [Commented On] T196892: Raw HTML in page descriptions

Bawolff added a comment. I personally think we should document the situation carefully, but ultimately this is clients responsibilityTASK DETAILhttps://phabricator.wikimedia.org/T196892EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff

[Wikidata-bugs] [Maniphest] [Unblock] T183020: Investigate the possibility to release Wikidata queries

Bawolff closed subtask T190875: Security review for Wikidata queries data release proposal as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T183020EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: EBjune, mkroetzsch, Smalysh

[Wikidata-bugs] [Maniphest] [Closed] T190875: Security review for Wikidata queries data release proposal

Bawolff closed this task as "Resolved".Bawolff claimed this task.Bawolff added a comment. I think this is ok, and I have no objections, with the caveat that (imo), security's role should be ensuring that stuff meets a certain standard or is safe against a certain threat model. I don'

[Wikidata-bugs] [Maniphest] [Commented On] T190875: Security review for Wikidata queries data release proposal

Bawolff added a comment. Sorry for the delay, this kind of got preempted by t194204 but is now next on my todo list. As an aside - this sort of thing traditionally doesnt require security team sign off (afaik) nor have we reviewed things like this in the past - historically its been legal

[Wikidata-bugs] [Maniphest] [Commented On] T190875: Security review for Wikidata queries data release proposal

Bawolff added a comment. Sorry, im on vacation until Monday. Perhaps someone else on the security team can take a look or failing that ill be back on monday (Thank you for your patience, i know this has been delayed multiple times)TASK DETAILhttps://phabricator.wikimedia.org/T190875EMAIL

[Wikidata-bugs] [Maniphest] [Updated] T195618: wikidatawiki.wb_terms missing label and descriptions for some languages

Bawolff added a comment. e78328eab0e7 was the commit i found, which made it look like it was disabled (Guessing by commit message. I'm not actually familiar with the feature or what's going on)TASK DETAILhttps://phabricator.wikimedia.org/T195618EMAIL PREFERENCEShttps://phabricator.wikimedia.org

Re: [Wikitech-l] Deactivating hyperlink by CSS

You could force the link to be behind (in a z-index sense) another transparent element. (Not really deactivated because you can still reach it via keyboard, but it would stop people clicking) -- Brian On Thu, May 10, 2018 at 12:15 PM, יגאל חיטרון wrote: > Hello. Is there

Re: [Wikitech-l] Proposal: Add security researchers to CREDITS file & [[Special:Version/credits]]

The reason I don't want them in the same category is, that: * I see them as a totally different type of contribution. I think a security reporter has more in common with a translator than a code contributor * The existing credits section is maintained by script based on git log. The security

Re: [Mediawiki-api] MediaWiki API v1.19.7; edit token request; empty response

Usually a blank response means php fatal error. If it is your wiki, check you web server error log, and also see https://www.mediawiki.org/wiki/Manual:How_to_debug#PHP_errors If its not your wiki, ask the owner of the wiki. -- Brian On Tue, May 1, 2018 at 7:38 PM, tom schulze

Re: [Mediawiki-api] Wikimedia API redirect 301

That header comes from https://cors-anywhere.herokuapp.com/ not MediaWiki. However, its usually set if mediawiki redirects you, which might happen if you are not using https. However, https://cors-anywhere.herokuapp.com/ is not needed. =* will tell MediaWiki to send appropriate CORS * headers.

[Wikidata-bugs] [Maniphest] [Commented On] T173339: Categories tracking pages with wikidata links are not updated when items on Wikidata are modified

Bawolff added a comment. A good way to test this theory would be to find a page affected by this and see if page_links_updated timestamp is greater than the timestamp on the wikidata edit. The timestamp on page_links_update should be the time that the page was finished being parsed (i wonder why

[Wikidata-bugs] [Maniphest] [Commented On] T190875: Security review for Wikidata queries data release proposal

Bawolff added a comment. Question: Looking at https://github.com/Wikidata/QueryAnalysis/blob/master/tools/extractAnonymized.py, at first glance, it looks like the string handline code wouldn't handle edge cases properly e.g. "foo\"bar" "foo'bar" ? (I only s

[Wikidata-bugs] [Maniphest] [Commented On] T190875: Security review for Wikidata queries data release proposal

Bawolff added a comment. Hi, So first of all, we'd like to see the code that does the query normalization. Second, could this have a summary of the types of queries we expect to be most common in the data set. I appreciate there will be a very long tail here, but having a summary of the most

  1   2   3   4   5   6   7   8   >