[Wikitech-l] Re: PHP RFC: Deprecate dynamic properties

[Max Semenik]

On Sat, Nov 13, 2021 at 6:01 PM Thiemo Kreuz 
wrote:

> Can we get this the other way around, being able to mark classes
> with #[DisallowDynamicProperties]?
>

That would mean every coding convention around would demand that every
class should have this on. Feels like cruft to me.

-- 
Best regards,
Max Semenik
___
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/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Phasing out old jQuery versions

[Max Semenik]

Huh, I see warnings from it on enwiki even when loading pages anonymously.
Gonna be fun)

On Sat, Aug 7, 2021 at 3:52 PM Amir Sarabadani  wrote:

> Hi,
> (If you don't use jQuery in your code or gadgets, you can ignore this
> email)
>
> in 2017 jQuery 3 got deployed to production and a backward compatibility
> layer was introduced to prevent old codes from breaking. Since then it has
> been emitting warnings in your console. All start with "JQMIGRATE". Some of
> these old jquery breaking changes have been deprecated in versions released
> in 2006 or 2007.
>
> We are slowly pulling the plug and removing that compatibility layer
> (which would reduce the default payload and make Wikipedia faster for
> everyone). Yesterday, that layer was removed from mediawiki CI, tests in
> gated extensions have passed but there is a chance that your extension
> might be broken in CI now if it's not part of gated extensions. In that
> case, please fix the errors.
>
> We will move forward to deploy this in Wikimedia wikis soon meaning really
> old gadgets will also break if they don't fix their code. Please check your
> console and if you see jquery migration deprecation warnings, attend to
> them because they will break soon. Firefox doesn't give trace to warnings
> anymore but in Chrome (and using ?debug=1) you can easily find the source
> of deprecation warnings.
>
> We already fixed many usages in code and gadgets and we will make sure to
> fix heavily used gadgets and user scripts but we can't possibly fix
> everything and it's the maintainers' responsibility to fix deprecation
> warnings that is being emitted for years.
>
> Another aspect is that if you use jquery.ui, this library has been
> deprecated as well and I recommend moving away from it but if you still use
> it and migration can be hard, we patched our jquery.ui fork to make sure it
> doesn't break. Still, if you find a part of jquery.ui that has not been
> fixed, let me know.
>
> You can track the work in https://phabricator.wikimedia.org/T280944 and
> the metrics of deprecations can be found in
> https://grafana.wikimedia.org/d/00037/mw-js-deprecate?orgId=1=1m=now-90d=now=24h
>
> Thank you and sorry for the inconvenience.
> --
> Amir (he/him)
>
> ___
> 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/postorius/lists/wikitech-l.lists.wikimedia.org/



-- 
Best regards,
Max Semenik
___
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/postorius/lists/wikitech-l.lists.wikimedia.org/

Re: [Wikitech-l] 1st CfP: SEMANTiCS 2021 EU || Sep 6 - 9, 2021 || Amsterdam, The Netherlands

[Max Semenik]

On Fri, Dec 25, 2020 at 1:21 PM Sebastian Hellmann <
pr-a...@informatik.uni-leipzig.de> wrote:

> Apologies for cross-posting


Apologies not accepted. Don't know about others on this list, but I'm tired
of your spam of conferences very remotely related to MediaWiki development.
MediaWiki is not Semantic MediaWiki, 99% of people here don't care about
your stuff. Please stop.

-- 
Best regards,
Max Semenik
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Allow HTML email

[Max Semenik]

On Thu, Sep 24, 2020 at 12:55 AM AntiCompositeNumber <
anticompositenum...@gmail.com> wrote:

> *HTML email is a scourge.*
>

Welcome to the future! Every new thing introduces new problems, but we
kinda can't stop the progress.

-- 
Best regards,
Max Semenik
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposed breaking change to Command::restrict()

[Max Semenik]

Maybe introduce a function like removeRestrictions()?

On Wed, Jul 8, 2020 at 2:53 PM Kunal Mehta  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> I'm proposing a breaking change to
> MediaWiki\Shell\Command::restrict(). I made a mistake in my original
> implementation of this function that I believe we're better off
> fixing. For background on what shell restrictions are, see
> <https://www.mediawiki.org/wiki/Manual:Shell_framework#Restrictions>.
>
> To summarize the ticket I filed
> <https://phabricator.wikimedia.org/T257278>:
>
> Command manages $restrictions as bitfields and by default sets it to
> Shell::RESTRICT_DEFAULT (39). To disable restrictions, the idea was to
> call ->restrict( Shell::RESTRICT_NONE );. However, ->restrict() adds
> to $restrictions (using |=) instead of overwriting...so it's
> impossible to disable a default restriction.
>
> My proposal is to have ->restrict() overwrite the current
> $restrictions instead of adding to it. Based on codesearch, every
> non-test caller is already set up to work this way, so in practice, it
> shouldn't be a breaking change.
>
> The Gerrit patch for this is
> <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/609870/> and
> contains multiple examples of the correct way to call the fixed function
> .
>
> Comments, alternative suggestions welcome. I would like to get this in
> for 1.35 if possible.
>
> Thanks,
> - -- Legoktm
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAl8Fs30ACgkQ8QX4EBsF
> JptHyA//Uo5h3l4EUTJlBNIoOR1jKlN7onKfzHZrxDPKvLDlBCrAYB9YLkxZ6Pfb
> /SP8c0mUH5UvQBH+SL/qZPmHTfwbnB1auOuyzu+XedFZxET26kh29glWSwbxf9KL
> i+7dAuO8gFM/q7gIuYMCc+TmZu+SQEOgr4Ek+iD/fIcQondpxmzaAdTUJ8UPn9a0
> OLONdqo7elFM8VRID0YlIzO4DCKymmpW/aEiJChOTxy11IUr4ZQ8n1r8aY66LZ2y
> qlsm00hofPkVH19Pjqj5T1E80etUcMwh6uVdpctgJBNFXNYIuaAG6sHatbZXH3WJ
> /zIfzhNBXB19233fQ3Cn/f+fLYXQPGxw5Z/ATEtlHSAFAeWwXtkpvOED0fAO0X8r
> 0BbAdHkWYPkbGTPimrf5R1dwvmnw09p4qGUMGGb9Nw6KwsJpOMoZL8oBMa120ktI
> FzJ6EPB3iv1XbsY1IOaekmdThISV/V1pB4PpteqpK44li+1kPCg4sJIqyaFMG86p
> ejgzlXMiLw8g9skezFGsZJeaUbGwu+Fu0GuAQ/4+py50jsmAEsO49u6md7TtzhUu
> Loa39JpisHk6Kk5otfL+f1b8MWNBBVuqixQTCL/T78G3jfotG9swjuqqKq8MNY6U
> qgx2lL8LEEaUik7MwhvxJ00A6p89HV9KTezTdwmlwWwmKA83ec0=
> =HouQ
> -END PGP SIGNATURE-
>
> _______
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Best regards,
Max Semenik
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki has been upgraded to PHPUnit 8

[Max Semenik]

Thanks to awesome efforts of many volunteers and staff developers alike,
we're on 8.5 now. We don't expect too much fallout, however keep an eye for
occasional failures. Also, please check the test logs for your repositories
for warnings introduced in the new version. Since there will be no
deployments next week, we have some extra time to ensure everything works
smoothly.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Composer does not know mediawiki/mediawiki on dry-runs

[Max Semenik]

On Fri, Nov 15, 2019 at 4:16 PM Max Semenik  wrote:

> Which raises the question: should this functionality stay in MediaWiki at
> all?
>

I've pushed https://gerrit.wikimedia.org/r/551346 for review.

Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Composer does not know mediawiki/mediawiki on dry-runs

[Max Semenik]

On Fri, Nov 15, 2019 at 7:19 PM Sam Wilson  wrote:

> Where does the mediawiki/mediawiki package come from? It's no longer on
> Packagist; how does Composer know where to get it? It should certainly
> not appear as a requirement for any package.
>

ComposerHookHandler adds it programmatically.

As for removing the functionality: do you mean the functionality of the
> Composer merge plugin? i.e. that we can load dependencies in the
> MediaWiki root directory, rather than within each extension's directory?
>

I mean ComposerHookHandler and friends.


-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Composer does not know mediawiki/mediawiki on dry-runs

[Max Semenik]

On Fri, Nov 15, 2019 at 8:16 AM Brad Jorsch (Anomie) 
wrote:

> It also predated T467 RfC: Extension management with Composer
> <https://phabricator.wikimedia.org/T467>, which rejected the proposal to
> manage extensions via composer.


Which raises the question: should this functionality stay in MediaWiki at
all?

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Max Semenik]

I don't think it's possible to filter by flagged status, however you can
combine this information with recent changes:
https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:ApiSandbox#action=query=json=flagged=recentchanges=2

On Wed, Mar 13, 2019 at 8:52 AM Сибирев Кирилл 
wrote:

> Hi, i can't find information about filtering pending changes through api,
> can someone
> help with my previous questions?
>
> 06.03.2019, 13:32, "Сибирев Кирилл" :
> > 05.03.2019, 19:33, "bawolff" :
> >>  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), that means a pending
> >>  change, which is a different system from patrolling.
> >>
> >>  Note, on enwikipedia (but not other projects) RC patrolling is
> disabled,
> >>  and only new page patrol is enabled (so only the first revision can
> have a
> >>  patrol status).
> >
> > Thanks for the answer, i'm little bit confused by naming here, i guess.
> > Mostly we use ru.wikipedia.org, where a lot of pages have blue/yellow
> markup
> > and legend for blue can be translated as "patrolled version", and yellow
> is "unverified version"
> > (here screenshot of what i am talking about
> https://yadi.sk/i/A0FRG6yz86ECdg)
> >
> > So, if i did understand you correctly, blue/yellow markup is about
> pending changes
> > (https://en.wikipedia.org/wiki/Wikipedia:Pending_changes) and not
> patrolling
> > (https://www.mediawiki.org/wiki/Help:Patrolling), am i right?
> >
> > Basically we want to get from api same data which users see on wikipedia
> article page
> > and as far as i understand yellow changes are not visible until approved.
> > Can you send me some page about comparing pending and patrolling,
> because for now
> > i can't understand if the two system can be applied to one page and what
> happens
> > if revision is patrolled (does it become approved and not pending after
> that)?
> >
> > If pending system is responsible for revision visibility on article page
> then it is
> > not matter to us what patrolling does, i guess.
> > But in that case we need to get pending property of revision from API,
> is it accessible?
> >
> >>  --
> >>  Brian
> >>
> >>  On Tue, Mar 5, 2019 at 4:13 PM Сибирев Кирилл 
> >>  wrote:
> >>
> >>>   Hi, we are using wikimedia http api for getting pages recent changes
> [1].
> >>>   We'd like to be able to distinguish patrolled and unpatrolled
> revisions and
> >>>   this feature is supported according to docs, but we still can't use
> it
> >>>   because of access permissions. For example if i making requests like
> [2] or
> >>>   [3] i am getting {"code": "permissiondenied", "info": "You need the
> >>>   \"patrol\" or \"patrolmarks\" right to request the patrolled flag."}
> error.
> >>>
> >>>   This API behaviour looks inconsistent to me, because anyone can see
> >>>   patrolled/unpatrolled colored markup at wikipedia revision history
> web
> >>>   pages. I think patrol right should be checked only at write (ones
> that mark
> >>>   revisions patrolled or not) API requests and not for read requests.
> >>>
> >>>   Is this behaviour really inconsistent and implemented that way due to
> >>>   technical restrictions or am i missing something? Can it be changed,
> so we
> >>>   can get patrolling information for revisions or maybe there are some
> >>>   workarounds exist?
> >>>
> >>>   [1] https://www.mediawiki.org/wiki/API:RecentChanges
> >>>   [2]
> >>>
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=title|patrolled=3
> >>>   [3]
> >>>
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=title=patrolled=3
> >>>
> >>>   ___
> >>>   Wikitech-l mailing list
> >>>   Wikitech-l@lists.wikimedia.org
> >>>   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >>
> >>  ___
> >>  Wikitech-l mailing list
> >>  Wikitech-l@lists.wikimedia.org
> >>  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Call for maintainers: Configure extension

[Max Semenik]

This extension has been out of date with MediaWiki for years. A ticket[1]
was opened a while ago to archive it, and someone archived the extension's
page[2] on mediawiki.org. Is there anyone interested in maintaining it, or
we can officially call it dead?


[1] https://phabricator.wikimedia.org/T185227
[2] https://www.mediawiki.org/wiki/Extension:Configure

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Voter Decision Support Systems Wikipedia Article

[Max Semenik]

This is a technical mailing list, please don't recruit meatpuppets here.

On Tue, Jan 1, 2019 at 3:36 PM Adam Sobieski 
wrote:

> Wikitech-l,
>
> Greetings. Recently, a discussion started with respect to deleting a
> Wikipedia page, Voter decision support system. The technologies of voter
> decision support systems are new. Pertinent Web standards are being
> advanced at the W3C Voter Decision Support Community Group (
> https://www.w3.org/community/voter-decision-support/).
>
> As to why we don’t already have voter decision support system software
> applications, as to why voters in modern democracies are not already
> supported with state-of-the-art software applications during and between
> election seasons, I indicate that a number of us are working on Web
> standards and schema to facilitate the development of such software
> applications. We can hope that software developers worldwide will find
> convenience from the standards and schema work underway at the W3C and IPTC.
>
> I wanted to bring the matter to your attention, to invite each of you to
> review the article, to invite each of you to observe the new W3C Community
> Group, and to invite each of you join the debate with respect to whether
> the encyclopedia article should be deleted:
> https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Voter_decision_support_system
> .
>
>
> Thank you,
> Adam Sobieski
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Looking for maintainers: RelatedSites

[Max Semenik]

Hey Brian, I didn't say it was going to happen any time soon. However, we
routinely archive extensions that have bitrotten to death, which having a
maintainer can prevent.

On Mon, Nov 5, 2018 at 5:04 PM Brian Wolff  wrote:

> Lots of extensions are maintainerless. I dont see why that implies it will
> eventually have to be archived. Perhaps the day will come when it no longer
> works with modern mediawiki, but until that day comes, why not leave it be?
>
> --
> brian
>
> On Monday, November 5, 2018, Max Semenik  wrote:
> > As RelatedSites extension has been undeployed from Wikimedia projects
> > today[1], a question arises: who will maintain it in the future? Unless
> > someone volunteers to maintain it, we will probably eventually have to
> > archive the repository. According to WikiApiary[2], besides WMF it's used
> > only on vojnaenciklopedija.com (ping Zoranzoki21).
> >
> > 
> > [1] https://phabricator.wikimedia.org/T128326
> > [2] https://wikiapiary.com/wiki/Extension:RelatedSites
> > --
> > Best regards,
> > Max Semenik ([[User:MaxSem]])
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Looking for maintainers: RelatedSites

[Max Semenik]

As RelatedSites extension has been undeployed from Wikimedia projects
today[1], a question arises: who will maintain it in the future? Unless
someone volunteers to maintain it, we will probably eventually have to
archive the repository. According to WikiApiary[2], besides WMF it's used
only on vojnaenciklopedija.com (ping Zoranzoki21).


[1] https://phabricator.wikimedia.org/T128326
[2] https://wikiapiary.com/wiki/Extension:RelatedSites
-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Max Semenik]

On Wed, Aug 8, 2018 at 5:08 PM, MZMcBride  wrote:
>
> The wikimedia-l mailing list is very specifically not within the purview
> of the mediawiki.org "Code of Conduct" or its associated committee.


CoC very explicitly states that it applies to "technical mailing lists

".
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] API breaking change: email-blacklist and echo-notifications-blacklist

[Max Semenik]

As part of work on T198935[1], the representation of preferences
`email-blacklist` and `echo-notifications-blacklist` returned by API
meta=userinfo has changed. Previously, they were by mistake returned as
arrays, which is unheard of in the API and resulted in weird output,
especially in XML:


  <_v>123
  <_v>456


At the same time, to change these preferences, you still had to use the
same format as DB storage, strings with newline-separated numbers. To
address this as well as a few other problems with conversion of preferences
on the storage-HtmlForm boundary, a fix[2] has been implemented that turned
these preferences newline-separated strings everywhere.

This fix will be deployed to WMF production next week. According to our API
usage analysis, there are unlikely any users this might affect, however
still please make sure you're ready.


[1] https://phabricator.wikimedia.org/T198935
[2] https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/444273/


-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator spam - account approval requirement enabled

[Max Semenik]

We've got ourselves da MVP!

On Sun, Jul 1, 2018 at 12:51 AM, Leon Ziemba 
wrote:

> I wrote a rollback script, currently running as CommunityTechBot
> <https://phabricator.wikimedia.org/p/CommunityTechBot/> and previously
> Community
> Tech bot <https://phabricator.wikimedia.org/p/Community_Tech_bot/>. It
> seems to work, aside from setting the triage level, which hopefully isn't a
> huge deal. I can try to fix that later. It is also being slowed down by
> rate limiting. The script isn't quite shareable yet but when it is I'll
> publish it. Going to sleep now :)
>

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Max Semenik]

