Tgr added a subscriber: Tgr.
Tgr added a comment.
Face recognition could be interesting when combined with T58666, to invite
people to add annotations.
TASK DETAIL
https://phabricator.wikimedia.org/T76886
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim
Tgr added a comment.
http://www.pastec.io/ claims to have a database built from Commons images,
might be interesting to test.
TASK DETAIL
https://phabricator.wikimedia.org/T76886
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username
Tgr added a comment.
Might be also interesting for visual captchas (T64960) although using a
publicly available algorithm is always a weakness there.
TASK DETAIL
https://phabricator.wikimedia.org/T76886
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe
Tgr edited projects, added Structured-Multimedia-Data; removed
MediaWiki-extensions-MultimediaViewer.
Tgr set Security to none.
TASK DETAIL
https://phabricator.wikimedia.org/T0
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username
Tgr added a subscriber: Tgr.
Tgr added a comment.
I think this bug should have higher priority. It breaks one of the most
fundamental functions of the wiki software, that a reader can easily find more
information on the topic in a different language. With Wikidata, subjective
editorial
Tgr closed this task as Resolved.
Tgr added a comment.
Mingle duplicate of the three related bugs, which have been fixed.
TASK DETAIL
https://phabricator.wikimedia.org/T77816
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username
Tgr edited the task description.
Tgr set Security to none.
TASK DETAIL
https://phabricator.wikimedia.org/T77816
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
Tgr placed this task up for grabs.
TASK DETAIL
https://phabricator.wikimedia.org/T77816
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Tgr reopened this task as Open.
Tgr added a subscriber: Tgr.
Tgr added a comment.
Testing unrelated Phabricator behavior. Ignore me.
TASK DETAIL
https://phabricator.wikimedia.org/T77816
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
Tgr closed this task as Resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T77816
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Tgr added a comment.
FWIW, a partial prototype is available at
https://github.com/creative-work-metadata/creative-work-metadata
TASK DETAIL
https://phabricator.wikimedia.org/T586
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username
Tgr placed this task up for grabs.
TASK DETAIL
https://phabricator.wikimedia.org/T76024
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Tgr added a blocking task: T76024: Post data model documentation from
structured data bootcamp.
TASK DETAIL
https://phabricator.wikimedia.org/T585
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https
Tgr edited the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T585
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Tgr added a blocked task: T585: Finalize high-level API.
TASK DETAIL
https://phabricator.wikimedia.org/T76024
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
Tgr edited the task description.
Tgr reopened this task as Open.
TASK DETAIL
https://phabricator.wikimedia.org/T101565
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: bd808, Tgr
Cc: Tgr, gerritbot, bd808, Sumit, Aklapper, Jdlrobson, mobrovac
Tgr added a comment.
@jdlrobson can you verify if this is fixed? (For normal pages you need to edit
and save the page after `vagrant provision` for the fix to take effect. Not
sure about the page banner.)
TASK DETAIL
https://phabricator.wikimedia.org/T101565
EMAIL PREFERENCES
https
Tgr added a comment.
https://phabricator.wikimedia.org/T56202 affects the default wiki as well.
TASK DETAIL
https://phabricator.wikimedia.org/T101565
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: bd808, Tgr
Cc: Tgr, gerritbot, bd808, Sumit
Tgr added a comment.
`?` does not come from any internal logic in CommonsMetadata - if the author or
source is not specified, the relevant key will simply be missing from the
response:
-
https://commons.wikimedia.org/w/api.php?action=querytitles=File%3ABathsOfCaracalla.jpgprop=imageinfoiiprop
Tgr added a subscriber: Tgr.
Tgr added a comment.
There is an `AttributionRequired`
https://www.mediawiki.org/wiki/Extension:CommonsMetadata#Returned_data field
already.
TASK DETAIL
https://phabricator.wikimedia.org/T75130
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings
Tgr added a subscriber: Tgr.
Tgr added a comment.
In https://phabricator.wikimedia.org/T101565#1353926, @bd808 wrote:
There have been reports in the past that `$wgUseInstantCommons` is broken in
MediaWiki-Vagrant.
That's https://phabricator.wikimedia.org/T56202. It affects wikis with a 404
Tgr added a subscriber: Tgr.
Tgr added a comment.
See second and third points in
https://phabricator.wikimedia.org/T108778#1530558.
TASK DETAIL
https://phabricator.wikimedia.org/T71456
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Tgr
Tgr added a comment.
Note that it won't work if the page has no other images (and is MediaViewer is
not set up).
TASK DETAIL
https://phabricator.wikimedia.org/T108778
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: gerritbot, Matanya, Tgr
Tgr added a comment.
There are multiple issues:
- until MediaViewer gets zoom functionality
(https://phabricator.wikimedia.org/T77151) I'm not sure there is a point in
using it. It can help with download and such, but it will display the image
pretty much the same way it looks on the page
Tgr added a subscriber: Tgr.
TASK DETAIL
https://phabricator.wikimedia.org/T107595
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel, Tgr
Cc: Tgr, Qgil, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand,
awight, Ricordisamoa, GWicke
Tgr added a subscriber: Tgr.
TASK DETAIL
https://phabricator.wikimedia.org/T99895
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Lucie, Tgr
Cc: Tgr, Ricordisamoa, Tpt, Lydia_Pintscher, Bugreporter, Aklapper, daniel,
Wikidata-bugs, aude, Malyacko
Tgr added a subscriber: Tgr.
Tgr added a comment.
Is that a good idea? Patrolling changes to the pagebanner parameters seems kind
of annoying without seeing the effect. The banner should be on top of the
article, not top of the page, but otherwise it seems useful to have it.
TASK DETAIL
Tgr added a subscriber: Tgr.
Tgr added a comment.
Is the problem with the parser cache or Varnish? Do you need an actual purge to
fix it, or is adding some cachebreaker like `?_=21947979` to the end of the URL
enough to show the correct banner?
TASK DETAIL
https://phabricator.wikimedia.org
Tgr added a comment.
No, what I want to verify is that it's not a Varnish cache
<https://www.mediawiki.org/wiki/Manual:Varnish_caching> issue.
TASK DETAIL
https://phabricator.wikimedia.org/T121135
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailprefe
Tgr added a comment.
In https://phabricator.wikimedia.org/T122381#1905406, @Lydia_Pintscher wrote:
> This is pretty much one of the things structured data for Commons with the
> help of Wikidata is about. Let's please not implement a separate/competing
> mechanism.
Yeah, t
Tgr added a blocking task: T68108: Store media information for files on
Wikimedia Commons as structured data.
Herald added a subscriber: Matanya.
TASK DETAIL
https://phabricator.wikimedia.org/T122381
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Tgr created this task.
Tgr added a subscriber: Tgr.
Tgr added projects: MediaWiki-File-management, Structured-Multimedia-Data,
Commons.
Herald added subscribers: StudiesWorld, Steinsplitter, Aklapper.
Herald added projects: Multimedia, Wikidata.
TASK DESCRIPTION
Currently, Commons
Tgr added a blocked task: T122381: Provide a way to curate and fetch titles
(short descriptions) for media files.
TASK DETAIL
https://phabricator.wikimedia.org/T68108
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Spinster, Orofarne
Tgr added a subscriber: Tgr.
Tgr added a comment.
The librarization project is somewhat blocked on this (or rather on the
Composer security problems outlined here), see comments in
https://gerrit.wikimedia.org/r/#/c/248661/
TASK DETAIL
https://phabricator.wikimedia.org/T105638
EMAIL
Tgr added a comment.
From the sources copied by jcrespo:
!
Tgr added a comment.
That seems like a pretty regular 4-day schedule; too short for the MediaWiki
software updates (which should have no effect anyway, plus they were on hold
through most of December). When you see the issue, does it affect some pages or
all of them? Can you not flush the next
Tgr added a comment.
Thanks! I was wondering whether something sets a shorter expiry since your
purges seemed to happen on a fairly regular 4-day schedule but apparently not.
Also, the bannertoc parameter is neither set in page props nor extension data.
tgr@mw1152:~$ mwscript eval.php --wiki
Tgr added a comment.
I'm not sure what else to look at. We should probably log debug data when the
page is parsed so we can see whether this is tied to a specific client or an
API call or something.
TASK DETAIL
https://phabricator.wikimedia.org/T121135
EMAIL PREFERENCES
https
Tgr added a comment.
Related MV tasks: T59298: The viewer box should not depend on the current page, T77152: Support Developer Plugins/Gadgets in Media Viewer. @hoo if you have thoughts on what kind of hooks would be helpful please add it to that task!TASK DETAILhttps://phabricator.wikimedia.org
Tgr edited projects, added MediaWiki-extensions-OAuth; removed MediaWiki-extensions-OAuthAuthentication.Herald added a subscriber: Malyacko.
TASK DETAILhttps://phabricator.wikimedia.org/T124224EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, TgrCc
Tgr added a comment.
At a glance, the methods which will break if `mParent` is not set are
- HTMLFormField::getErrorsAndErrorClass
<https://github.com/wikimedia/mediawiki/blob/30aaec7b506e38ae628bbfd3b133bf43d58f12c1/includes/htmlform/HTMLFormField.php#L806>,
HTMLFormField::getErr
Tgr closed this task as "Resolved".
Tgr added a comment.
Splitting the generic problem to T134401: It is unclear what should happen
when HTMLFormField::$mParent is null
<https://phabricator.wikimedia.org/T134401>.
TASK DETAIL
https://phabricator.wikimedia.org/T134351
E
Tgr added a comment.
Worth considering that all wikis will probably have local mediainfo eventually, as we want to be able to add metadata to images the same way everywhere, and most images cannot be moved to Commons.TASK DETAILhttps://phabricator.wikimedia.org/T141602EMAIL PREFERENCEShttps
Tgr added a comment.
This was already discussed elsewhere, but for the record, we might want to move protection from the page level to the slot (stream?) level. Some use cases: file handling (T8579), CSS/JS associated to templates (T483), documentation of templates which have been protected due
Tgr added a comment.
This is not really a workaround - MCR deals with data storage and access, this would deal with data extraction from wikitext. That's necessary whether we have MCR or not. Blocking it on MCR just makes the situation worse - it is already a big jumble of various groups waiting
Tgr added a comment.
See T122867: Evaluate the feasibility of cache invalidation for the action API for some related discussion.TASK DETAILhttps://phabricator.wikimedia.org/T152425EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: Tgr, tstarling
Tgr created this task.Tgr added projects: Developer-Wishlist (2017), Structured-Multimedia-Data, MediaWiki-Parser.Herald added a subscriber: Aklapper.Herald added a project: Wikidata.
TASK DESCRIPTIONThe problem of passing structured data from wikitext to external applications comes up in a wide
Tgr added a comment.
A somewhat related idea: T156876: Structured data side channel for wikitextTASK DETAILhttps://phabricator.wikimedia.org/T105845EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GWicke, TgrCc: SBisson, MZMcBride, Mholloway, RandomDSdevel
Tgr edited the task description. (Show Details)
EDIT DETAILSThe problem of passing structured data from wikitext to external applications comes up in a wide variety of contexts, and a garden of ugly workarounds has grown around it, usually consisting of encoding the data in the HTML rendered from
Tgr added a comment.
One possible approach is detecting references which are controversial (by detecting removal or edit war patterns, maybe appearance in fact check databases, manual blacklists) and then flagging sentences which are supported by such references.TASK DETAILhttps
Tgr changed the title from "[Task] Add mw.wikibase.getEntityObject by site link (title) Lua function" to "[Task] Add Lua function to get Wikibase entity by site link (title)".Tgr edited the task description. (Show Details)
EDIT DETAILSPlease add a Lua functio
Tgr added a comment.
In T156370#2987273, @FDMS wrote:
Sounds related to (if not a duplicate of) T89692.
Indeed, it's a consequence of that issue (which is stalled due to lack of community interest).TASK DETAILhttps://phabricator.wikimedia.org/T156370EMAIL PREFERENCEShttps
Tgr added a comment.
From the developer point of view it's very tempting to look at the various stuff editors do and think "I can build an app for that!".
The Wikipedia community did in fact build an app for that, so I am not sure why you are talking as if this idea was some
Tgr added a comment.
See T149807: WindowManager should not let you add windows with no name defined.TASK DETAILhttps://phabricator.wikimedia.org/T155166EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: Tgr, hoo, Lucie, Lydia_Pintscher, Micru
Tgr added a comment.
In T157993#3027511, @Jheald wrote:
I don't know if there are any other ways to link & invoke MediaViewer (but there might be), or to pass it the names of the other images to include in the slideshow.
No.TASK DETAILhttps://phabricator.wikimedia.org/T157993E
Tgr added a parent task: T142308: Most extensions which add a user right should also add or extend a grant.
TASK DETAILhttps://phabricator.wikimedia.org/T124269EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: aude, TgrCc: Anomie, gerritbot, aude, Aklapper
Tgr added a comment.
Or, if that is not possible, have a flag in recentchanges that indicates whether all secondary updates for an edit have been completed.
Instead of a flag you could have an indexed sequence ID which is null while the updates are ongoing (or maybe a separate table which only
Tgr added a comment.
Is this blocked on something specific or just lack of interest? As I understood the original blocker was proper HTTPS support in Composer and that was fixed upstream some months ago.TASK DETAILhttps://phabricator.wikimedia.org/T105638EMAIL PREFERENCEShttps
Tgr added a comment.
It might be helpful to split the use cases into ones where MCR is nice to have and those which need it. As I understand it, there are roughly three groups:
data that would otherwise be stored on separate pages but could be bundled into a single page for better UX: media info
Tgr added a comment.
In T107595#2664438, @Pppery wrote:
Structured Media Data: What exactly is this seperating license information from? This proposed change seems like it would lose some of the flexibility in file licenses
Flexibility means it is impossible to build assumptions
Tgr added a comment.
In T107595#2667512, @daniel wrote:
I think little of that complexity should be exposed to users. We probably don't want editors to freely mix and match slots - rather, we want an integrated experience for editing and display. Ideally editors should neither know nor care
Tgr added a comment.
Is it possible to reuse this mechanism for T78479: API error messages should be localised?TASK DETAILhttps://phabricator.wikimedia.org/T47843EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, TgrCc: Tgr, bearND, MZMcBride, Fhocutt
Tgr edited the task description. (Show Details)
EDIT DETAILS...**URL**: http://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Errors_and_Warnings_Localization
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=45277**See Also**: {T47277}TASK DETAILhttps
Tgr added a comment.
In T107595#2791067, @TomT0m wrote:
If I understand correctly, this feature will potentially allow to view an article with the versions of the templates that existed at the time the wikitext was edited.
You might be thinking of Memento (which is not related to this in any
Tgr added a parent task: T111303: Create password verification API with AuthManager.
TASK DETAILhttps://phabricator.wikimedia.org/T47843EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, TgrCc: gerritbot, Nikerabbit, Tgr, bearND, MZMcBride, Fhocutt
Tgr edited the task description. (Show Details)
EDIT DETAILSTo be considered:
* HttpFunctions.php* includes/http
* MultiHttpClient...TASK DETAILhttps://phabricator.wikimedia.org/T110022EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: Lydia_Pintscher
Tgr added a comment.
I poked at librarizing includes/http recently - the dependencies are CookieJar, Status[Value] and at-ease. So StatusValue would have to be librarized first. Also the current interface is rather ugly.TASK DETAILhttps://phabricator.wikimedia.org/T110022EMAIL PREFERENCEShttps
Tgr added a comment.
The old task for that was T59298.
You'd probably have to kill off mw.mmv.MultimediaViewer.thumbs and replace it with some kind of iterator object that can return the mw.mmv.LightboxImage for the next and previous images (or an array of them if you want to be forwards
Tgr triaged this task as "Unbreak Now!" priority.Tgr added a comment.Herald added subscribers: Jay8g, TerraCodes.
This is causing T153597: mediawiki-extensions-qunit-jessie tests are failing, per https://gerrit.wikimedia.org/r/#/c/328327/TASK DETAILhttps://phabricator.wikimedia.org/T1
Tgr closed this task as "Resolved".Tgr added a comment.
In T153729#2889274, @Nikerabbit wrote:
https://gerrit.wikimedia.org/r/#/c/328327 is not public or viewable, btw.
Huh, didn't know gerrit can do that (I was using the "create new change" button). Fixed now (but it wa
Tgr added a comment.
In T153729#2893117, @daniel wrote:
wfWarn should fail phpunit tests, but it perhaps should not fail qunit tests. How is that failure triggered?
XDebug warnings show up (since last weekend or so) in pages which should contain _javascript_ (Special:_javascript_Test/qunit
Tgr created this task.Tgr added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONhttps://integration.wikimedia.org/ci/job/mediawiki-extensions-qunit-jessie/19494/console
00:02:38 PHP Notice: Cannot find site mywiki in sites table [Called from Wikibase\Client
Tgr added a comment.
Would it be available for non-search functionality as well? Filtering change lists by category is something patrollers want very much.TASK DETAILhttps://phabricator.wikimedia.org/T165982EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Tgr added a comment.
I think this proposal mixes two different things in an unhelpful way:
Wikidata (AIUI) largely ignores legal protections on databases ("sui generis database rights") as these protections don't exist in the US. This is technically legal but creates legal uncertainty
Tgr claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T174036EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: Liuxinyu970226, TomT0m, Smalyshev, Lokal_Profil, -jem-, Aklapper, daniel, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF
Tgr added a comment.
Note that undo can span multiple revisions; if we go with this we need to disable that somehow. Also single-edit undos where the edit was created in some nonstandard way (e.g. hard revision deletion).TASK DETAILhttps://phabricator.wikimedia.org/T194412EMAIL PREFERENCEShttps
Tgr added a comment.
So just let the user load the undo screen and show an error message if more than one slot changed? I guess that makes more sense.TASK DETAILhttps://phabricator.wikimedia.org/T194412EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc
Tgr added a comment.
Do editors have rights over infobox data? Individual facts are not copyrightable; collections of infobox data could maybe be copyrighted if they were curated by an organization with a legal personality, or a well-defined group of authors, but that is not the case
Tgr added a comment.
DifferenceEngine is a god class which does everything from interpreting query parameters for selecting the target revision to direct DB queries to table formatting to writing to OutputPage. Also extensions can replace it with a subclass. So a proper solution will involve
Tgr updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...SHORTDESC should support `{{SHORRTDESC:...|noreplace}}` like DISPLAYTITLE and other things do, so that templates can mark their values as fallback ones.TASK DETAILhttps://phabricator.wikimedia.org/T193857EMAIL
Tgr added a comment.
In T174036#4208313, @Anomie wrote:
Chances are that most of the database lookup logic, header formatting, and so on would need to be extracted to a different class, so the object returned by ContentHandler can handle only the actual diff logic.
Sure, I just don't want
Tgr added a comment.
To be clear, this is not something that exists for SHORTDESC currently. Shouldn't be hard to add though, and other magic words already use the mechanism so it won't make things more complex than they already are.TASK DETAILhttps://phabricator.wikimedia.org/T193857EMAIL
Tgr renamed this task from "Short description magic word stores last instance on page" to "Support 'noreplace' keyword in {{SHORTDESC}}".Tgr added a project: Reading-Infrastructure-Team-Backlog (Kanban).Tgr updated the task description. (Show Details)
CHANGES TO TASK DESCR
Tgr added a comment.
Every magic word with a side effect works in a last-one-wins manner; it would be pretty confusing to change that just for this one, IMO. Anyway, probably better to discuss in a new task than an already-closed one.TASK DETAILhttps://phabricator.wikimedia.org/T184000EMAIL
Tgr added a comment.
I can see why people want to put the description on the top of the wikitext. On the other hand, every magic word / parser function overrides the side effect of earlier invocations with that of later ones, and I don't think it's a good idea to change that - wikitext is complex
Tgr added a comment.
The mcr-dev project has three machines now:
mcr-base.wmflabs.org (box: mcr-base.mcr-dev.eqiad.wmflabs) is a plain MediaWiki (via Labs-Vagrant), with 405015 and 434183 cherry-picked
mcr-full.wmflabs.org (box: mcr-full.mcr-dev.eqiad.wmflabs) is for testing lots of extensions
Tgr added a comment.
@Bstorm can you add me to the list of admins? @Addshore and @aude are not working on this ATM.TASK DETAILhttps://phabricator.wikimedia.org/T194239EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Bstorm, TgrCc: Bstorm, bd808, Tgr, daniel
Tgr added a comment.
It would involve creating new DifferenceEngine instances for each non-main slot, sure. But given that DifferenceEngine does everything including revision lookup, and pretty much all its method are public (and some set public properties as a side effect) having Article handle
Tgr created this task.Tgr added projects: Reading-Infrastructure-Team-Backlog, Security-Extensions, MediaWiki-extensions-WikibaseClient, Security.Herald added a subscriber: Aklapper.Herald added a project: Wikidata.
TASK DESCRIPTIONPage descriptions coming from Wikidata (whether via
Tgr added a comment.
mcr-full works fine for manual testing but most of the selenium tests fail, probably due to some of the extensions interfering. I'm not sure how to track that down without visuals, and could not get that to work (T196646: Running selenium inside Vagrant with xvfb or X11 does
Tgr updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...* [[http://mcr-sdc.wmflabs.org/wiki/Main_Page|mcr-sdc.wmflabs.org]] (box: mcr-sdc.mcr-dev.eqiad.wmflabs) - SDC-like testing environment (WIP)
TASK DETAILhttps://phabricator.wikimedia.org/T192306EMAIL PREFERENCEShttps
Tgr added a comment.
Test plan was https://www.mediawiki.org/wiki/User:Daniel_Kinzler_(WMDE)/MCR-StorageLayerTesting#PageUpdater_test_plan. All tests either passed or failed on master as well (those will be repeated on beta after merging).TASK DETAILhttps://phabricator.wikimedia.org/T196653EMAIL
Tgr closed this task as "Resolved".Tgr added a comment.
Has been in production for a couple days. Please reopen if it's not working as expected.TASK DETAILhttps://phabricator.wikimedia.org/T193857EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Tgr closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T195790EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: gerritbot, Aklapper, Tgr, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30,
Tgr closed this task as "Resolved".Tgr added a comment.
Done; seems like gerritbot sent the notification to the wrong ticket somehow.TASK DETAILhttps://phabricator.wikimedia.org/T191830EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: LGoto, W
Tgr created this task.Tgr added projects: MediaWiki-extensions-WikibaseClient, Reading-Infrastructure-Team-Backlog (Kanban).Herald added a subscriber: Aklapper.Herald added a project: Wikidata.
TASK DESCRIPTIONPer T195551: [BUG] Formatting in local descriptions is breaking use of descriptions
Tgr added a parent task: T195551: [BUG] Formatting in local descriptions is breaking use of descriptions (example: San Francisco article).
TASK DETAILhttps://phabricator.wikimedia.org/T195790EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: Aklapper, Tgr
Tgr added a comment.
Yeah, those pages were parsed during the outage and the script trying to fetch from Wikidata returned an error message, and that got cached with the rest of the parsing output. It will go away the next time the page is parsed (in 30 days if not triggered sooner manually
Tgr added a comment.
tgr@mcr-full:/srv/mediawiki-vagrant$ vagrant roles list -e
Enabled roles:
abusefiltereventlogging newusermessage
antispam flow templatesandbox
babel geodata
Tgr removed a subtask: T193185: Increase quota for wikidata-federation project.
TASK DETAILhttps://phabricator.wikimedia.org/T192306EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: aude, Tgr, bd808, CCicalese_WMF, Abit, Addshore, Aklapper, daniel, Lahi
1 - 100 of 320 matches
Mail list logo
