Sorry for cross-posting!
Reminder: Technical Advice IRC meeting again **Wednesday 3-4 pm UTC** on
#wikimedia-tech.
The Technical Advice IRC Meeting (TAIM) is a weekly support event for
volunteer developers. Every Wednesday, two full-time developers are
available to help you with all your questions about Mediawiki, gadgets,
tools and more! This can be anything from "how to get started" over "who
would be the best contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
Hope to see you there!
Michi (for the Technical Advice IRC Meeting crew)
--
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hi All,
TechCom is hosting an IRC discussion on RFC: Block users by
page/namespace <https://phabricator.wikimedia.org/T199917> this
Wednesday August 8th at 2pm PST(21:00 UTC, 23:00 CEST) in #wikimediaoffice
The goal of the Partial Blocks project is to give wiki administrators a
more robust set of tools to be able to better respond to different user
conflict situations. To retain constructive contributors who cause
disruption on one page (e.g. contentious article page, user talk page of
someone they constantly berate, etc.) we want to give admins the ability
to block them from editing specific pages and/or all articles inside a
namespace.
If you haven't joined a #wikimediaoffice meeting before more information
can be found here:
<https://meta.wikimedia.org/wiki/IRC_office_hours#How_to_participate>
More information regarding the TechCom RFC process is available here:
https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Processes#RFC_…
Thanks,
Kate
--
Kate Chapman TechCom Facilitator (Contractor)
Hello.
The team working on TemplateStyles at the Wikimedia Foundation would
like to enable TemplateStyles on all Wikimedia later this week.
TemplateStyles is a feature to allow non-administrators to write and
manage CSS styles for templates. It allows contributors who edit
templates to separate content and presentation. A good web practice
that makes it easier to manage the layout of templates. If you don't
edit templates, this will not have any impact on your contributions.
TemplateStyles is useful for a few reasons.
* It makes it possible for templates to work better on mobile.
* It cuts out confusion on where to apply CSS rules.
* Editing CSS is currently limited to administrators, which is a major
barrier to participation.
* All stylesheets must be loaded on all pages (whether they actually
use the page or not), which wastes bandwidth and makes debugging style
rules more difficult.
You can learn more about TemplateStyles on MediaWiki.org.[0] Technical
documentation is also available.[1]
This is an optional feature and no one must use it, but template
contributors are encouraged to do so! Please discuss and let us know
if there are any concerns. If there are no concerns we will proceed to
deploy the feature on the 9th of August.
[0] https://www.mediawiki.org/wiki/Help:TemplateStyles
[1] https://www.mediawiki.org/wiki/Extension:TemplateStyles
Yours,
Chris Koerner
Community Relations Specialist
Wikimedia Foundation
Hey,
Some people reported that they have trouble labelling edits in wikilabels
[1] (specially for Wikidata and that's why I'm cross-posting to wikidata-l
too). That was due to the fact that wikilabels is behind a proxy on cloud
VPS which confuses the application and sometimes it thinks the request is
made over HTTP and changes the links/redirects to http instead of https and
basically jumping over to SSL and not-SSL continuously causing OAuth
redirect loops (because cookies can't jump around like requests). There
were several options but the most secure and sane one was to enforce SSL
and tell the application to consider everything as SSL request.
This would solve lots of bugs and issues in wikilabels. We apologize for
any inconvenience caused by it. It was difficult to understand the
underlying problem because it was happening for some people and not all and
was hard to reproduce the bug.
Also, If you encounter any (new) issue, Please let me know immediately.
More info: https://phabricator.wikimedia.org/T184437
[1]: https://labels.wmflabs.org/
Best
--
Amir Sarabadani
Software Engineer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland – Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
On Sun, Jul 29, 2018 at 4:30 PM, Bryan Davis <bd808(a)wikimedia.org> wrote:
> On Sun, Jul 29, 2018 at 12:37 AM rupert THURNER
> <rupert.thurner(a)gmail.com> wrote:
> >
> > if one takes an example, lke https://tools.wmflabs.org/video2commons/,
> is
> > this implemented like it should? is there any difference from "any"
> > application or applications on the tools server? am looking at the code
> > here currently:
> > https://github.com/toolforge/video2commons/blob/master/
> video2commons/frontend/app.py
> > the "dologin" method.
>
> Yes, there is a major difference between a web application like the
> video2commons tool and a device native application like an Android
> app. That difference is that in a web application secret data can be
> kept on the web server side that is not visible to the end user. This
> allows the OAuth application secret to be used in signing requests to
> the Wikimedia servers without exposing that secret to anyone who is
> looking at the source code of the web application. This separation is
> not possible when the application is running on end-user controlled
> devices as a phone or desktop application does.
>
>
interesting, never thought about it. i found an entry on stackexchange
confirming what you said. additionally it states that oauth is not for
authenticaiton. oauth's purpose is to access users resources from some
resource provider, while openid_connect should be used to authenticate.
does openid_connect work with wikipedia and is it the best option currently?
[0]
https://security.stackexchange.com/questions/133065/why-is-it-a-bad-idea-to…
[1] https://connect2id.com/learn/openid-connect
[2] https://www.mediawiki.org/wiki/Extension:OpenID_Connect
rupert
Hi, i have created this task [1] with i have uploaded this patch [2] to make polygerrit the default ui.
The reason why is upstream are preparing to remove the gwtui very soon. In matter of fact upstream have disabled the gwtui on *.googlesource.com. Upstream already have this change [3] to remove the ui. Making PolyGerrit the default ui will get new users use to the new ui.
GWTUI will still be available with ui switcher in the footer or you can append the url like https://gerrit.wikimedia.org/r/?polygerrit=0
PolyGerrit is stable, secure and also fast. It also has features that you cannot see in gwtui like user status, naming your patchiest (description), cc feature and also being able to tell who added you as a reviewer.
This email is advanced notice before we change the default ui.
any bugs todo with polygerrit / gerrit can be filled at https://phabricator.wikimedia.org/project/view/330/ and we can forward it upstream.
[1] https://phabricator.wikimedia.org/T196812
[2] https://gerrit.wikimedia.org/r/c/operations/puppet/+/439444
[3] https://gerrit-review.googlesource.com/c/gerrit/+/116790
Is there a way to use the allimages API to get categories applied to each File: page? If not, would it make sense to suggest adding a categories property using Phabricator or by some other communication channel?
https://www.mediawiki.org/wiki/API:Allimages
Thank you,
Michael