My personal opinion is twofold:

* The file shouldn't be mandatory because all policies should (and do)
apply automatically, there should be no magic spell to enable them on a
case by case basis. CODE_OF_CONDUCT.md is mostly a GitHub convention that
allows that site to indicate CoC terms in its interface.

* However, users who disagree with the rules of using our resources
shouldn't be using them. If you're using Gerrit/Phabricator/wikis/lists/etc,
you're bound by our community's rules as far as interactions there go. Your
personal interactions related to these extensions are kinda gray area,
however it's important to remember that these don't just happen out of
nothing. For example, if someone asks you a question related to your
extension, this is probably because they've found it on mw.org and
downloaded it from our Git or ExtensionDistributor. Therefore, while we
don't want to play thought police we at the same time can't pretend we
don't care about them non-private aspects.

That being said, which parts of the CoC do you have a problem with?

On Thu, Jun 7, 2018 at 2:01 PM, Yaron Koren  wrote:

> Hi,
>
> CODE_OF_CONDUCT.md is a file that was added to most MediaWiki extensions
> almost exactly a year ago. It reads, in full:
>
> "The development of this software is covered by a [Code of Conduct](
> https://www.mediawiki.org/wiki/Code_of_Conduct)."
>
> This file was added on the grounds that "Now that we have a Code of Conduct
> we need to advertise it." You can see the Phabricator task for adding the
> file everywhere, including a lot of debate over whether it's a good idea,
> here:
>
> https://phabricator.wikimedia.org/T165540
>
> I removed these files from all my extension directories pretty soon after
> they were added, on the grounds that I just think it's false information -
> the development of my extensions happens mostly on my and others' laptops,
> in private emails and so forth - not "Wikimedia spaces", and thus not
> covered by the Code of Conduct, according to the CoC. Some corporate
> person, for example, downloading my software, could see that file and think
> that they're bound by the Code of Conduct when sending me a patch, when in
> fact (for better or worse) they're not.
>
> That's how it went until two days ago, when Antoine Musso submitted a patch
> for my Site Settings extension (I don't know why that one specifically),
> re-adding the file. I rejected the patch, on the same grounds as before,
> but another developer, Chad Horohoe, overrode me and merged it in. That led
> to a discussion featuring Antoine, Chad, a few other WMF developers, and
> me, which you can find here:
>
> https://gerrit.wikimedia.org/r/#/c/437555/
>
> Some of the (unbelievable) highlights:
>
> - From Antoine: "Well then can we just archive this repository please?"
>
> - From Chad: "Yeah no that's not how it works. If it's being hosted on
> gerrit.wikimedia.org, it needs a CoC file. If you object to that, you can
> find hosting elsewhere."
>
> - From Amir Sarabadani: "Having CoC removed seems violation of CoC itself."
>
> That last one is interesting, because the Code of Conduct doesn't mention
> CODE_OF_CONDUCT.md at all. Which I would have thought Amir would know,
> given that he's now a member of the "Code of Conduct Committee". (!)
>
> Actually, CODE_OF_CONDUCT.md isn't really mentioned anywhere - it was never
> voted on, and I don't believe it was even a directive from WMF management.
> As far as I know, this was the work of a few solitary (can I say "rogue"?)
> WMF developers who happen to have the ability to modify all the
> repositories - and, I guess, are into advertising.
>
> Now, we could talk about whether the CODE_OF_CONDUCT.md file is a good idea
> - or whether it's even accurate - but I'd rather talk about the most
> pressing issue, which is that a few developers have seemingly threatened to
> delete my extensions from the Wikimedia Git repository.
> That leads me to a few questions:
>
> - Do developers like Chad Horohoe have the right to delete my extensions
> from the repository? (I'm guessing they have the ability.)
>
> - Is CODE_OF_CONDUCT.md now really mandatory?
>
> - Is there some kind of chain of command, or process, for determining these
> things, or are we in sort of a Wild West situation where whoever has the
> ability to modify or delete other people's extensions can do so without
> consequences?
>
> Any thoughts or insight on these questions are welcome. There are some
> disturbing implications to that thread, that I'd like to see resolved.
>
> -Yaron
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki and OpenID Connect

[Max Semenik]

Have you tried discussing this with the community? Let me tell you what
their reaction will be: "we don't care who you are, we care what are your
sources". Everywhere online, exposing your real life identity means a
possibility of real life problems: stalking, harassment, attempts to get
someone you have a content dispute with fired. And I'm not even theorizing:
all the above things have happened on Wikipedia, multiple times. Social
networks want to have people's confirmed identities so that they could sell
them to the highest bidder. We at Wikimedia are different - we want to know
as little about our users as possible, and a bit less than that.

On Fri, May 4, 2018 at 7:14 PM, Adam Sobieski <adamsobie...@hotmail.com>
wrote:

> Chad,
>
> I’m working on a new Wikipedia article, Account Verification (
> https://en.wikipedia.org/wiki/Account_verification).
> Account verification can enhance the quality of online services,
> mitigating sockpuppetry, bots, trolls, spam, vandalism, fake news,
> disinformation and election interference.
>
> Account verification was initially a feature for public figures and
> accounts of public interest, individuals in music, acting, fashion,
> government, politics, religion, journalism, media, sports, business and
> other key interest areas. Account verification was introduced to Twitter in
> June 2009, Google+ in August 2011, Facebook in February 2012, Instagram in
> December 2014, and Pinterest in June 2015.
>
> In July 2016, Twitter announced that, beyond public figures, any
> individual could apply for account verification. In March 2018, during a
> live-stream on Periscope, Jack Dorsey, co-founder and CEO of Twitter,
> discussed the idea of allowing any individual to get a verified account (
> https://variety.com/2018/digital/news/twitter-verified-
> account-open-everyone-1202722587/).
>
> In April 2018, Mark Zuckerberg, co-founder and CEO of Facebook, announced
> that purchasers of political or issue-based advertisements would be
> required to verify their identities and locations. He also indicated that
> Facebook would require individuals who manage large pages to be verified (
> https://www.facebook.com/zuck/posts/10104784125525891).
>
> These events of March and April of 2018 occurred just recently. These
> issues are both important and contemporary.
>
> I’m looking at administrative functions such as page protection and
> considering scenarios where one or more administrators would determine that
> a page requires a verified account to edit. “Verified users” would be
> another column in the table, Interaction of Wikipedia user groups and page
> protection levels, at: https://en.wikipedia.org/wiki/
> Wikipedia:Protection_policy#Overview_of_types_of_protection .
>
> I would like to respond to your question both quickly and thoroughly. This
> is part one (quickly) and I will work on part two (thoroughly) over the
> weekend and respond early next week.
>
>
> Best regards,
> Adam
>
> From: Chad<mailto:innocentkil...@gmail.com>
> Sent: Friday, May 4, 2018 9:03 PM
> To: Wikimedia developers<mailto:wikitech-l@lists.wikimedia.org>
> Subject: Re: [Wikitech-l] MediaWiki and OpenID Connect
>
> On Fri, May 4, 2018, 1:21 PM Adam Sobieski <adamsobie...@hotmail.com>
> wrote:
>
> > With such features, we can envision allowing groups of users or admins to
> > determine that certain articles require a verified account to edit.
> >
>
> Why would this be desirable?
>
> -Chad
>
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ¿Qué te hace feliz esta semana? / What's making you happy this week? (Week of 25 February 2018)

[Max Semenik]

Шта?

2018-02-25 21:41 GMT-08:00 Pine W <wiki.p...@gmail.com>:

> (Hello, I am trying something new this week by writing in Spanish. I am
> hoping to encourage people to contribute to this conversation in their
> preferred languages.)
>
> Hola, estoy intentando algo nuevo esta semana escribiendo en español.
> Espero
> animar a las personas a contribuir a esta conversación en sus idiomas
> preferidos.
>
> Algo que me hace feliz esta semana es la disponibilidad de "diffs visuales"
> como se describe en el Blog de la Fundación Wikimedia:
> https://blog.wikimedia.org/2018/02/20/visual-diffs/.
>
> ¿Qué te hace feliz esta semana?
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Adding extension to packagist under "mediawiki" vendor

[Max Semenik]

[0] is for what it says - developing libraries based on parts of MW code.
It has nothing to do with extension development. I'd advice you to use your
own vendor and mind that we don't officially support extension installation
via Composer at all.

1 февр. 2018 г. 7:08 пользователь "Tobias Oetterer" <
oette...@uni-paderborn.de> написал:

> Hey
>
>
>
> I have released a mediawiki extension and would like to make it available
> via composer. Obviously, I need the help of someone with access to the
> “mediawiki” vendor. I dug through the documentation on [0], especially the
> “Packagist guidelines” and tried to reach one of the listed people, alas to
> no avail. If anyone could point me in the right direction or better yet,
> has
> the needed permission to add [1] that would be wonderful.
>
>
>
>
>
> [0]: https://www.mediawiki.org/wiki/Manual:Developing_libraries
>
> [1]: https://github.com/oetterer/BootstrapComponents
>
>
>
> Cheers,
>
> Tobias
>
>
>
> --
>
> If this email is rather brief, it is not meant to be impolite but to
> respect
> your time.
>   http://five.sentenc.es
>
> No trees were killed to send this message, but a large number of electrons
> were terribly inconvenienced
>
>
>
> Paderborn University
>
> Zentrum IMT
>
> Warburger Straße 100
>
> 33098 Paderborn
>
>
>
> Office: N5.338
>
> Phone: 05251/60-2194
>
> Internet:   http://imt.uni-paderborn.de
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] FLIF for Wikimedia

[Max Semenik]

10 дек. 2017 г. 23:42 пользователь "Ruben Kelevra" 
написал:

So... to break the current discussion down, there is no hard "we
don't want this format" yet shown up.


Nope, you've been provided ample reasons why a phab ticket requesting this
will probably be declined on the spot.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for a developer support channel

[Max Semenik]

Who's gonna maintain this installation?

On Sat, Nov 18, 2017 at 1:57 PM, Niharika Kohli <nko...@wikimedia.org>
wrote:

> I'd like to add that having Discourse will provide the one thing IRC
> channels and mailing lists fail to - search capabilities. If you hangout on
> the #mediawiki IRC channel, you have probably noticed that we get a lot of
> repeat questions all the time. This would save everyone time and effort.
>
> Not to mention ease of use. Discourse is way more usable than IRC or
> mailing lists. Usability is the main reason there are so many questions
> about MediaWiki asked on Stackoverflow instead:
> https://stackoverflow.com/unanswered/tagged/mediawiki
> <https://stackoverflow.com/unanswered/tagged/mediawiki>,
> https://stackoverflow.com/questions/tagged/mediawiki-api?sort=newest
> <https://stackoverflow.com/questions/tagged/mediawiki-api?sort=newest>,
> https://stackoverflow.com/questions/tagged/mediawiki-extensions...
>
> I'd personally hope we can stop asking developers to go to IRC or mailing
> lists eventually and use Discourse/something else as a discussion forum for
> support.
>
> On Sat, Nov 18, 2017 at 1:31 PM, Quim Gil <q...@wikimedia.org> wrote:
>
> > Hi, I have expanded
> > https://www.mediawiki.org/wiki/Discourse#One_place_to_
> > seek_developer_support
> >
> > https://www.mediawiki.org/wiki/Project:Support_desk is the only channel
> > whose main purpose is to provide support. The volunteers maintaining are
> > the ones to decide about its future. There is no rush for any decisions
> > there. First we need to run a successful pilot.
> >
> > The rest of channels (like this mailing list) were created for something
> > else. If these channels stop receiving questions from new developers,
> they
> > will continue doing whatever they do now.
> >
> > > I'd like to understand how adding a venue will improve matters.
> >
> > For new developers arriving to our shores, being able to ask a first
> > question about any topic in one place with a familiar UI is a big
> > improvement over having to figure out a disseminated landscape of wiki
> Talk
> > pages, mailing lists and IRC channels (especially if they are not used to
> > any of these environments). The reason to propose this new space is them,
> > not us.
> >
> > On Sat, Nov 18, 2017 at 5:01 PM, MZMcBride <z...@mzmcbride.com> wrote:
> >
> > > Brian Wolff wrote:
> > > >On Friday, November 17, 2017, Quim Gil <q...@wikimedia.org> wrote:
> > > >> The Technical Collaboration team proposes the creation of a
> developer
> > > >> support channel focusing on newcomers, as part of our Onboarding New
> > > >> Developer program. We are proposing to create a site based on
> > Discourse
> > > >> (starting with a pilot in discourse-mediawiki.wmflabs.org) and to
> > point
> > > >>the many existing scattered channels there.
> > > >
> > > >What does point existing channels to discouse mean exactly? Are you
> > > >planning to shutdown any existing channels? If so, which ones?
> > >
> > > Excellent questions. I'd like to know the answers as well.
> > >
> > > I raised a similar point at
> > > <https://www.mediawiki.org/wiki/Talk:Discourse>. I skimmed
> > > <https://phabricator.wikimedia.org/T155678>, looking for some answers,
> > and
> > > I didn't find any.
> > >
> > > Quim, are you involved in MediaWiki support in places such as the
> > > #mediawiki IRC channel or the mediawiki-l mailing list? Are you
> involved
> > > in MediaWiki support elsewhere? I'm trying to better understand how it
> > > would be appropriate for you to seemingly suggest disrupting or
> shutting
> > > down these established and functioning venues. If this is not your
> > > suggestion, I'd like to understand how adding a venue will improve
> > matters.
> > >
> > > MZMcBride
> > >
> > >
> > >
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> >
> >
> >
> > --
> > Quim Gil
> > Engineering Community Manager @ Wikimedia Foundation
> > http://www.mediawiki.org/wiki/User:Qgil
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Niharika
> Software Engineer
> Community Tech
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Roadmap for continued compatibility with MySQL

[Max Semenik]

We have no plans of dropping support at the moment, though we had some
discussions about raising the minimum required versions (which are
ridiculously low at the moment).

On Thu, Oct 19, 2017 at 6:41 PM, Hogan, Michael C <
michael.c.hog...@boeing.com> wrote:

> How many years into the future is it reasonable to expect that MySQL will
> remain a recommended database server for "production use" along with
> MariaDB now that the Foundation has switched to using MariaDB internally? I
> know that MariaDB claims to be drop in compatible with MySQL, but the list
> of variances seems to be slowly growing. References...
> * Compatibility - [[mw:Compatibility]]
> * MariaDB support? - [[mw:Topic:R1hqki3kaytylml4]]
> * https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/
>
> Other than [[mw:Compatibility]] on mediawiki.org is there anywhere else
> (wiki pages, Phabricator tasks/tags, etc.) that I should check for
> technical roadmap information before emailing wikitech-l?
>
>
> Thank you!
> Michael
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HHVM vs. Zend divergence

[Max Semenik]

On Tue, Sep 19, 2017 at 8:37 PM, Tim Starling <tstarl...@wikimedia.org>
wrote:

> According to people on the ops team who have worked with them
> recently, they stopped working on the open source product altogether.
> They stopped responding to bug reports.


This makes it sound as if your estimation of one year to migrate off HHVM
is too long and we need to run for it even sooner.


-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HHVM vs. Zend divergence

[Max Semenik]

On Mon, Sep 18, 2017 at 2:33 PM, C. Scott Ananian <canan...@wikimedia.org>
wrote:

> Other tools we are using, such as Phabricator, will also be following HHVM
> to Hack (presumably).


To the contrary, Phabricator has never supported HHVM.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] HHVM vs. Zend divergence

[Max Semenik]

Today, the HHVM developers made an announcement[1] that they have plans of
ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
instead.

While this does not mean that we need to take an action immediately,
eventually we will have to decide something. As I see it, our options are:

1) Continue requiring that MediaWiki uses a common set of HHVM and Zend
PHP. This, however, is a dead end and will make things progressively harder
as the implementations will diverge and various Composer libraries we use
will start requiring some Zend-specific features.

2) Declare our loyalty to HHVM. This will result in most of our current
users being unable to upgrade, eventually producing what amounts to a
WMF-only product and lots of installations with outdated MediaWiki having
security holes. At least we will be able to convert to Hack eventually.
This is a very clean-cut case of vendor lock-in though, and if Facebook
decides to switch their code base to something shinier, we'll be deep in
trouble.

