Recently Wikimedia sites switched to https-only for privacy reasons, and
the https certificate has been updated to prevent access altogether where a
secure connection couldn't be established.
This is a problem because some schools and companies deliberately eavesdrop
https for monitoring purposes by inserting an in-house https certificate.
Wikimedia's switch to https-only is preventing people from such networks
from even *reading* Wikipedia.
Is there a compromise that can be sought?
On Mon, Jun 22, 2015 at 10:30 PM, John Mark Vandenberg <jayvdb(a)gmail.com>
> Ugh, is there a way to configure pygments to have fallbacks for
> languages which are substantially based on another? e.g. xpp is
> basically java, and looks quite good when I tested it on betalabs. I
> am sure that Pygments has some parser close to 'email', as they do
> support a 'http session' language.
Yes. We maintain a mapping from GeSHi lexer names to compatible Pygment
Making xpp render as Java would be as simple as adding "xpp" => "java". If
you submit a patch, I will be happy to merge it.
Over the course of the next two days, a major update to the
SyntaxHighlight_GeSHi extension will be rolled out to Wikimedia wikis. The
change swaps geshi, the unmaintained PHP library which performs the lexical
analysis and output formatting of code, for another library, called
The roll-out will remove support for 31 languages while adding support for
several hundred languages not previously supported, including Dart, Rust,
Julia, APL, Mathematica, SNOBOL, Puppet, Dylan, Racket, Swift, and many
others. See <https://people.wikimedia.org/~ori/geshi_changes.txt> for a
full list. The languages that will lose support are mostly obscure, with
the notable exception of ALGOL68, Oz, and MMIX.
The change is expected to slightly improve the time it takes to load and
render all pages on all wikis (not just those that contain code blocks!),
at the cost of a slight penalty (about a tenth of a second) on the time it
takes to save edits which introduce or modify a block of highlighted code
to an article.
Lastly, the way the extension handles unfamiliar languages will change.
Previously, if the specified language was not supported by the extension,
instead of a code block, the extension would print an error message. From
now on, it will simply output a plain, unhighlighted block of monospaced
The wikitext syntax for highlighting code will remain the same.
As most of you know (hopefully), anonymous editing on mobile has been
enabled for all projects (except Korean Wikipedia). One of the side effects
of this is that there has been an increase in vandalism that uses emoji (
https://en.wikipedia.org/wiki/Emoji). Much of this vandalism is not caught
by existing AbuseFilter filters. I encourage all projects to add new
AbuseFilter filters for detecting emoji, and either showing a warning or
preventing such edits.
The Unicode range for all emoji characters is [🌀-🙏🚀-🛳☀-➿], although you
may need to customize this for your particular project. For example, the
emoji characters ★ and ☆ are commonly used in Japanese song titles.
Feel free to steal the filter currently in use on English Wikipedia:
Please note that some community-run bots may stop working unless they are
fixed before the end of June:
---------- Forwarded message ----------
From: Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org>
Date: 2 June 2015 at 13:42
Subject: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for
action=query will change at the end of this month
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>,
As has been announced several times (most recently at
the default continuation mode for action=query requests to api.php will be
changing to be easier for new coders to use correctly.
*The date is now set:* we intend to merge the change to ride the deployment
train at the end of June. That should be 1.26wmf12, to be deployed to test
wikis on June 30, non-Wikipedias on July 1, and Wikipedias on July 2.
If your bot or script is receiving the warning about this upcoming change
(as seen here
example), it's time to fix your code!
- The simple solution is to simply include the "rawcontinue" parameter
with your request to continue receiving the raw continuation data (
No other code changes should be necessary.
- Or you could update your code to use the simplified continuation
documented at https://www.mediawiki.org/wiki/API:Query#Continuing_queries
which is much easier for clients to implement correctly.
Either of the above solutions may be tested immediately, you'll know it
works because you stop seeing the warning.
I've compiled a list of bots that have hit the deprecation warning more
than 10000 times over the course of the week May 23–29. If you are
responsible for any of these bots, please fix them. If you know who is,
please make sure they've seen this notification. Thanks.
Brad Jorsch (Anomie)
Wikitech-l mailing list
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester