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
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
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
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
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
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
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.
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
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
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
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
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
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"
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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'
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
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
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
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
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
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
Bawolff added subscribers: APalmer_WMF, Bawolff.Bawolff added projects: Privacy, WMF-Legal.Bawolff added a comment.
I suspect this is more something that should have a privacy review from #wmf-legal than a security review.TASK DETAILhttps://phabricator.wikimedia.org/T190875EMAIL PREFERENCEShttps
Bawolff closed this task as "Resolved".Bawolff added a comment.
Yep, you are good.TASK DETAILhttps://phabricator.wikimedia.org/T186726EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Jakob_WMDE, Jonas, gerritbot, Aklapper, Lucas_Werkme
Bawolff closed subtask T186726: Security review WikibaseLexeme extension as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T168260EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Addshore, Aklapper, daniel, Lahi, Gq86, Ci
Bawolff added a comment.
I've actually been thinking about this recently.
MediaWiki is doing a subpar job with clickjacking in general. I'm now thinking that resource loader should in general just refuse to load any JS if the page is in a frame.TASK DETAILhttps://phabricator.wikimedia.org
Bawolff added a comment.
re: FormIdFormatter and SenseIdFormatter - I thought they might later be extended to a real implementation, which is why I was concerned, but as long as its just a dummy implementation that's eventually going away, that's all cool.
re: click-jacking: Yeah, it really
Bawolff moved this task from In Progress to Awaiting remediation on the Security-Reviews board.Bawolff added a comment.
Review of WikidataLexeme & php-vuejs-templating (To be clear, I didn't look at vue.js in general, since that was already reviewed by Darian afaik).
"FormIdFormatter.
Bawolff added a comment.
Just to confirm this is ready for review? The [WIP] in the title of the bug confuses me.
p.s. in regards to
Please link or describe setup process for setting up a test environment. @WMDE-leszek, can you help with this?
Don't worry about that. Its a MW extension, I only
Bawolff added a comment.
Php considering "0" to be false strikes again!TASK DETAILhttps://phabricator.wikimedia.org/T184812EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, BawolffCc: Bawolff, greg, Ladsgroup, jcrespo,
Bawolff claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T186726EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Aklapper, Lucas_Werkmeister_WMDE, Ladsgroup, thiemowmde, Lydia_Pintscher, WMDE-leszek, Lahi, Gq86, Cinemantique
Bawolff added a comment.
So core is fixed now, so we should be all clear to go ahead with the fix in wikidataTASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff
Bawolff added a comment.
Fix for gender at https://gerrit.wikimedia.org/r/398772TASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff, Lucas_Werkmeister_WMDE, Aklapper, Lahi, Gq86
Bawolff added a comment.
I don’t think we can do that – {{GENDER}} needs the unescaped username. Otherwise we’ll address these users with the wrong gender. (I tried it out locally, {{GENDER:*asterisk|he|she|they}} produces “she” while {{GENDER:asterisk|he|she|they}} produces “they”.)
And weirdly
Bawolff added a comment.
Hmm. Maybe thats a bug in GENDER: i would expect it to normalize titles.TASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff, Lucas_Werkmeister_WMDE
Bawolff added a comment.
In T182800#3835432, @Lucas_Werkmeister_WMDE wrote:
Why is this even being parsed as a list, anyways? The plain text of the message is:
Restore revision 597045630 by [[Special:Contributions/*Youngjin|{{GENDER:*Youngjin|*Youngjin}}]]
There’s no * anywhere near
Bawolff changed the visibility from "Custom Policy" to "Public (No Login Required)".
TASK DETAILhttps://phabricator.wikimedia.org/T164948EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, BawolffCc: Lucas_Werkmeister
Bawolff removed a project: Security.Herald added a project: Security.
TASK DETAILhttps://phabricator.wikimedia.org/T182800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: gerritbot, Bawolff, Lucas_Werkmeister_WMDE, Aklapper, Cpaulf30, Lahi, Gq86
Bawolff added a comment.
In T182800#3835104, @Lucas_Werkmeister_WMDE wrote:
Ah, but plaintext parameters are, like raw parameters, processed after the message is parsed, so {{PLURAL:$3|claim|claims}} no longer works :/
Oh, I didn't think about that. Just use a normal ->params() and w
Bawolff added a comment.
In T182800#3834874, @Lucas_Werkmeister_WMDE wrote:
Possible fix:
diff --git a/lib/includes/Formatters/AutoCommentFormatter.php b/lib/includes/Formatters/AutoCommentFormatter.php
index 0c77d8762..b57ab5580 100644
--- a/lib/includes/Formatters/AutoCommentFormatter.php
Bawolff closed this task as a duplicate of T180878: Upgrade rubocop across the extension fleet.
TASK DETAILhttps://phabricator.wikimedia.org/T180892EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Aklapper, Niedzielski, Lahi, GoranSMilovanovic
Bawolff added a project: Security.
TASK DETAILhttps://phabricator.wikimedia.org/T180892EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Aklapper, Niedzielski, Lahi, GoranSMilovanovic, QZanden, HJiang-WMF, dpatrick, Luke081515, Wikidata-bugs, aude
Bawolff added a comment.
Is there an estimate on the number of rows in a given time period this would be?TASK DETAILhttps://phabricator.wikimedia.org/T179010EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, Aklapper, daniel, jcrespo
Bawolff added a comment.
Hi, There's been reports of high amounts of lag on commons causing read only mode, especially between 7:10-10:10 UTC today. (I filed T178094) Perhaps the rate of deletion of commons RC entries is too aggresive?TASK DETAILhttps://phabricator.wikimedia.org/T12EMAIL
Bawolff added a comment.
Well wikidata is almost certainly a contributing factor, (particularly for russian) I would hesitate to blame it solely for slow ores on watchlist speeds, without more evidence. Especially on english wikipedia with its large recentchanges table and relatively low usage
Bawolff added a comment.
Correction: the response is cached according to the maxage specified in the request; however, I’m not sure if this works if pages are edited or purged (as far as I can tell, the browser doesn’t validate its cached data), so it can be hard to choose the right maxage
Bawolff added a comment.
In T171027#3676023, @jmatazzoni wrote:
In T171027#3673060, @Lydia_Pintscher wrote:
This is a hugely political issue. Let's please not do this unless necessary.
Right now, ORES is unusable on Watchlist for English, Russian and probably some other big wikis. It causes
Bawolff added a comment.
In T177707#3673488, @Mike_Peel wrote:
"Open question: Where should the cut-off initially be?" - the problem I have here is that it's particularly useful to see changes to highly-used pages, as it's those same pages that need to be watched closer to
Bawolff added a comment.
In T171027#3667090, @jcrespo wrote:
The introduction of wikidata events on recentchanges has converted the "light" recentchanges table into a monolithical 500GB table:
commonswiki]> SHOW TABLE STATUS like 'recentchanges'\G
*
Bawolff added a comment.
They're not fully redundant, since rc_type for Wikidata is RC_EXTERNAL (from core, thus not Wikidata-specific).
Afaict only wikidata uses it. Flow uses a different number. Personally i think it would have made more sense to stick with numbers and have each ext pick
Bawolff added a comment.
As an aside, in the case of commons, it might make sense to always record label usage as being for all languages, instead of which specific language, since commons uses weird {{int:...}} hacks for multilingualness, which won't record all the usages for non-canonical
Bawolff added a comment.
I suspect that having more rows in recentchanges is much much worse than having more rows in wbc_entity_usage.TASK DETAILhttps://phabricator.wikimedia.org/T151717EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff
Bawolff added a comment.
In T151717#3598222, @Halfak wrote:
I think the idea is that we'll be able to include wbc_entity_usage to increase granularity in watchlists once this is solved for. It will require some new work though :) Happy to see @Bawolff excited about this functionality.
My
Bawolff added a comment.
I suspect that fixing this bug will significantly help with T171027 (watchlists being too slow)TASK DETAILhttps://phabricator.wikimedia.org/T151717EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, eranroz, Ottomata
Bawolff added a comment.
To answer my own question: https://github.com/wikimedia/wikiba.seTASK DETAILhttps://phabricator.wikimedia.org/T171274EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, PokestarFan, Aklapper, JanZerebecki, hoo
Bawolff added a comment.Herald added a subscriber: PokestarFan.
Is the site in a git repo somewhere?TASK DETAILhttps://phabricator.wikimedia.org/T171274EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Bawolff, PokestarFan, Aklapper, JanZerebecki
Bawolff added a comment.
I approve on behalf of #security-teamTASK DETAILhttps://phabricator.wikimedia.org/T170927EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Reedy, Bawolff, dpatrick, PokestarFan, chasemp, bd808, gerritbot, Marostegui
Bawolff closed subtask T159709: Security review for WikibaseMediaInfo extension as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T159708EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Ricordisamoa, Aklapper, Lydia_Pintsche
Bawolff moved this task from Scheduled to Done on the Security-Reviews board.Bawolff closed this task as "Resolved".Bawolff claimed this task.Bawolff added a comment.
Sorry for the delay in reviewing this one.
Security review passed. There's not much to say. Most of the interface wo
Bawolff changed the title from "[Bug] Special: Create a new item button isn't showing thumbnails on Wikidata" to "Special:NewItem - Create a new item button isn't showing thumbnails on Wikidata".
TASK DETAILhttps://phabricator.wikimedia.org/T159697EMAIL PREFERENCEShttps://phabr
Bawolff added a project: Wikidata.
TASK DETAILhttps://phabricator.wikimedia.org/T159697EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Viveksr96, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Bawolff added a comment.
In T156240#2971262, @daniel wrote:
@Bawolff well, right now, all the vandal has to do is go to the page and add [[nds:Bawolff sucks...GHHDCBTSfgjbftgdthn"]] to the page... Granted, the fix is a bit less obvious, but deleting a page is easy enough.
I agree its som
Bawolff added a comment.
The scenario i was thinking of is someone uses gpus to brute force a conflict between a real title and the normalized version of a naughty string.
So e.g. if "Dog" and "Bawolff sucks...GHHDCBTSfgjbftgdthn" collide after normalization (this is just a
Bawolff added a comment.
In T149082#2968137, @Addshore wrote:
In T149082#2966632, @Bawolff wrote:
I assume this is not using the LinkUpdates related hooks because it only wants to deal with new pages not edits (?) However it seems that this still triggers on all edits. Perhaps it should look
Bawolff moved this task from Scheduled to Done on the Security-Reviews board.Bawolff added a comment.
Security review of Cognate extension (As of a187d934b8c6)
Normal issues
Use sha256 (or some other modern hash) instead of md5. Even in contexts where the attacks against it is not important we
Bawolff moved this task from Scheduled to Done on the Security-Reviews board.Bawolff closed this task as "Resolved".Bawolff claimed this task.Bawolff added a comment.
Security review of InterwikiSorting revision 7d48e09104136 (Jan 3, 2017)
Extension looks good. One small (non-securit
Bawolff closed subtask T149083: Security review for InterwikiSorting Extension as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T150183EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BawolffCc: Ladsgroup, Aklapper, Addshore, Lydia
Bawolff added a comment.
In https://phabricator.wikimedia.org/T135961#2316963, @Bawolff wrote:
> Umm, I thought I had already fixed this.
Or I guess that would be //you// already fixed it ;)
TASK DETAIL
https://phabricator.wikimedia.org/T135961
EMAIL PREFERENCES
ht
Bawolff added a comment.
I guess
- F3939586: T110143-scribunto-REL1_23b.patch
<https://phabricator.wikimedia.org/F3939586>
- F3939587: T110143-scribunto-master_b.patch
<https://phabricator.wikimedia.org/F3939587>
- F3939588: T110143-scribunto-REL1_25b.p
Bawolff added a comment.
Umm, I thought I had already fixed this.
TASK DETAIL
https://phabricator.wikimedia.org/T135961
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie, Bawolff
Cc: Bawolff, Aklapper, Zppix, demon, Legoktm, JanZerebecki
Bawolff added a comment.
> I think there's a very valuable use-case in data sets well below the 100mb
range
That was just a general example, because it wasn't clear to me if this was
being sold as a general purpose solution for all data-sets. 4 mb is the actual
limit for wikipa
Bawolff added a comment.
> We already have pretty robust support for pages containing text.
Not if your data-set is 100 mb big. I think this bug maybe needs some scope
clarification before deciding which approach is best.
> I think the best way forward is to post on c
Bawolff added a project: Wikidata.org.
Herald added a project: Wikidata.
TASK DETAIL
https://phabricator.wikimedia.org/T110012
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Bawolff
Cc: siebrand, Rillke, Bawolff, Steinsplitter, Umar, Wikidata-bugs
Bawolff changed the title from Date format in file infobox on commons
localized incorectly in Chechen (ce) to Date format in file infobox on
commons and at wikidata localized incorectly in Chechen (ce).
TASK DETAIL
https://phabricator.wikimedia.org/T110012
EMAIL PREFERENCES
https
88 matches
Mail list logo