3) Revert WMF to Zend and forget about HHVM. This will result in
performance degradation, however it will not be that dramatic: when we
upgraded, we switched to HHVM from PHP 5.3 which was really outdated, while
5.6 and 7 provided nice performance improvements.

I personally think that 3) is the only viable option in the long run. What
do you think?


[1] http://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Recommending Firefox to users using legacy browsers?

[Max Semenik]

+1 to that. Additionally, the proposed method wouldn't even work because we
blacklist crappy browsers from receiving JS.

On Thu, Aug 31, 2017 at 1:37 PM, bawolff <bawolff...@gmail.com> wrote:

> On Thu, Aug 31, 2017 at 8:14 PM, Legoktm <legoktm.wikipe...@gmail.com>
> wrote:
> > Hello,
> >
> > This was something that came up during "The Big Open" at Wikimania, when
> > Katherine Maher talked with Ryan Merkley (CEO of Creative Commons) and
> > Mark Surman (ED of Mozilla Foundation). One of the themes mentioned was
> > that our projects need to work together and support each other.
> >
> > In that vein, I'm interested in what people think about promoting
> > Firefox to users who are using legacy browsers that we don't support at
> > Grade A (or some other criteria). As part of the "drop IE8 on XP"
> > project[1] we're already promoting Firefox as the alternative option. I
> > was imagining it could be a small and unobtrusive bubble
> > notification[2], similar to those that Google pushes Chrome on people
> with.
> >
> > If users use modern browsers, they're going to have better security
> > support, and most likely a better experience browsing Wikimedia sites
> > too. We'd be improving the web by reducing legacy browsers, and allowing
> > us to move forward with newer technology sooner (ideally).
> >
> > And we'd be supporting a project that is ideologically aligned with us:
> > Mozilla.
> >
> > Thoughts, opinions?
> >
> > [1] https://phabricator.wikimedia.org/T147199
> > [2] https://www.mediawiki.org/wiki/Bubble_notifications
> >
> > Thanks,
> > -- Legoktm
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> I'm concerned this would be seen as an inapropriate bias.
>
> Suggesting Firefox for IE8 on XP makes sense because it is basically
> the only option for that platform that is reasonably secure and not
> super obscure. Promoting firefox is general for legacy browsers seems
> like a slippery slope to me.
>
> Additionally, I think this is more a political than a technical
> decision, and one that would require consultation with the general
> Wikimedia community (e.g. Meta RFC).
>
> --
> Brian
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HTML5 sections update

[Max Semenik]

On Thu, Aug 3, 2017 at 3:48 PM, DaB. <w...@dabpunkt.eu> wrote:

> may I ask why the methods are named escapeSomething, when their result
> is not escaped?
>

They still escape the ID (even if as lightly as converting spaces to
underscores).

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HTML5 sections update

[Max Semenik]

On Thu, Aug 3, 2017 at 12:26 AM, Strainu <strain...@gmail.com> wrote:

> 1. Will this be included in the tech news?
>

Yes, I've added it.


> 2. How will the behavior of anchorencode change? Should it be removed
> from templates after the new IDs become default?


Anchorencode should not be removed: it still encodes links, just in a
different way.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] HTML5 sections update

[Max Semenik]

Hey, yesterday the patch implementing human-readable section IDs [0] was
merged (thanks, Tim!). The new feature has already been enabled on beta
cluster and you can try it yourselves, e.g. on [1] - some pages might still
have old HTML cached though and require a null edit to update.

What's next? We can probably flip it on testwiki after Wikimania, but
further deployments depend on Reading Web, Apps and Parsoid teams. We,
however, can already encourage editors to check it out in staging.

Unanswered question: do we really need to percent-encode the IDs? There is
extensive discussion of that in the aforementioned task, concluding that
percent-encoding is probably more "correct". However, not escaping it gives
much better browser compatibility (close to 100%). We can change this at
any time because no links will be broken due to the way browsers handle
percent-encoded fragments.

What's the impact for end users? When the commit above goes live, there
will be no user-visible changes, and almost no HTML changes at all (only
some interface IDs/classes generated from MediaWiki messages might slightly
change, but no links will be broken). When we migrate we will initially
enable new IDs as a fallback. After 1 month, the new IDs will become
default while old ones will be used as a fallback. This way, old links will
continue to work, and we have no plans to disable the fallbacks in the
foreseeable future.

What's the impact for developers? Sanitizer::escapeId() has been
deprecated, all code should migrate
to escapeIdForAttribute(), escapeIdForLink()
or escapeIdForExternalInterwiki(). Warning: unlike escapeId(), these
functions' output is not guaranteed to be HTML-safe so it must be escaped.
Our security guidelines say that everything should be HTML-safe anyway, so
even escapeId() should be properly escaped. The same deprecation happened
in JavaScript, mw.util.escapeId() is also deprecated.


[0] https://phabricator.wikimedia.org/T152540
[1]
https://ru.wikipedia.beta.wmflabs.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Human-readable section IDs

[Max Semenik]

Hey, the way non-Latin characters are displayed in section has always been
a serious complaint from our communities:
https://phabricator.wikimedia.org/T152540

Community tech has done some work in this area and it's ready to get more
eyeballs:
https://gerrit.wikimedia.org/r/#/c/362326/

A few words about implementation plan:
* There is now a concept of primary vs. fallback IDs. Primary are used for
linking, fallbacks are used so that old links still work.
* To transition to the new system, a wiki should first continue serving
legacy-encoded sections with new encoding as a fallback, then switch the
two after all older parser/HTTP caches have been filled with new HTML.
Legacy encoding should remain enabled as long as there is a noticeable
traffic using it, on WMF sites that probably means years.
* By default, MediaWiki will still behave exactly like before. Changing the
defaults to something more modern will be discussed later, after all the
initial issues are resolved.
* Because it's being used without escaping in so many places outside of
core and because there is now a fine distinction between ID escaping for
different purposes, Sanitizer::escapeId() is deprecated. It will never
output new encoding and should be replaced with one of escapeIdForHtml(),
escapeIdForLink() or escapeIdForExternalInterwiki() AFTER making sure it's
getting properly escaped.

Your help reviewing/testing/discussing this is highly appreciated!

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] use of @inheritdoc

[Max Semenik]

Meanwhile, I've encountered another problem that supports the point that we
need to document functions, this or another way: Phan barfs about functions
using Database::selectField().[1] I've suppressed the warnings for now, but
would like a more permanent solution.


-
[1]
https://integration.wikimedia.org/ci/job/mwext-php70-phan-jessie/2199/console

On Fri, May 19, 2017 at 3:12 AM, Jeroen De Dauw <jeroended...@gmail.com>
wrote:

> Hey,
>
> Personally I'm not using this in my projects and would object to those tags
> being added as they are IMO clutter. Those projects have some relevant
> differences with MediaWiki that all contribute to those tags being more
> clutter than helpful:
>
> * Good OO: small classes and interfaces, favoring of composition over
> inheritance and thus very rarely inheriting concrete code
> * Simple well named methods with no or few parameters: documentation
> explaining something beyond type is seldomly needed
> * Usage of scalar type hints, nullable type hints and return type hints via
> usage of PHP 7.1
>
> And of course following any of those points has benefits way beyond not
> needing inheritdoc tags as crutch.
>
> Cheers
>
> --
> Jeroen De Dauw | https://entropywins.wtf | https://keybase.io/jeroendedauw
> Software craftsmanship advocate
> ~=[,,_,,]:3
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Security announcement: XSS when Kartographer is used with JsonConfig

[Max Semenik]

A stored XSS vulnerability was discovered when Kartographer is configured
to receive map data from wiki pages via JsonConfig. Unless your wiki has
both extensions installed and JsonConfig is configured to provide map data,
it is safe. Otherwise, you're encouraged to upgrade both extensions
IMMEDIATELY.

Affected versions:
* Versions for latest MediaWiki release, 1.28, don't support the
aforementioned functionality and therefore are not vulnerable.
* Versions for pre-release 1.29 and alpha 1.30 are affected and have fixes
applied in source control.

Upgrading:
You can download latest sources from Git[1] or ExtensionDistributor[2]

See this ticket for more information:
https://phabricator.wikimedia.org/T163166


[1]
https://www.mediawiki.org/wiki/Download_from_Git#Using_Git_to_download_MediaWiki_extensions
[2] https://www.mediawiki.org/wiki/Special:ExtensionDistributor

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Nicer MediaWiki eval.php

[Max Semenik]

Looks really neat, however why not just replace eval.php with it?

On Thu, Feb 2, 2017 at 1:08 PM, Antoine Musso <hashar+...@free.fr> wrote:

> Hello,
>
> To interact with a MediaWiki installation, one typically uses
> maintenance/eval.php which let you executes command and get results
> interactively.
>
> It has several drawbacks though such as lack of code completion, colors or
> dieing on PHP fatal errors.
>
> There is a nice console for PHP: http://psysh.org/
>
> I eventually wrote a little patches to integrate it in a new script
> maintenance/console.php:
>
>  https://gerrit.wikimedia.org/r/#/c/334217/
>
>
> It is a very basic evening hack, but I would appreciate some early
> feedback about it.  Hopefully we can get it polished and eventually end up
> with a better command than eval.php :]
>
>
> Thx!
>
> --
> Antoine "hashar" Musso
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deprecation logging in production

[Max Semenik]

iki
> 1.23. [Called from SpecialRecentChanges::runMainQueryHook in
> /srv/mediawiki/php-1.29.0-wmf.8/includes/specials/SpecialRecentchanges.ph
>
> Use of wfSetupSession was deprecated in MediaWiki 1.27. [Called from
> CollectionSession::startSession in
> /srv/mediawiki/php-1.29.0-wmf.8/extensions/Collection/
> Collection.session.php
> at line 38]
>
> Use of SpecialWatchlistQuery hook (used in
> FlaggedRevsUIHooks::modifyChangesListQuery) was deprecated in MediaWiki
> 1.23. [Called from SpecialWatchlist::runMainQueryHook in
> /srv/mediawiki/php-1.29.0-wmf.8/includes/specials/SpecialWatchlist.php at
> line 309]
>
> Use of Revision::getText was deprecated in MediaWiki 1.21. [Called from
> FlaggedRevision::getRevText in
> /srv/mediawiki/php-1.29.0-wmf.8/extensions/FlaggedRevs/
> backend/FlaggedRevision.php
> at line 480]
>
> Use of SpecialRecentChangesQuery hook (used in
> FlaggedRevsUIHooks::modifyRecentChangesQuery) was deprecated in MediaWiki
> 1.23. [Called from SpecialRecentChanges::runMainQueryHook in
> /srv/mediawiki/php-1.29.0-wmf.9/includes/specials/SpecialRecentchanges.ph
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [RFC] Giving actual CSRF tokens to not logged in users (T40417)

[Max Semenik]

On Thu, Sep 29, 2016 at 1:37 PM, Brad Jorsch (Anomie) <bjor...@wikimedia.org
> wrote:

> On Thu, Sep 29, 2016 at 4:00 PM, Brian Wolff <bawo...@gmail.com> wrote:
>
> > This way it will work for users without cookies (Maybe none exist, but I
> > like the idea you can edit wikipedia without cookies)
>
>
> There have been people who disabled cookies and still wanted to be able to
> use the sites.
>

For the good of most, I think it would be acceptable to require a very few
to enable cookies to *edit*.


> > It will also have minimal breakage, as you won't have to adjust any
> > existing usages of tokens (For example, on special pages).
> >
>
> Note it will affect scripts and API clients that expect to see "+\" as the
> token as a sign that they're logged out, or worse assume that's the token
> and don't bother to fetch it.


We had breaking API/frontend infrastructure changes before, this one seems
less invasive and will break only badly written clients. In any case, most
clients are intended for logged in users.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Urgent help needed from WMF admins

[Max Semenik]

Fixed.

On Thu, Sep 22, 2016 at 6:43 PM, Huji Lee <huji.h...@gmail.com> wrote:

> Please see https://phabricator.wikimedia.org/T146440 and assist.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Incident report: Multiple breakages due to wfLoadExtension() transition

[Max Semenik]

On Wed, Aug 10, 2016 at 11:49 AM, Max Semenik <maxsem.w...@gmail.com> wrote:

> TLDR: migration of 2 extensions to wfLoadExtension() resulted in problems,
> Logstash wasn't displaying them.
>

Posted on Wikitech:
https://wikitech.wikimedia.org/wiki/Incident_documentation/20160809-MediaWiki


-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Incident report: Multiple breakages due to wfLoadExtension() transition

[Max Semenik]

TLDR: migration of 2 extensions to wfLoadExtension() resulted in problems,
Logstash wasn't displaying them.

== Timeline ==
Previous days
* In a massive effort by many people, lots of extensions were converted to
extension.json, including
** Timeline in https://gerrit.wikimedia.org/r/#/c/303248/
** ContactPage in https://gerrit.wikimedia.org/r/#/c/298084/
* These changes were not compatible with our current production
configuration and thus had to be accompanied with mediawiki-config changes
and probably be deployed separately to minimize the chance of screwup.
* Furthermore, even a cursory testing of the above Timeline change would
have shown that it is broken.

August 9
* After 12:00 SF time Mukunda deploys train to stage 0 wikis
* At 16:00 Max prepares for SWAT but sees errors in fatalmonitor and
investigates:
** Creating default object from empty value in
/srv/mediawiki/wmf-config/CommonSettings.php
on line 686
** Undefined variable: wgContactConfig in
/srv/mediawiki/wmf-config/CommonSettings.php
on line 968
* Max sees no such errors in Logstash.
* After identifying the cause, Max starts reverting the affected
extensions, however there were a lot of intermediate commits and Reedy was
committing fixes so Max proceeds with deploying the fixes instead.
* Fixes produced more problems. Max contemplates a revert of group0 back to
wmf.13 but decides not to because he has never done that before and fixes
kept on coming. In the hindsight, this was a mistake.
* Config fixes to accommodate for wmf.14 started causing notices in wmf.13
so Max resets wmf.13 Timeline to wmf.14.
* Errors indicating more breakages in Timeline prompt another batch of
fixes.
* At 17:42, everything is back to normal.

== Casualties ==

* Max's liver.

* Evening SWAT didn't happen.

* For about 10 minutes, new timeline generation on production wikis was
broken.


== Conclusions ==

* Our code review practices are lax, including merging hairy patches
without testing and self-merges.

* Timeline has 0 (zero) tests while just a single parser test would have
allowed to detect problems during code review.

* Logstash fatalmonitor dashboard isn't displaying HHVM warnings/errors
right now.

* And Logstash is used by scap to verify error levels, rendering this check
useless.

* Logstash/Kibana is probably too complex a beast to be trusted to be the
definitive source of MediaWiki health information, fatalmonitor is still
more reliable. Invest time in improving it and merging with
exceptionmonitor?

* In ongoing outage with logs full of noise, testing stuff on canary
servers is hard as non-fatal errors are easy to miss on fluorine. Deployers
need access to HHVM logs on all appservers.

* Beta cluster isn't serving its purpose of being the first line of defense
against bugs (other than "oh, whole thing is down"). Errors in beta should
be watched as closely as in prod and should be treated with the same level
of seriousness, because otherwise the former will eventually turn into the
latter.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Getting rid of $wgWellFormedXml = false;

[Max Semenik]

On Mon, May 2, 2016 at 3:04 PM, Brian Wolff <bawo...@gmail.com> wrote:

>
> There are references to it breaking people's screen scraping bots last time
> it was turned on. That was like 5 years ago though.
>

At this point, I would say that everybody who screen-scrapes saw it coming
and breaking them is a good thing as sometimes, lessons just have to be
learned.


Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Diff algorithms: the shootout

[Max Semenik]

All right, votes indicate that wikidiff3 is even better in quality, so here
we go:
https://gerrit.wikimedia.org/r/#/c/284003/ removes DairikiDiff. After it's
merged, I plan to refactor this area further and work on improving diff
quality now that we'll have 2 places to make changes instead of 3.

On Mon, Apr 18, 2016 at 1:56 PM, Antoine Musso <hashar+...@free.fr> wrote:

> Le 16/04/2016 04:00, MZMcBride a écrit :
> > Is there a related Phabricator Maniphest task about this? I'm not sure I
> > understand the motivation for making a switch. I would think that heavy
> > diffs are a very small portion of traffic.
>
> An intensive would be for MediaWiki core to only have a single diff
> system instead of two.
>
> For the historic part, wikidiff3 got introduced in August 2008:
>
>  https://www.mediawiki.org/wiki/Special:Code/MediaWiki/38653
>  commit e45cf2b8
>
>
> --
> Antoine "hashar" Musso
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Diff algorithms: the shootout

[Max Semenik]

Right now, MediaWiki has 2 pure-PHP engines to produce diffs (there's also
a native PHP extension wikidiff2, but we're not discussing it right now):
* DairikiDiff is what everybody uses, and
* Wikidiff3, and alternative implementation by Guy Van den Broeck that was
around for 8 years but required a configuration change
While less battle-tested, Wikidiff3 offers vastly improved performance on
heavy diffs compared to DairikiDiff. The price, however, is that it makes
certain shortcuts if the diff is too complex. I ran through 100K diffs from
English Wikipedia, and 6% of diffs were different. Lots of changes were
seemingly insignificant but I need your help with determining if it's
really so.

I've built this tool
<https://diff-forge.wmflabs.org/wiki/Special:DiffCompare>[1] to facilitate
the comparison. It displays two diffs from different algorithms side by
side (yeah, it can get too wide, I know:P). Which of them is which is
random. Parts with differences between the implementations are highlighted
in yellow. Below is the diff of differences for the reference. You can vote
with buttons above the diffs, no registration is required. If you see a
catastrophically bad diff please send me the link.

Unless the results are significantly worse, I'd like to go ahead and make
wikidiff3 the only implementation.

[1] https://diff-forge.wmflabs.org/wiki/Special:DiffCompare

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] New RFC: remove mbstring fallbacks

[Max Semenik]

Hey, I have a new topic I'd like to discuss. It's about mbstring and
whether do we really need to support running without it.

The RFC is at https://gerrit.wikimedia.org/r/#/c/267309/

Here's a copy:

MediaWiki currently relies heavily on Unicode support to provide support
for 300+ languages yet does not require the mbstring PHP extension to
function. Instead, we create PHP-only fallbacks if a native support is not
available. This creates a few problems:
* These fallbacks are extremely slow. The script in P2734
<https://phabricator.wikimedia.org/P2734> demonstrates that fallbacks are
roughly order of magnitude slower on PHP 5.6. In extreme cases, it can be
100+ times slower, per comment in Fallback.php).
* These fallbacks cover only a few functions. If there's no fallback,
either ad-hoc solutions are used in places, or, like in SwiftFileBackend,
we just say "mbstring is required".
* This also means that extensions can't expect any consistent Unicode
support.
* Won't somebody please think of the children!

Now that we've dramatically increased PHP requirements, we've already cut
off a lot of crappy environments so this change will likely not affect too
many users.

OS support:
* On Debian-based systems, a simple apt-get install php5 gives you mbstring
by default.
* On RPM-based, a separate package is required
* On Windows, people tend to use *AMP all-in-one packages that have
mbstring.


Current mbstring usage in core (excluding fallbacks themselves):

mediawiki/includes$ grep -orEh '\bmb_\w+' . | sort | uniq -c
   7 mb_check_encoding
   6 mb_convert_encoding
  12 mb_strlen
   4 mb_substr


Some time ago, I committed https://gerrit.wikimedia.org/r/#/c/267309/ to
start a discussion, but it went largely unnoticed so I'd like to start a
formal RFC.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Max Semenik]

PRO: preserving the blame history is a false hope because we liberally move
files around, extract classes to separate files and so on. In other words,
we do the usual refactoring work and in process we break blame at all
times. Syntax updates are just another refactoring, nothing principally
new. And no, when hell freezes over are inconsistent code standards better:
we already have a code base inconsistent enough after 15 years of
development and MUST avoid creating more.

On Fri, Feb 12, 2016 at 11:28 AM, Alex Monk <kren...@gmail.com> wrote:

> PRO from me, for all the reasons mentioned by legoktm
>
> On 12 February 2016 at 19:26, Legoktm <legoktm.wikipe...@gmail.com> wrote:
>
> > Hi,
> >
> > On 02/12/2016 07:27 AM, Daniel Kinzler wrote:
> > > Now that we target PHP 5.5, some people are itching to make use of some
> > new
> > > language features, like the new array syntax, e.g.
> > > <https://gerrit.wikimedia.org/r/#/c/269745/>.
> > >
> > > Mass changes like this, or similar changes relating to coding style,
> > tend to
> > > lead to controversy. I want to make sure we have a discussion about
> this
> > here,
> > > to avoid having the argument over and over on any such patch.
> > >
> > > Please give a quick PRO or CON response as a basis for discussion.
> > >
> > > In essence, the discussion boils down to two conflicting positions:
> > >
> > > PRO: do mass migration to the new syntax, style, or whatever, as soon
> as
> > > possible. This way, the codebase is in a consistent form, and that form
> > is the
> > > one we agreed is the best for readability. Doing changes like this is
> > > gratifying, because it's low hanging fruit: it's easy to do, and has
> > large
> > > visible impact (well ok, visible in the source).
> >
> > I'll offer an alternative, which is to convert all of them at once using
> > PHPCS and then enforce that all new patches use [] arrays. You then only
> > have one commit which changes everything, not hundreds you have to go
> > through while git blaming or looking in git log.
> >
> > > CON: don't do mass migration to new syntax, only start using new styles
> > and
> > > features when touching the respective bit of code anyway. The argument
> > is here
> > > that touching many lines of code, even if it's just for whitespace
> > changes,
> > > causes merge conflicts when doing backports and when rebasing patches.
> > E.g. if
> > > we touch half the files in the codebase to change to the new array
> > syntax, who
> > > is going to manually rebase the couple of hundred patches we have open?
> >
> > There's no need to do it manually. Just tell people to run the phpcs
> > autofixer before they rebase, and the result should be identical to
> > what's already there. And we can have PHPCS run in the other direction
> > for backports ([] -> array()).
> >
> > But if we don't do that, people are going to start converting things
> > manually whenever they work on the code, and you'll still end up with
> > hundreds of open patches needing rebase, except it can't be done
> > automatically anymore.
> >
> > > My personal vote is CON. No rebase hell please! Changing to the syntax
> > doesn't
> > > buy us anything.
> >
> > Consistency buys us a lot. New developers won't be confused on whether
> > to use [] or array(). It makes entry easier for people coming from other
> > languages where [] is used for lists.
> >
> > I think you're going to end up in rebase hell regardless, so we should
> > rip off the bandaid quickly and get it over with, and use the automated
> > tools we have to our advantage.
> >
> > So, if we're voting, I'm PRO.
> >
> > -- Legoktm
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bulk link rewrites for HTTP -> HTTPS migration?

[Max Semenik]

Fix them with a bot, for example AWB
<https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser>.

On Wed, Jan 13, 2016 at 9:09 AM, Chris Adams <ch...@improbable.org> wrote:

> I've been working with a number of colleagues getting ready to turn HTTPS
> on by default for various loc.gov domains. This has been fairly successful
> and we're working through the old legacy apps now.
>
> When that work completes, we'll have somewhere around half a million links
> which differ only in the URL scheme. What would be the best way to rewrite
> all of those URLs? I'd like to reduce the window during which users transit
> from HTTPS -> HTTP -> HTTPS.
>
> If anyone's curious, I've been collecting the links for a few dozen wikis
> in a somewhat oversized Git repo:
>
> https://github.com/acdha/lc-wikipedia-links
>
> The first site which has completely migrated is the much smaller World
> Digital Library which has just under four thousand links:
> https://gist.github.com/acdha/f785b22b356a9842439e
>
> Thanks,
> Chris
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] IRC office hours: Shared hosting

[Max Semenik]

James, your message is absolutely an offtopic in this thread aboud shared
hosting of MediaWiki installations by third parties. Could you raise your
concerns in a separate thread, not aiming them at Gilles who is completely
unable to help you as he's simply doing different stuff at the foundation?

On Mon, Dec 14, 2015 at 6:51 PM, James Salsman <jsals...@gmail.com> wrote:

> Hi Giles,
>
> I regret I will probably not be available for the IRC office hours as
> scheduled.
>
> In the discussion of shared hosting, I worry that en:User:Dispenser's
> reflinks project, which requires a 20 TB cache, is being forgotten
> again. He tried to host it himself, but it's offline again. This data
> is essential in maintaining an audit trail of references as long as
> the Internet Archive respects robots.txt retroactively, allowing those
> who inherit domains to censor them, even if they have already been
> used as a reference in Wikipedia. Keeping the cache is absolutely a
> fair use right in the US, in both statutory and case law, and it is
> essential to be able to track down patterns of attempts at deceptive
> editing to address quality concerns around deliberately biased editing
> such as paid editing. Because of the sensitivity of this goal, the
> Foundation should certainly bear the risk of hosting the reflinks
> cache. However, in the past, 20 TB was considered excessive, even
> though the cost was shown to be less than $5000 without whatever Dell
> NSA-enabled hardware you usually buy.
>
> Would you please reach out to en:User:Dispenser and offer them the
> 20TB hosting solution they need for the Foundation to bear the risk of
> the reflinks cache?  Thank you for your kind consideration.
>
> Best regards,
> Jim
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Max Semenik]

On Thu, Nov 12, 2015 at 11:15 AM, Paladox <thomasmulhall...@yahoo.com>
wrote:

> Why not start informing ie8 users now so that it gives them plenty of time
> to update. I would recommend them switching to chrome or firefox if on
> windows xp since ie9 is not available on windows xp.


Because everybody who could/cared upgraded ages ago. Also, because we're
NPOV and shouldn't bundle our neutral articles with our personal browser
preferences.


-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] i would like that i need not set standart spacing in my code

[Max Semenik]

On Wed, Oct 14, 2015 at 12:07 PM, Gergo Tisza <gti...@wikimedia.org> wrote:

> On Wed, Oct 14, 2015 at 10:42 AM, dinar qurbanov <qdi...@gmail.com> wrote:
>
> > it is possible to show prettified code in gerrit web pages, and send
> > prettified version to people if they get it via git fetch, but save
> > also their original form .


 Also, we want to ditch Gerrit, not add more cruft to it.


-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Deprecate $wgEnableAPI?

[Max Semenik]

Hey, I've created https://phabricator.wikimedia.org/T115414 to remove
$wgEnableAPI. Quoting the bug:

By now, MediaWiki is severely crippled without the API, with most of
interesting extensions relying on the API, it becomes more and more
problematic to disable it. Now it's probably fair to say that wikis that do
that are just shooting their own feet off for no good reason. Therefore, I
propose to officially declare that MW does not support working without the
API and remove this very setting.

Please state your opinions on this.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Announcing the launch of Maps

[Max Semenik]

The underlying data is ODbL which is properly attributed per OSM
guidelines. The license for tiles themselves is a different issue, OSM
decided to CC them, we're not claiming any additional copyright so far,
until legal tells us in https://phabricator.wikimedia.org/T111224

On Thu, Sep 17, 2015 at 12:40 PM, Ryan Kaldari <rkald...@wikimedia.org>
wrote:

> What is the license for the map tiles, i.e. the cartography rather than the
> data? Open Street Maps uses CC-BY-SA, although they don't really make it
> clear who is supposed to be attributed. It looks like our tiles are
> different though.
>
> On Thu, Sep 17, 2015 at 12:26 PM, Tomasz Finc <tf...@wikimedia.org> wrote:
>
> > The Discovery Department has launched an experimental tile and static
> maps
> > service available at https://maps.wikimedia.org.
> >
> > Using this service you can browse and embed map tiles into your own tools
> > using OpenStreetMap data. Currently, we handle traffic from *.wmflabs
> .org
> > and *.wikivoyage .org (referrer header must be either missing or set to
> > these values) but we would like to open it up to Wikipedia traffic if we
> > see enough use. Our hope is that this service fits the needs of the
> > numerous maps developers and tool authors who have asked for a WMF hosted
> > tile service with an initial focus on WikiVoyage.
> >
> > We'd love for you to try our new service, experiment writing tools using
> > our tiles, and giving us feedback <
> > https://www.mediawiki.org/wiki/Talk:Maps> .
> > If you've built a tool using OpenStreetMap-based imagery then using our
> > service is a simple drop-in replacement.
> >
> > Getting started is as easy as
> > https://www.mediawiki.org/wiki/Maps#Getting_Started
> >
> > How can you help?
> >
> > * Adapt your labs tool to use this service - for example, use Leaflet js
> > library and point it to https://maps.wikimedia.org
> > * File bugs in Phabricator
> > <https://phabricator.wikimedia.org/tag/discovery-maps-sprint/>
> > * Provide us feedback to help guide future features
> > <https://www.mediawiki.org/wiki/Talk:Maps>
> > * Improve our map style <https://github.com/kartotherian/osm-bright.tm2>
> > * Improve our data extraction
> > <https://github.com/kartotherian/osm-bright.tm2source>
> >
> > Based on usage and your feedback, the Discovery team
> > <https://www.mediawiki.org/wiki/Discovery> will decide how to proceed.
> >
> > We could add more data sources (both vector and raster), work on
> additional
> > services such as static maps or geosearch, work on supporting all
> > languages, switch to client-side WebGL rendering, etc. Please help us
> > decide what is most important.
> >
> > https://www.mediawiki.org/wiki/Maps has more about the project and
> related
> > Maps work.
> >
> > == In Depth ==
> >
> > Tiles are served from https://maps.wikimedia.org, but can only be
> accessed
> > from any subdomains of *.wmflabs .org and *.wikivoyage.org.
> Kartotherian
> > can produce tiles as images (png), and as raw vector data (PBF Mapbox
> > format or json):
> >
> > .../{source}/{zoom}/{x}/{y}[@{scale}x].{format}
> >
> > Additionally, Kartotherian can produce snapshot (static) images of any
> > location, scaling, and zoom level with
> >
> > .../{source},{zoom},{lat},{lon},{width}x{height}[@{scale}x].{format}.
> >
> > For example, to get an image centered at 42,-3.14, at zoom level 4, size
> > 800x600, use
> > https://maps.wikimedia.org/img/osm-intl,4,42,-3.14,800x600.png
> > (copy/paste the link, or else it might not work due to referrer
> > restriction).
> >
> > Do note that the static feature is highly experimental right now.
> >
> > We would like to thank WMF Ops (especially Alex Kosiaris, Brandon Black,
> > and Jaime Crespo), services team, OSM community and engineers, and the
> > Mapnik and Mapbox teams. The project would not have completed so fast
> > without you.
> >
> > Thank You
> >
> > --tomasz
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Idea: Cryptographically signed wiki pages.

[Max Semenik]

Obligatory XKCD: https://xkcd.com/538/

On Sun, Sep 13, 2015 at 9:20 AM, Purodha Blissenbach <
puro...@blissenbach.org> wrote:

> The idea is that third parties can publish texts, such as theis statutes,
> via a open or public wiki, and readers can be sure to read, download, sign,
> and mail the originals. Another use would be to have pledges and petitions
> signed by many people. Etc. It is not about WMF-run Wikis.
>
> Purodha
>
>
> On 13.09.2015 18:09, Greg Grossmeier wrote:
>
>> I guess this is to guard against the WMF changing content behind the
>> scenes? Through court order or otherwise?
>>
>> The pages are already cryptographically signed for transmission (tls), so
>> you know you get what WMF servers want you to get, at least.
>>
>> Greg
>>
>> --
>> Sent from my phone, please excuse brevity.
>> On Sep 13, 2015 6:45 AM, "John" <phoenixoverr...@gmail.com> wrote:
>>
>> why do they need signed in the first place?
>>>
>>> On Sun, Sep 13, 2015 at 5:39 AM, Purodha Blissenbach <
>>> puro...@blissenbach.org> wrote:
>>>
>>> > In a discussion in the German Pirate Party the idea came up that we
>>> might
>>> > want to have cryptographically signed wiki pages.
>>> > I could not find that this has been implemented already anyhow.
>>> >
>>> > Thus, can we develop an extsion which provides cryptographically signed
>>> > wiki pages?
>>> >
>>> > A brief and preliminaly scetch would mean that any user who provides a
>>> > matching public key could sign any existing page.
>>> > Before a page + signature is saved, the signature is checked for
>>> vadility.
>>> > Editing a siged page is possible without resigning it.
>>> > There must be a page display allowing to copy+paste the page with
>>> > signature for external verification.
>>> > Therre should be a button triggering the verifivation via an external
>>> > online service.
>>> > Maybe signature display of signed pages should be suppressable.
>>> > Any numer of independent signatures must be possible to a page.
>>> >
>>> > Does that make sense? Anything vital forgotten?
>>> >
>>> > Feedback welcome.
>>> >
>>> > Greetings -- Purodha
>>> >
>>> > ___
>>> > Wikitech-l mailing list
>>> > Wikitech-l@lists.wikimedia.org
>>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>> _______
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New RFC: better JS minification

[Max Semenik]

On Tue, Sep 1, 2015 at 8:49 AM, Ori Livneh <o...@wikimedia.org> wrote:

> So +1 for reviving it.
>

Feel free to, however I myself have neither the time nor inclination to
work on this; the components are:
* The extension itself:
https://github.com/wikimedia/mediawiki-extensions-Minifier
* Minifier service in extension's /server/ directory
* Core change https://gerrit.wikimedia.org/r/#/c/74293/

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikitech-ambassadors] [BREAKING CHANGE] Use of document.write no longer supported

[Max Semenik]

Already reported as https://phabricator.wikimedia.org/T108139

On Wed, Aug 5, 2015 at 5:10 PM, Bartosz Dziewoński matma@gmail.com
wrote:

 I think this announcement is missing one important tidbit:

 If you have `document.write(…)` anywhere in your user JavaScript, **you
 will get a blank page** on all pages of your wiki *, including the user
 JavaScript page you'd have to edit to fix it, until you disable JavaScript
 in your browser or ask an administrator to fix it for you.

 If you have `document.write(…)` anywhere in the site JavaScript, **all
 users** will **get a blank page** on all pages of the wiki *, including
 anonymous readers, including all administrators who could fix it, until one
 of them disables JavaScript in their browser, and finds and fixes the
 broken script.

 * Except for Special:Preferences and password-related pages, where user
 and site JavaScript is disabled for security reasons.



 On Thu, 06 Aug 2015 01:24:03 +0200, Krinkle krinklem...@gmail.com wrote:

 TL:DR; Double-check your wiki's site scripts and your personal scripts
 to ensure document.write is no longer used.

 Hey all,

 We have strongly discouraged for many years the use of synchronous
 document.write() to inject additional HTML into the output stream.
 Across MediaWiki core, extensions, and gadgets this hasn't worked since
 2012.
 With two legacy exceptions: the 'site' and 'user' modules. We always
 found a way
 to continue support for those. But this is now going to be removed.

 In upcoming ResourceLoader upgrades and performance improvements, we will
 cease support for synchronous document-write, in the site and user
 modules.
 Use of document-write requires MediaWiki to instruct the browser to pause
 its
 rendering before the browser may proceed to parse and display a page to
 users.

 Even though most scripts don't use this feature, the mere fact that we
 support it
 is causing a measurable impact on page load performance.

 Starting in 1.26wmf17 (released to wikis this week), ResourceLoader will
 be
 fully asynchronous. This change is already live on the Beta Cluster. [1]
 This means it is no longer possible for the site and user scripts to, with
 document-write, pause the browser execution and insert additional HTML in
 the initial output stream.

 Removing an API does not necessarily mean removing a capability. If you
 encounter any issues or can't find a simple upgrade path for an existing
 script, please reach out on the mailing list. Below is summary of a few
 typical use cases:

 1. Loading scripts.

 Instead of `document.write(script src=url/script);`
 use `mw.loader.load(url);` instead.

 2. Loading stylesheets.

 Instead of `document.write(link rel=stylesheet href=url/);`
 use `mw.loader.load(url, text/css);` instead.

 3. Creating elements.

 Instead of `document.write(div/div);`, use:

 var nodes = $.parseHTML(div../div); $('body').append(nodes);

 Or something like:

 $(div).attr({ id: foo }).appendTo(body);


 Please take some time to look through your wiki's site scripts
 (MediaWiki:Common.js,
 MediaWiki:Vector.js, etc.) and make sure document-write is no longer used.
 You can also use the search engine. For example:

 https://nl.wikipedia.org/w/index.php?search=document.writens8=1
 https://commons.wikimedia.org/w/index.php?search=document.writens8=1

 Search results from mwgrep on all public wikis:
 https://phabricator.wikimedia.org/P1832

 Check out the migration page for other deprecations and common issues you
 may encounter:
 https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users)

 == Further reading ==

 The ResourceLoader improvements that led to this change are tracked under
 https://phabricator.wikimedia.org/T107399.

 Refer to the following workboards for other tasks in this area:

 https://phabricator.wikimedia.org/tag/mediawiki-resourceloader/board/?order=priority

 https://phabricator.wikimedia.org/tag/performance-team/board/?order=priority

 Now that the site and user modules are primary citizens in the
 ResourceLoader landscape,
 their states can be tracked with mw.loader. This solves long-outstanding
 issues such as
 https://phabricator.wikimedia.org/T106736 which sometimes caused
 malfunctions
 in Common.js to affect user gadgets, VisualEditor, and other site tools.

 — Krinkle

 [1] http://en.wikipedia.beta.wmflabs.org/


 ___
 Wikitech-ambassadors mailing list
 wikitech-ambassad...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors



 --
 Bartosz Dziewoński


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Geolocation and WikiVoyage

[Max Semenik]

https://en.wikivoyage.org/w/api.php?action=querylist=geosearchgsradius=2gscoord=51.507222|-0.1275gslimit=100format=json

On Tue, Jul 21, 2015 at 10:40 AM, Sylvain Arnouts 
sylvain.arno...@wanadoo.fr wrote:

 Hi guys !

 I'm working on a website, which find your position using geolocation, and
 then show the wikipedia's pages around you on an OSM map. For the moment it
 works.
 The goal here is to create a full solution dedicated to tourism. For
 example a tourist is dropped in a city he doesn't know, and he can have
 informations on what's around thanks to Wikipedia and wikidata. But I'd
 like to add WikiVoyage informations too.

 I know it's possible with Wikidata API to enter a position (longitude and
 latitude), a range, and have all Wikipedia pages around. Is it possible to
 do the same with WikiVoyage pages ?

 Thanks a lot ! :)

 Sylvain.
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Main themes for Wikimania's hackathon?

[Max Semenik]

I think that Wikimania is too global and there will be far too many devs
with too numerous areas of knowledge to concentrate on a single topic.

On Tue, Jun 23, 2015 at 1:25 PM, Quim Gil q...@wikimedia.org wrote:

 Hi, we have tried the idea of having main themes at the MediaWiki Developer
 Summit and Ther Wikimedia Hackathon. Wikimania's hackathon is approaching
 fast, and we need to decide

 * whether main themes will be useful for this event
 * if so, which main themes we want to promote.

 Your feedback is welcome at https://phabricator.wikimedia.org/T94031

 PS: sneak preview
 https://wikimania2015.wikimedia.org/wiki/Hackathon#Schedule

 --
 Quim Gil
 Engineering Community Manager @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/User:Qgil
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [WikimediaMobile] [reading-wmf] Fwd: Mobile Firendly

[Max Semenik]

Already fixed by Brandon and Ori: https://gerrit.wikimedia.org/r/#/c/214705/

On Fri, May 29, 2015 at 1:55 PM, Jon Katz jk...@wikimedia.org wrote:

 +external mobile and wikitech

 Shoot.  I meant to send this the external list.  For those of you just
 joining us, we recently got an email from google letting us know that some
 of our pages are now failing the mobile-friendly test, which has an adverse
 impact on our search results.  It appears that most of our pages are also
 blocking style info.

 Google doesn't offer much insight into penalties, but if they're sending
 us the email then it is or will have some impact.  I'd like to see if we
 can better understand the other side of the equation- what is cost of
 fixing it?  I think Jon's questions below are the ones to start with.

 -J


 On Fri, May 29, 2015 at 1:35 PM, Jon Robson jrob...@wikimedia.org wrote:

 It's all in the report. We block w/ in robots.txt always have.

 There have been a bunch of changes to improve performance of the site
 overall which might have led to that. Mailing this to the public mailing
 list wikitech would give you a better idea.

 Our site /is/ mobile friendly it's just we tell google not to load styles
 from w/load.php so no need to panic.

 The question is what is the penalty of us failing this tool? Does it
 impact our google search rankings?

 Fix is trivial.. Update robots.txt but first the question is why are we
 blocking scripts and styles on that url?
 On 29 May 2015 1:17 pm, Jon Katz jk...@wikimedia.org wrote:

 Hi Readership team and broader community,
 Any changes we might have recently made to cause this warning to appear
 about googlebot not being able to access our site?
 I consider this to be a very serious issue.
 The examples below are not mobile, but same issue applies when you try
 an en.m. version of the pages.

 Best,
 Jon


 -- Forwarded message --
 From: Wes Moran wmo...@wikimedia.org
 Date: Fri, May 29, 2015 at 12:47 PM
 Subject: Mobile Firendly
 To: Jon Katz jk...@wikimedia.org
 Cc: Adam Baso ab...@wikimedia.org


 Jon,

 Google notified us of the followin...

 We recently noticed that there was a change with how you embed CSS  JS
 which results in us not being able to use the CSS  JS to recognize what
 the page looks like. That's making some of your pages fail the
 mobile-friendly-test, for example. You used to load CSS  JS from
 bits.wikimedia.org, but now they're loaded through /w/load.php?...
 directly from the Wikipedia host, where that path is blocked by robots.txt.

 You can see how we render the pages with Fetch as Google in Webmaster
 Tools / Search Console, you can also see most of that with the test-page at:

 https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FBusot

 Some of the pages still pass the test there (example
 https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FZ%25C3%25BCrich),
 but the CSS is broken there too since it's blocked. 

 Any ideas what can be causing this?

 Regards,
 Wes


 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf


 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf



 ___
 Mobile-l mailing list
 mobil...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia group on GitHub

[Max Semenik]

You can register additional email addresses at
https://github.com/settings/emails - after that, your commits will be
recognised (at least new ones, not sure about those already in).

On Wed, May 27, 2015 at 10:30 AM, Jeroen De Dauw jeroended...@gmail.com
wrote:

 Hey,

 I've noticed that it adds some of my commits to Wikimedia repos to my
  calendar and sometime it doesn't.
 

 If you commit using different git email/name/whatever, then GitHub will not
 recognize that as you unless you first do the needed config steps. This is
 true for all such git using services that I am aware of.

 Cheers

 --
 Jeroen De Dauw - http://www.bn2vs.com
 Software craftsmanship advocate
 Developer at Wikimedia Germany
 ~=[,,_,,]:3
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] I forked GeSHi

[Max Semenik]

So, after looking at the backlog of GeSHi's pull requests, I decided that
my itch was irritating enough to warrant a click on that nasty little fork
button. Let me introduce you to Chechil Highlighter
https://github.com/MaxSem/chechil. So far, I've:

   - Grabbed all pending GeSHi pull requests and reviewed them, merging
   into Chechil whenever it made sense.
   - Thrown out support for pre-antiquated PHP versions
   - Ditched a couple of small features deprecated by GeSHi developers
   themselves
   - Started adding unit tests

My immediate plans are to cover stuff with at least basic unit tests before
a major rewrite, which would include:

   - Kill the system where every language definition specifies its own
   styles in favor of a unified CSS file. That would make things more
   consistent and allow us to significantly reduce the size of our startup
   module that wouldn't need to contain all those per-language modules. And
   would allow restyling the highlighted text easily and consistently.
   - Converting PHP language definitions to JSON for improved security.
   Especially important since GeSHi allows you to use custom definitions.
   - Generally improving the code base, bringing it up to modern standards.

So far, this is just a personal pet project, I'm not proposing that we use
it for highlighting on WMF or anything, but I feel like that would be a
step forward if the rewrite succeeds. Please don't hesitate to throw your
boos or suggestions at me!

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Conpherence enabled? (was [Wikitech-ambassadors] Tech newsletter (2015, week 19))

[Max Semenik]

For the sake of open collaboration, please let's not encourage ways of
communication that are non-standard for open source projects. PM on IRC
should be more than enough for online 1:1 communications, while email is
good enough for offline. GSoC is all about introducing more people to open
collaboration, and Conpherence doesn't sound as if it's helping to
accomplish this goal in any way.

On Tue, May 5, 2015 at 10:23 PM, Jamison Lofthouse 
jamison.loftho...@gmail.com wrote:

 Please no Phriction for obvious reasons ;). As for Conpherence it was more
 for the one-on-one conversations that are needed for GSoC and other mentor
 to student collaborations.
 Negative24

 On Tue, May 5, 2015 at 12:58 PM Legoktm legoktm.wikipe...@gmail.com
 wrote:

  On 05/04/2015 08:07 AM, Guillaume Paumier wrote:
 * You can now chat with other users
   https://www.mediawiki.org/wiki/Conpherence in Phabricator. [1]
   https://phabricator.wikimedia.org/T91392
 
  Uh, why? Where was this actually discussed with more than 4 people? We
  already have IRC and mailing lists, so why do we need yet another
  communication system? Are we going to be enabling Phriction next?
 
  Please turn it off.
 
  -- Legoktm
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Thumbnail image hinting in articles via metadata tags

[Max Semenik]

On Thu, Apr 2, 2015 at 11:35 AM, James Pearson ja...@reddit.com wrote:

 While writing this, I recalled that the Wikipedia Android app displays
 thumbnails in its search results.  I think that's pulling from OpenSearch
 with the PageImages extension[2]? but I haven't really delved into that
 yet.  I'm curious how those images get pulled - if it's taking into account
 infoboxes or such, or just the first image on the page, or what.


It uses a scoring system that takes position on page, size and w:h ratio
into account.


 Would it be feasible to include an og:image tag on pages for which we have
 a reasonable guess as to the thumbnail?  Open Graph[3] is supported by what
 seems anecdotally to me to be a wide range of services, so good hints there
 would improve thumbnails for links on not just reddit, but Facebook,
 Twitter, various chat clients, I think several Wordpress plugins, etc.


https://phabricator.wikimedia.org/T8



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Maps

[Max Semenik]

Hi, just a quick note: as part of general search and discovery work, me and
Yuri are resurrecting the project to have OpenStreetMap in Wikimedia
starting in April. Because the initial part of this work will include
researching options which will influence precise goals and this is yet to
be done, we still can't commit to a precise timeline, but as a ballpark
estimate I personally want to aim for serving PNG tiles at a reasonable,
though not necessarily dynamic maps on every WP page scale by the end of
Q4. Vector/multilingual maps would be the next stage. We will be mostly
using Phabricator for planning,
https://phabricator.wikimedia.org/tag/openstreetmap/ is my first pass on
the outline of things to be done.

Your comments and suggestions would be highly appreciated, please share
your thoughts, ideas of projects that might use these maps, or just
merciless critique! :D

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Maps

[Max Semenik]

On Wed, Mar 18, 2015 at 4:01 PM, MZMcBride z...@mzmcbride.com wrote:

 I believe OpenStreetMap previously had a relationship with Wikimedia
 Germany and the Toolserver(?). I'm not sure if that endeavor is related to
 this one. And I'm not sure what the scopes of these projects are.


Toolserver's gone, right?


 It looks like this new project would be the Wikimedia Foundation acting as
 both the (tile)server and the client, using data from OpenStreetMap. Is
 that correct?


Yes.


 If so, will the tileserver be considered a public service
 for use outside of Wikimedia wikis?


TBD.


 And will this service be hosted on
 Wikimedia Labs?


No, on real hardware.


 Expanding the mediawiki.org and Meta-Wiki pages to include more
 information about the history here would be great.


Hey, we're still working on fulfilling our previous commitments. Everything
will come, just not instantaneously;)

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Max Semenik]

On Tue, Mar 17, 2015 at 3:05 AM, Ricordisamoa ricordisa...@openmailbox.org
wrote:

  * An arbitrary indentation level *must* be allowed, with optional
facilitations for adding an {{outdent}}-like marker


Why? Manual indentation just leads to you having to decode these levels
sometimes. Soulless machines are better at indenting consistently than us
meatbags. Also, my personal opinion is that indenting is just silly and
needs to die, not accumulate more cruft.


  * Every basic functionality (including but not limited to the
preview button) *must* work without relying on JavaScript (T60019
https://phabricator.wikimedia.org/T60019)


Surprise! It's 2015, and web doesn't quite work without JS. Some basics
still need to work without it, but very basics.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Max Semenik]

On Mon, Mar 16, 2015 at 2:30 PM, Gergo Tisza gti...@wikimedia.org wrote:

 Well, the obvious collateral is always money; and with bitcoin going
 mainstream, untraceable money transfers are now accessible even to
 nontechnical users (although I don't know Not sure if the mere act of
 buying bitcoins could endanger someone in certain oppressive regimes).
 Something like $10 is probably not a serious hurdle to anyone intent on
 avoiding censorship but enough to deter spammers. The money could be
 donated to the Tor project, or retained and returned after a certain number
 of edits.


In some jurisdictions Bitcoin is outright prohibited, with penalties for
end users for mere ownership of any amounts. Would be very funny to require
people to expose their asses to more problems in order to edit Wikipedia.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Progress report: Hierator

[Max Semenik]

Hi, this is a status update for my WikiHiero rewrite! [1]

I've made a first pass on comparison, based on all hieroglyphic texts on
English Wikipedia: [2]
You can see the difference yourselves, in my opinion the general quality is
considerably better, and far more hieroglyphs are supported. However, a few
problems were identified, mostly related to WikiHiero accidentally allowing
invalid syntax in the past. I'm working on either fixing them in tokenizer,
e.g. converting ra:: to something like ra:.:. or making a fallback to
the old HTML renderer and adding a tracking category for future fixage by
editors. Some of the known problems are listed at [3]. Unfortunately, this
also includes some cases where WikiHiero's hieroglyphs deviated from what
was said in standards, resulting in a mess that needs manual conversion
during a transitional period. These will also fall back on the old renderer
and be tracked.

The code is still being worked on, it can be seen in [4] (Hierator) and [5]
(WikiHiero).

-
[1] https://www.mediawiki.org/wiki/Requests_for_comment/Hierator
[2] http://staging.wmflabs.org/w/extensions/wikihiero/comparison/
[3] https://www.mediawiki.org/wiki/Extension:WikiHiero/JSesh_migration
[4] https://gerrit.wikimedia.org/r/178970
[5] https://gerrit.wikimedia.org/r/178269


-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Boil the ocean, be silly, throw the baby out with bathwater, demolish silos, have fun

[Max Semenik]

Yup!

On Sun, Feb 15, 2015 at 3:08 PM, Tim Starling tstarl...@wikimedia.org
wrote:

 On 14/02/15 09:39, Max Semenik wrote:
  On Fri, Feb 13, 2015 at 2:23 PM, Legoktm legoktm.wikipe...@gmail.com
  wrote:
 
 
  https://phabricator.wikimedia.org/T71366
 
 
  Note that my proposal is explicitly different from Jon's plans about that
  bug: he wants to continue overriding special pages, etc. while I want to
  leave everything like this outside of the skin, including its custom
  JS-based wikitext editor.

 So how would this work exactly? Would Minvera's navigation drawer be
 refactored so that it uses Skin::buildSidebar(),
 SkinTemplate::buildContentNavigationUrls(), etc.? And how would MF
 reapply its special page replacement? Hooks into those same common
 functions? Would it be possible to get the mobile special pages on a
 non-minerva skin?

 I suppose the OutputPage::setTarget() call would also be left in MF.

 -- Tim Starling


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Boil the ocean, be silly, throw the baby out with bathwater, demolish silos, have fun

[Max Semenik]

On Fri, Feb 13, 2015 at 2:23 PM, Legoktm legoktm.wikipe...@gmail.com
wrote:


 https://phabricator.wikimedia.org/T71366


Note that my proposal is explicitly different from Jon's plans about that
bug: he wants to continue overriding special pages, etc. while I want to
leave everything like this outside of the skin, including its custom
JS-based wikitext editor.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Boil the ocean, be silly, throw the baby out with bathwater, demolish silos, have fun

[Max Semenik]

On Fri, Feb 13, 2015 at 2:23 PM, Risker risker...@gmail.com wrote:

 Help me out here. Why does anyone care that the article was last edited 13
 days ago by Omeganian?  And even if they do, why is that the very first
 thing that someone sees?


See the part about improvements.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Boil the ocean, be silly, throw the baby out with bathwater, demolish silos, have fun

[Max Semenik]

Sorry for all the trolling, but why instead of discussing how we need a
responsive skin for MediaWiki and waiting for Winter to come don't we just
do it:
* Move Minerva out of MobileFrontend
* Leave all mobile-specific improvements, improvements and hacks in MF
* Polish Minerva to do everythig a normal desktop skin does
* Bundle it with MW by default


[0] https://en.wikipedia.org/wiki/James_Randi?useskin=minerva

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GPL upgrading to version 3

[Max Semenik]

On Mon, Feb 9, 2015 at 12:01 AM, David Gerard dger...@gmail.com wrote:

 On 9 February 2015 at 04:51, Rob Lanphier ro...@wikimedia.org wrote:

  Also, one cost of copyleft licenses is that they are much, much more
  complicated than permissive licenses.  Even though many people feel
  comfortable with the compliance requirements of most OSI-approved
  licenses, the permissive licenses can usually stand alone without an
  FAQ, whereas an FAQ is required for just about all of the copyleft
  licenses.  That simplicity reduces a very real barrier to adoption.

 Is this statement from anecdote or data? Otherwise you need to explain
 how LibreOffice (copyleft) has fifteen or so companies contributing,
 whereas Apache OpenOffice (permissive) has one and even they've given
 up actually paying people to work on it. The idea that permissive
 works better for getting contributions seems to me completely
 unevidenced.


OpenOffice's woes are unrelated to its license, it was already dead by
forking when Oracle transferred it to Apache, facilitating a change from
GPL+proprietary CLA to the Apache license.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GPL upgrading to version 3

[Max Semenik]

On Mon, Feb 9, 2015 at 12:22 PM, Tyler Romeo tylerro...@gmail.com wrote:

 I hope you don’t seriously think GPL software is not “truly free”.


 Well, it all depends on point of view on what is free. The FSF
interpretation is you can do it your own way if it's done just how I say.
Not everyone agrees that more restrictions is more freedom. Note: I don't
disagree with Stallmanian coplyleft principles in all cases, I just
consider the word free highly misleading here.


-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GPL upgrading to version 3

[Max Semenik]

On Sat, Feb 7, 2015 at 2:20 PM, Tyler Romeo tylerro...@gmail.com wrote:

 **However**, I’d like to take this opportunity and jump a step further.
 What would everybody think of switching to the AGPLv3 instead? The
 advantage that this provides, for those who don’t know, is a single
 additional restriction: when the software is used over the network, source
 code must still be provided. In other words, the requirements all remain
 the same (providing a copy of the source code, ensuring all modifications
 are also GPLed, etc.). The only difference is that the requirements take
 effect over the Internet rather than only when the software is distributed
 in object code form.


Honestly, I'm no big fan of strongly copyleft licenses, especially AGPL. In
addition to scaring off corporate users (yes, even soulless for-profit
drones deserve the right to use FLOSS), it creates a lot of uncertainty
even for open source users. I would personally prefer something much
permissive like MIT style.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GPL upgrading to version 3

[Max Semenik]

On Sun, Feb 8, 2015 at 2:13 AM, Tyler Romeo tylerro...@gmail.com wrote:

 (Also, we actually can’t switch to the MIT license without express
 permissions from every developer who ever contributed to core anyway.)

Same applies to AGPL.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] C2.com switches to single-page app distributed nodejs backend

[Max Semenik]

Actually, it has a nice HTML-only fallback, and Googlebot executes JS these
days.

On Mon, Feb 2, 2015 at 8:53 AM, James Douglas jdoug...@wikimedia.org
wrote:

 This is an interesting change.  I wonder how they keep the site accessible
 by search engine indexers, and folks with older/limited/text-only browsers
 or limited connectivity.

 On Mon, Feb 2, 2015 at 8:20 AM, Gabriel Wicke gwi...@wikimedia.org
 wrote:

  The original wiki is getting a technical facelift:
 
 - http://c2.com/cgi/wiki?WikiWikiSystemNotice
 - http://c2.fed.wiki.org/view/welcome-visitors
 - https://news.ycombinator.com/item?id=8983158
 
  Gabriel
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of shared hosting

[Max Semenik]

On Thu, Jan 15, 2015 at 10:38 PM, Bryan Davis bd...@wikimedia.org wrote:


 One of the bigger questions I have about the potential shift to
 requiring services is the fate of shared hosting deployments of
 MediaWiki. What will happen to the numerous MediaWiki installs on
 shared hosting providers like 1and1, Dreamhost or GoDaddy when running
 MediaWiki requires multiple node.js/java/hack/python stand alone
 processes to function? Is the MediaWiki community making a conscious
 decision to abandon these customers? If so should we start looking for
 a suitable replacement that can be recommended and possibly develop
 tools to easy the migration away from MediaWiki to another monolithic
 wiki application? If not, how are we going to ensure that pure PHP
 alternate implementations get equal testing and feature development if
 they are not actively used on the Foundation's project wikis?


This is not even about shared hostings: it is pretty obvious that running a
bunch of heterogenous services is harder than just one PHP app, especially
if you don't have dedicated ops like we at WMF do. Therefore, the question
is: what will we gain and what will we lose by making MediaWiki unusable by
95% of its current user base?


-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The future of shared hosting

[Max Semenik]

On Thu, Jan 15, 2015 at 11:27 PM, Trevor Parscal tpars...@wikimedia.org
wrote:

 95% is pretty extreme.


Can't agree on this, as the number covers:

   - All curent shared host users
   - Those who use an entry-level VPS and would suddenly discover that with
   a few extra node services their RAM is insufficient
   - People who aren't technical enough to run a bunch of services glued
   together with PHP
  - Especially if these services are even a tiny bit more complex to
  install than `apt-get install`
   - People who run MW in strict corporate environments where installing
   just another piece of software is a big deal

I initially considered writing 99%, but decided that some users might
consider upgrading their plans, etc. Still, 99% is proably the accurate
estimate of current installations potentially affected by servicization.


 I have always questioned the balance being struck here, and would welcome
 an adjustment of the minimum requirements to run MediaWiki. In many cases,
 if we can just require shell access we can automate away the complexity for
 the typical use cases.


 Yep, maintaining the ability to run MW in crappy environments has always
been a losing battle, and especially since we're planning to ditch PHP 5.3
support soon (which would render MW incompatible with a lot of crappy
hosts) it might be the time to officially declare that we don't care about
supporting environments without shell access. Still, shell access does not
equate to root access or even to running Parsoid from userspace, that's a
different story.

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Stance on Social Media

[Max Semenik]

On Fri, Jan 9, 2015 at 3:15 PM, Kevin Wayne Williams 
kwwilli...@kwwilliams.com wrote:

 Not sure where to reply to a top-post to a bottom posted thread, so I will
 shoot for the middle and hope people can keep track of this knot. Your
 counterexample (which can be manually done today, so I've got experience
 with it) invariably winds up with a fan-flood of inexperienced editors and
 we wind up semi-protecting the article to keep them from damaging it.


Since when an inflow of new editors is a bad thing? Of course, not all
newbies will become productive editors, but if we start outright potential
new people, we will end up with Wikipedia ran by three grumpy cats. See
Citizendium for an example of a wiki that failed because it couldn't
maintain a stream of new contributors as old ones were leaving.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Stance on Social Media

[Max Semenik]

As always, if there is a way to do something, there will be a way to abuse
it. Remember when we enabled IPv6 support some people started moaning that
new style IPs are vandalising even though the rate of vandalism wasn't
different between IPv4 and IPv6 anons? This is the same situation: to your
example one can always provide a counterexample, OMG the article about our
favorite singer is so crappy, let's all help make it awesome! Is that bad?
Even someone as hating social networks as me has to agree that by now,
there's no rational reason not to add social sharing buttons.

On Fri, Jan 9, 2015 at 2:25 PM, Kevin Wayne Williams 
kwwilli...@kwwilliams.com wrote:

 Brian Wolff schreef op 2015/01/09 om 15:17:

  I think its important to separate  two types of social media interaction:
 *allowing people to post their favourite article (share this links)
 *meta level interaction (stuff about the community)

 Nobody objects to the second afaik. The first is like proposing nsfw
 filters on commmons (ie get ready for the pitchforks).


 You missed the worst part: Some evil administrator won't let me post that
 Mariah Carey/Iggy Azalea/pop singer of the week sold 50 bajillion copies of
 her latest album! Fans Unite, and make sure that Wikipedia has the TRUTH!
 accompanied by an edit this article link to the singer's article. The
 last thing we need to do is make that kind of crap easier.

 KWW



 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Max Semenik]

I'm pretty sure most users technical enough to use IRC are able to solve
captchas well.

On Sun, Nov 9, 2014 at 3:45 PM, Platonides platoni...@gmail.com wrote:

 On 09/11/14 06:21, Pine W wrote:

 Discussing an option with the community to test replacing registration
 CAPTCHAs with an email requirement makes sense to me. I would support a
 small, carefully designed test. If someone is motivated to create a
 Wikimedia account and they don't want to register an email, they can be
 given the option to have someone help them to set up an account via IRC,
 Facebook, or other communications methods.


 It would be nice to have a link that leads the user to a
 #wikipedia-accountcreation channel for getting help creating an account.
 There are few ways to get thelp for an inexperienced user if they fail at
 the create account form. It is orthogonal however on whether we use a
 captcha or not.


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] WikiGrok deployed

[Max Semenik]

Hi, WikiGrok[0] has been successfully deployed to the English Wikipedia.
Along with it a first campaign[1] was deployed. Now database is being
slowly populated with suggestions:

MariaDB [enwiki_p] select page_title, pp_value from page, page_props where
pp_page=page_id and pp_propname='wikigrok_questions_v1' limit 100;
+-+--+
| page_title  | pp_value
  |
+-+--+
| Richard_Branson |
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| Tina_Fey|
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| Jon_Stewart |
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| Bill_Maher  |
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| Jeff_Foxworthy  |
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| Evadne_Price|
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| Dominic_Guard   |
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| Dilsa_Demirbag_Sten |
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| J._Douglas_MacMillan|
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| Carol_Bowman|
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| Lianella_Carell |
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| G._K._Reddy |
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| Liù_Bosisio |
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
| Matilde_Rodríguez_Cabo  |
a:1:{s:6:author;a:2:{s:8:property;s:4:P106;s:9:questions;a:1:{s:7:Q482980;s:6:author;}}}
|
+-+--+
14 rows in set (0.42 sec)

Pages are getting updated when edited (null edit works, but not
action=purge). According to estimations made with WikiData Query[2], the
number of potentially affected pages is approximately 33,000. If really
needed, we could whip up a script to null-edit these pages from server side
in a controlled manner, but I would like to have more data on performance
and memory consumption first.

== Monitoring ==
* Graphite: MediaWiki - WikiGrok
* Exceptions from WikiData: type:mobile in Logstash.

== Firefighting ==
Most of potentially performance-scary/error causing code with can be
disabled by commenting out $wgWikiGrokSlowCampaigns in
wmf-config/mobile.php. If shit hits fan really hard, whole extension can be
disabled through the usual means, with $wmgUseWikiGrok.

== Next steps ==
I'm working on DB storage for questions[3] which will allow us to avoid
abusing page_props and give features such as find me pages that could use
this type of fixes and find me a random page to fix.



[0] https://www.mediawiki.org/wiki/Extension:WikiGrok
[1] https://gerrit.wikimedia.org/r/#/c/170453/
[2] http://wdq.wmflabs.org/
[3] https://gerrit.wikimedia.org/r/170263

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fixing PollNY -- ResourceLoader woes

[Max Semenik]

How exactly did you try it: mw.loader.using( 'resource.name', function() {
... } ) ?

On Tue, Sep 16, 2014 at 3:00 PM, Jack Phoenix j...@countervandalism.net
wrote:

 Hi all,

 A few days ago I was fiddling around with my Labs instance [1], which
 serves as a development/testing/showcase area for social tools [2]. Somehow
 I ended up on Special:ViewPoll [3] and got curious as to why a JavaScript
 hover effect (mouseover/mouseout) didn't work on that page -- I was sure it
 used to work just fine not that long time ago. Without thinking that much
 about it, I clicked on the one and only poll listed on the page [4], and
 turns out the whole Poll: page is about as broken as it can be due to a
 JavaScript error.

 After a while of debugging, consultation and more debugging, turned out
 that my local development setup had $wgResourceLoaderDebug = true; in its
 LocalSettings.php, which apparently hides some race conditions or something
 like that. The Labs instance tries to be a more faithful representation of
 a production wiki, and as such, it doesn't have this setting enabled and
 hence why the problem manifests there.

 PollNY itself is a rather old extension, as most original social tools are
 (see the MW.org page [2] for details), and as such, it likely has some
 non-optimal code and it's also gone through plenty of iterations in the
 past. As a matter of fact, when porting PollNY to use ResourceLoader, it
 seems I myself made some suboptimal choices, such as bundling both CSS and
 JS into the same module and loading this module with 'position' = 'top'.

 Anyway, after decoupling the main CSS into its own module (locally, haven't
 submitted this to git yet), tweaking the callers and whatnot, I was able to
 get the hover effects on Special:ViewPoll to work as intended. While this
 is definitely a step forward, the actual problem with pages in the Poll:
 namespace still persists.

 PollNY has two JS files, LightBox.js and Poll.js. LightBox.js contains a
 lightbox implementation and technically it's not needed for stuff like the
 pollembed tag etc. and it should only be loaded on Poll: pages. Poll.js,
 on the other hand, is basically needed everywhere where there is PollNY;
 special pages, pages that embed a poll via the pollembed tag, Poll:
 pages...

 Now, the actual issue is that no matter what I do, I get a TypeError:
 'LightBox' is not defined on Poll: pages (such as [4]). In the git master
 version, this is due to the aforementioned race condition: line 466 of
 Poll.js tries to use mw.loader.load() to load the LightBox RL module if
 it's not already loaded, but in RL's production mode this fails, because,
 as I've been told by those with more intimate knowledge of ResourceLoader
 and its inner workings, mw.loader.load is asynchronous. I've tried
 mw.loader.using, but it doesn't seem to do anything as far as fixing the
 issue goes.

 Please let me know if you're able to help me out with this; I've ran out of
 ideas.

 [1] http://social-tools.wmflabs.org/
 [2] https://www.mediawiki.org/wiki/Social_tools
 [3] http://social-tools.wmflabs.org/wiki/Special:ViewPoll
 [4] http://social-tools.wmflabs.org/wiki/Poll:How_is_the_weather_today%3F


 Thanks and regards,
 --
 Jack Phoenix
 MediaWiki developer
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Thoughts about roles

[Max Semenik]

Done in https://gerrit.wikimedia.org/r/155861 - your critique would be
appreciated:)


On Sat, Aug 9, 2014 at 6:40 PM, Max Semenik maxsem.w...@gmail.com wrote:

 Currently a lot of our extension Vagrant roles are working like Swiss
 knives: they do everything possible to imagine. For example, MobileFrontend
 always installs 3 optional dependencies while CirrusSearch includes its
 configuration for unit tests that among other things
 enforces $wgCapitalLinks = false which is untypical for most MW installs.

 I think many of these actually make development harder. Solution? Can we
 split some larger roles to basic and advanced parts, so that people who
 need an extension to play around or to satisfy a dependency will not be
 forced to emulate a significant part of WMF infrastructure?

 --
 Best regards,
 Max Semenik ([[User:MaxSem]])




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Thoughts about roles

[Max Semenik]

Currently a lot of our extension Vagrant roles are working like Swiss
knives: they do everything possible to imagine. For example, MobileFrontend
always installs 3 optional dependencies while CirrusSearch includes its
configuration for unit tests that among other things
enforces $wgCapitalLinks = false which is untypical for most MW installs.

I think many of these actually make development harder. Solution? Can we
split some larger roles to basic and advanced parts, so that people who
need an extension to play around or to satisfy a dependency will not be
forced to emulate a significant part of WMF infrastructure?

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] jQuery UI 1.10.4 and IE6 support

[Max Semenik]

Why? Everyone who was able to upgrade already did that. The remainder are
either users with really crappy machines or corporate slaves who can't
decide anything themselves. What will you achieve by annoying them?


On Fri, Jul 25, 2014 at 2:36 PM, Thomas Mulhall thomasmulhall...@yahoo.com
wrote:

 I also think that a notice should be put ontop of mediawiki to say that
 internet explorer 6 is no longer supported and ask them to upgrade to
 internet explorer 8.


 On Friday, 25 July 2014, 0:14, Thomas Mulhall thomasmulhall...@yahoo.com
 wrote:



 We had a discussion about internet explorer 6 and someone said that we
 should start to remove some code but keep codes that let internet explorer
 6 users edit and view the page.


 On Thursday, 24 July 2014, 22:03, Thomas Mulhall 
 thomasmulhall...@yahoo.com wrote:



 Thanks.


 On Thursday, 24 July 2014, 21:49, Sumana Harihareswara 
 suma...@wikimedia.org wrote:



 Replying with a subject line. :) Good luck Thomas.



 Sumana Harihareswara
 Senior Technical Writer
 Wikimedia Foundation


 On Thu, Jul 24, 2014 at 4:24 PM, Thomas Mulhall 
 thomasmulhall...@yahoo.com wrote:

 Hi should we upgrade jquery ui to version 1.10.4. even though we recently
 upgraded to version 1.9.2 we could upgrade to 1.10.4 in Mediawiki 1.25. The
 main difference is it removes internet explorer 6 support which as long as
 internet explorer 6 users can edit and view the page it wont matter to
 them. here is the changelog jqueryui.com/changelog/1.10.0/
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Linux distros or Solaris for MediaWiki

[Max Semenik]

The main issue with packages is not even the version. It is kinda expected
that distros don't have bleeding-edge packages, and 1.19 will be supported
for almost a year from now. However all packages I know of (Debian flavors
and not) split MW directory and put its parts into different places, trying
to follow the Filesystem Hierarchy Standard. The result is not only
confsuion (one guy on IRC asked which of three LocalSettings.php files
present on his server he should edit; two of them turned out to be symlinks
but still helluva confusing) but also outright breakages because our code
base generally assumes that everything lies in one place.


On Mon, Jul 21, 2014 at 12:23 AM, Dmitriy Sintsov questpc...@gmail.com
wrote:

 Yes, please do not install MediaWiki via apt-get or aptitude. It will be
 old version with suboptimal settings. It is much better to install it
 manually.
 Speaking of Ubuntu, I think WMF is running a lot of Ubuntu / Debian
 systems. So, Ubuntu should be the best way of running MediaWiki.
 Dmitriy



 On Mon, Jul 21, 2014 at 10:55 AM, Pine W wiki.p...@gmail.com wrote:

  David: https://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Ubuntu
 
  That warning could be clearer about what it's referring to.
 
 
  On Sun, Jul 20, 2014 at 2:24 PM, David Gerard dger...@gmail.com wrote:
 
   Where does it say it's unsupported? Some older page, talking about the
   distro version? I routinely use MW from tarball on Ubuntu and it's
   fine. https://www.mediawiki.org/wiki/Debian/Ubuntu
  
   I'd personally recommend you install the prerequisites then use the
   MediaWiki tarball, but the distro 1.19 in recent versions of Ubuntu
  should
   be
   good (if a bit old).
  
   I have done MW on Solaris and it was an exercise in pain, unless you
   use something that resolves dependencies for you. That is to say, a
   Linux.
  
  
   - d.
  
  
  
   On 20 July 2014 20:55, Pine W wiki.p...@gmail.com wrote:
I have experience with Ubuntu but MediaWiki says that Ubuntu is
unsupported. Which Linux distro would people recommend, and which
  distro
   of
Linux does WMF use for MediaWiki? I am thinking about installing
 Debian
   but
am open to any suggestions that have a friendly UX.
   
Solaris is an option also.
   
Pine
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Linux distros or Solaris for MediaWiki

[Max Semenik]

Yep. It says that the broken .deb package made by Debian guys is not
supported by us developeers, not that MW doesn't support Ubuntu or vice
versa. Just stick with tarballs or Git checkouts and you'll be fine.


On Sun, Jul 20, 2014 at 1:10 PM, Pine W wiki.p...@gmail.com wrote:

 From https://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Ubuntu

 *Warning:* MediaWiki can also be installed using aptitude. The Ubuntu
 MediaWiki package is unsupported and usually outdated. We do not recommend
 you use it.

 I suppose that could refer only to aptitude and not Ubuntu support as a
 whole.

 Pine


 On Sun, Jul 20, 2014 at 1:04 PM, Michał Łazowik mlazo...@me.com wrote:

  Hey,
 
  Wiadomość napisana przez Pine W wiki.p...@gmail.com w dniu 20 lip
 2014,
  o godz. 21:55:
 
   I have experience with Ubuntu but MediaWiki says that Ubuntu is
   unsupported.
 
  Where, when, why what? I mean, from where do you have that info?
 
   Which Linux distro would people recommend, and which distro of
   Linux does WMF use for MediaWiki?
 
  It's quite amusing in the view of what you said:
  it's… Ubuntu :p [0]
 
  And basically anything that can run some web server (e.g. apache, nginx)
  with php support should work. I think it would be hard to find a distro
  that
  wouldn't work.
 
  Regards,
  Michał
 
  [0] http://meta.wikimedia.org/wiki/Wikimedia_servers#Software
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Anyone going to WikiMania?

[Max Semenik]

A lot of us coming, both WMF and volunteer developers. Bring your laptop
and your brain, of course - we'll have fun!


On Sat, Jul 19, 2014 at 2:47 AM, Mark Clements (HappyDog) 
gm...@kennel17.co.uk wrote:

 Hi there,

 As it's on my doorstep, I've got myself tickets to WikiMania 2014,
 including the hackathon.

 I've never been to a hackathon before!  What should I expect?  Are any of
 you guys coming?

 - Mark Clements
 HappyDog



 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practices for loading large, pre-minified JavaScript modules?

[Max Semenik]

You can bypass minification with raw=true, but it would kill most of RL
niceties too.


On Sun, Jul 13, 2014 at 6:10 AM, Brion Vibber bvib...@wikimedia.org wrote:

 I've started experimenting with embedding my ogv.js media player into
 TimedMediaHandler to provide Ogg playback in Safari and Internet Explorer:
 https://gerrit.wikimedia.org/r/#/c/145756/

 This involves on-demand loading of a fairly large chunk of mostly
 machine-generated, dense, pre-minified JavaScript that weighs in around a
 megabyte (gzips to 250k or so).


 Initially I tried tossing it in with the ResourceLoader modules and loading
 it with mw.loader.using(), but in some configurations the automatic JS
 minification in ResourceLoader was taking too long to process the file. (On
 MediaWiki-Vagrant with Zend PHP and Xdebug enabled, it actually hit the
 30-second execution limit. Ouch!)

 I couldn't find a way to disable minification for a particular module; it
 looks like it's applied as a filter step after modules are bundled
 together, so I'm not sure it's really possible.


 Currently I'm loading the ogv.js payload as a separate file with
 $.ajax({dataType:'script'}); this totally bypasses ResourceLoader and thus
 the minifier, but gzipping is dependent on the web server configuration.
 (MediaWiki-Vagrant's Apache configuration auto-gzips .js files, so yay!)

 I also lose other ResourceLoader features like automatic cache
 invalidation; for now I'm appending a  version parameter on the URL to
 ensure that the file is re-cached when updated, but it has to be manually
 updated along with the JS payload file.


 Any recommendations for making ResourceLoader and large, pre-minified JS
 sources fit together better? Or is what I'm doing pretty much the best
 practice for now? :)

 I'm considering a 'stub' ResourceLoaderModule subclass that generates the
 $.ajax() loader call including an automatic version timestamp URL parameter
 from the file's last-modification time...

 -- brion
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Best practices for loading large, pre-minified JavaScript modules?

[Max Semenik]

On Sun, Jul 13, 2014 at 6:35 PM, Krinkle krinklem...@gmail.com wrote:

 raw is what bypasses the client loader framework. So instead of
 returning a combined
 script/styles/messages response to the mw.loader.implement callback, it
 returns a raw
 response for only scripts, styles or messages – whichever is specified in
 the only=
 parameter – without a mw.loader.implement or mw.loader.state call.


Blargh, I'm quite good at forgetting stuff I myself have written :P

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HTML templating progress; Knockout Components curly brace syntax

[Max Semenik]

For all that is holy, we should pick one templating engine (that must be
compatible with both JS and PHP) and switch everything to it. Having many
templating engines would be horrible.


On Tue, Jul 8, 2014 at 12:56 PM, Ryan Kaldari rkald...@wikimedia.org
wrote:

 On Tue, Jul 8, 2014 at 12:20 PM, Rob Lanphier ro...@wikimedia.org wrote:

  Is there someone who has the time to perform and publish an independent
  audit on performance specifically?  We currently have this:
 
 
 https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library#Performance
 
  ...which suggests that Knockoff is 50% faster than then next fastest
  solution (Handlebars), and over 10x faster than most.  If this stands up
 to
  scrutiny, and holds true as Knockoff gains feature parity, this is a huge
  achievement that we should shout about far and wide, since I believe no
 one
  disputes that a DOM-based approach is much more secure than a
 string-based
  approach...
 

 Yes, it's 50% faster, but we're not really comparing apples to apples.
 Knockout/T-assembly requires a pre-compilation step, so we should keep that
 in mind in the comparisons. The pre-compilation doesn't affect performance,
 but it does add a layer of complexity to the process.

 The approach that Mantle is taking is pretty interesting, i.e. allowing you
 to use any templating system you want as long as it meets certain
 assumptions. I would love to see Knockout/T-assembly and Mantle move
 towards being compatible with each other (which wouldn't take much work).
 Then people who want maximum performance/security can use Knockout and
 people who want maximum simplicity can use Mustache, etc. I know there are
 probably few people on this list who would think that offering simplicity
 is important, but we should remember that we are an open source project
 with thousands of 3rd party users, many of whom are not professional
 programmers, but would love to be able to tweak the interface and build
 simple extensions. Adopting an MVC framework with templating/widgets is a
 huge step in the right direction, but we would be squandering the
 opportunity, IMO, if our only templating system is too complicated for
 novice programmers to figure out how to use. If we can offer the best of
 both worlds, that seems like the ideal solution to me.

 Ryan Kaldari
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Removing support for register_globals

[Max Semenik]

Can we use this as an opportunity to officially become 5.4 only? 5.5 would
be even cooler, but OMGTHINKOFTHECHILDREN!!!1ONEONEONE


On Tue, Jul 8, 2014 at 6:17 PM, Chad innocentkil...@gmail.com wrote:

 On Tue, Jul 8, 2014 at 6:01 PM, Legoktm legoktm.wikipe...@gmail.com
 wrote:

  Hi,
 
  tl;dr: https://gerrit.wikimedia.org/r/144854 stops supporting
  MediaWiki instances with register_globals enabled.
 
 
 Merged. The less of this cruft we hang onto the better.

 -Chad
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Removing support for register_globals

[Max Semenik]

On Tue, Jul 8, 2014 at 6:23 PM, Max Semenik maxsem.w...@gmail.com wrote:

 Can we use this as an opportunity to officially become 5.4 only? 5.5 would
 be even cooler, but OMGTHINKOFTHECHILDREN!!!1ONEONEONE


As a clarification: when we have it on our cluster, but that's actually
surprisingly close:)

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Separating Special:MyLanguage from Extension:Collection

[Max Semenik]

Aaaand this is implemented and is up for review:
https://gerrit.wikimedia.org/r/#/c/140765/

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Separating Special:MyLanguage from Extension:Collection

[Max Semenik]

The page looks kinda small and useful, so why not just move it into core?


On Tue, Jun 17, 2014 at 4:20 PM, Matthew Walker mwal...@wikimedia.org
wrote:

 Today, Kaldari wanted to have translate enabled on foundationwiki so that
 Special:MyLanguage was available, but that would fall afoul of bug:44871
 [1]. This is not a unique request, fundraising also has some use for
 MyLanguage features on wikis that don't have (and wont have) translate.

 Are there any concerns with separating out that special page into it's own
 extension? The one that immediately jumps to mind is how the i18n team
 bundles translate.

 [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44871

 ~Matt Walker
 Wikimedia Foundation
 Fundraising Technology Team
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Nesting of mediawiki/core/vendor inside mediawiki/core

[Max Semenik]

I actually think that Composer-installed stuff should be under $IP/includes
as that's where most code should be.


On Wed, Jun 11, 2014 at 3:26 PM, Tim Starling tstarl...@wikimedia.org
wrote:

 One thing that concerns me about the proposed composer setup, that I
 haven't mentioned yet, is the nesting of the project hierarchy, with
 mediawiki/core/vendor inside mediawiki/core.

 You know that we have mediawiki/extensions instead of
 mediawiki/core/extensions -- that makes it easy to check out all
 Gerrit repos in the natural directory hierarchy and to still have a
 clean $IP/extensions which you can use for installer testing or whatever.

 I wonder if a similar solution is possible with vendor -- could we
 have mediawiki/vendor instead of mediawiki/core/vendor? Then it would
 be possible to play around with dropping things into $IP/vendor while
 still having the vendor git repo checked out in a sensible location,
 available for editing.

 -- Tim Starling


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes in API action=parsemobileformat=...

[Max Semenik]

This change is getting finalised with https://gerrit.wikimedia.org/r/138029
- please fix your code if you haven't done so yet!


On Wed, Oct 23, 2013 at 1:56 PM, Max Semenik maxsem.w...@gmail.com wrote:

 Hi, in response to bug 54607 [1], we've changed the semantics of the
 mobileformat parameter to action=parse

 == Summary ==

 Previously, it used to accept strings 'html' or 'wml', later just
 'html' and modify the structure of output (see below). This was problematic
 because you needed to retrieve the HTML from output in different ways,
 depending on whether mobileformat is specified or not. Now,
 mobileformat is a boolean parameter, that is if there's a 'mobileformat'
 parameter in request, it will be treated as the output should be
 mobile-friendly, regardless of value. And the output structure will
 be the same. For compatibility with older callers,
 mobileformat=(html|wml) will be special-cased to return the older
 structure at least for 6 month from now. These changes will start
 being rolled out to the WMF sites starting from tomorrow, Tuesday
 October 24th and this process will be complete by October 31st.

 == Examples ==

 === Non-mobile parse ===

 api.php?action=parseformat=xml

 {
 parse: {
 title: ...,
 text: {
 *: foo
 }
 }
 }

 api.php?action=parseformat=json

 ?xml version=1.0?
 api
   parse title=... displaytitle=...
 text xml:space=preservefoo/text
   /parse
 /api


 === Parse that outputs mobile HTML, old style ===

 api.php?action=parseformat=jsonmobileformat=html

 {
 parse: {
 title: API,
 text: foo
 }
 }

 api.php?action=parseformat=xmlmobileformat=html

 ?xml version=1.0?
 api
   parse title=... text=foo displaytitle=...
   /parse
 /api

 === Parse that outputs mobile HTML, new style ===

 api.php?action=parseformat=...mobileformat

 Same as for non-mobile parses.

 == FAQ ==

 Q: I didn't use mobileformat before, does anything change for me?
 A: No.

 Q: I use mobileformat=html, will my bot/tool be broken now?
 A: No, you will have 6 months to switch to new style.

 Q: I'm only planning to use mobileformat, what should I do?
 A: Just use the new style.

 Q: How did this format discrepancy appear in the first place?
 A: To err is human.

 -
 [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=54607




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] LiquidThreads - how do we kill it?

[Max Semenik]

So you propose to never ever change the look and feel because it might piss
off some old-timers?


On Fri, Jun 6, 2014 at 6:01 PM, Juergen Fenn schneeschme...@googlemail.com
wrote:

 2014-06-07 2:44 GMT+02:00 Arcane 21 arc...@live.com:
  Going to have concur on this. Flow and VE would be great for attracting
 new users, but leaving the foundation of the community in the dust in favor
 of innovation strikes me as a bad idea.
 
  I support the idea of having the ability for the old methods of editing
 and talk pages to work when and where possible and for the transition to
 newer ideas to be as gentle as possible on those who might otherwise be
 alienated by the changes.

 Again, I would like to invite you to think twice. I talked about the
 psychological foundation for participating in such a large project as
 Wikipedia. It needs tact not to harm an already suffering community
 when such sweeping changes should be introduced.

 No one has ever asked for our opinion whether we want this or not. It
 is decided over our head, par ordre de mufti. Most of us insist on
 community processes taking place for introducing new technology on
 such a big scale, not in order to deactivate it.

 Again, this is all about breaking a community. And we cannot discuss
 this in terms of what is good or bad because you cannot revert the
 negative impact new technology will have on old editors. This is not
 only about technology. It's about psychology. And the latter will
 prevail.

 Regards,
 Jürgen.

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deployments of new, radically different default features

[Max Semenik]

I thought we already had this discussion recently:
http://www.gossamer-threads.com/lists/wiki/wikitech/412782?do=post_view_threaded#412782


On Sat, May 17, 2014 at 2:55 PM, Rainer Rillke rainerril...@hotmail.comwrote:

 Recently, Media Viewer[1] (MMV) has been switched at Wikimedia Commons
 to be default.

 As some people do not care a lot for beta features or new features, do
 not read the mailing lists and overlook main discussion forums or are
 just unable to understand English, they were surprised and confused and
 wondered how they could disable the feature.

 Please help me to evaluate if there are alternatives to how software
 deployment is currently done. Here are some suggestions from community
 member Jameslwoodward (commons adminstrator):


 A Post a banner so that there is a good chance of actually reaching
   everyone.
 B Ensure that the internally referenced help page actually has correct
   information.
 C Major changes can be the default for new users, but should be opt-in
   for existing users.

 I think (A) could be partially done by tech-ambassadors (what a
 difficult word); however when deploying something like MMV to all wikis,
 isn't this worth a CentralNotice?

 (B) is as obvious as important. Outdated information is confusing. Make
 sure to update your help pages before going to release your software to
 the wild. Or delay the release until this is done.

 Suggestion (C) is interesting, although perhaps technically difficult to
 implement.
 If a feature that one experienced as anonymous user is good [login
 cookies expire, ...], or one explicitly tested the feature or was told
 by a fellow about a good feature, it is very likely that one will enable
 that feature for the account, too. People will do this freely. Without
 complaining. And people, who intentionally enabled a feature, usually
 have a positive attitude, are willing to help and improve the feature.
 They will provide you with constructive feedback.
 The overall atmosphere would be a lot more positive than that we
 currently experience with new tools, *the power users do not need*. So
 why not actively promoting a feature until there is a critical mass
 using it? It may take a lot of time but I think it's worth a test.


 A personal appeal:
 Please care about the power users [2]. They are the core and foundation
 of the WMF projects. They create the content; manage most issues - think
 about the OTRS team - in their spare time, ... so WMF can finally run
 the fundraiser banners and you can get your payment.

 -- Rillke


 [1] https://www.mediawiki.org/wiki/Help:Multimedia/Media_Viewer
 [2]

 http://www.aswedeingermany.de/50SoftwareDevelopment/20MostImportantRuleOfUIDesign.html

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Deployments of new, radically different default features

[Max Semenik]

I actually think that  anons should be the last to gget new features if at
all possible: they are the group least informed about projects' internal
workings and thus it's hard for them to report problems.


On Sat, May 17, 2014 at 3:37 PM, John phoenixoverr...@gmail.com wrote:

 Here is an interesting deployment idea, roll out but leave as opt-in for a
 period of time, after a month or so, set as default for anons and new
 accounts, During the whole process keep track of who has enabled it and
 then disabled it, vs never enabled it. After a period of time move everyone
 who hasnt specifically disabled the viewer to have the setting as default.

 This would achieve several different things all at the same time, enabling
 wider spread testing/debugging, and a phased deployment process that should
 minimize negative user impact as much as possible. As I have seen way too
 many features pushed out to the general pubic long before they should
 have been. WMF wikis take mediawiki and wikitext along with templates and
 the parser and make them do some really odd things. It doesnt matter how
 much testing you do, quirks will pop up. In a phased deploy process that
 utilizes both watchlist and central notices this should keep the fallout
 to  minimum.
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l