As part of the on-going UI standardisation work[0], we have just merged
into MediaWiki master a patch that will allow users of HTMLForm[1] to
easily switch over to use OOUI[2]. This allows you to make your code use
the standard UI styling and components with very little effort, improving
consistency and accessibility.
To convert your code over from the existing styling of MediaWiki's HTMLForm
(or its VForm version), you can replace the instantiation command of
- $form = new HTMLForm( … );
- or:
- $form = HTMLForm::factory( 'vform', … );
-
with
- $form = HTMLForm::factory( 'ooui', … );
… and everything Should Just Work™.
This doesn't break anything for existing use of this code, and you can
explicitly retain the existing styling by using $form = HTMLForm::factory(
'table', … ); or 'div' or 'vform' instead if you wish. Feel free to add
your code to the epic task on Phabricator which is the central liaison
point for this work[3].
Finally, please be careful to check your interfaces after converting them –
although we have tested this and believe it works well, there may be some
edge cases where it doesn't quite work. We're still missing a few features
[4] (such as prettier radio buttons), which we're hoping to have ready in a
week or two. If do you find any such issues, please report them so we can
fix them. Also note that OOUI already implements the new "MediaWiki" theme
for all users, so please ensure you advertise the visual changes as they
roll out to minimise disruption.
[0] - https://phabricator.wikimedia.org/T49145
[1] - https://www.mediawiki.org/wiki/HTMLForm
[2] - https://phabricator.wikimedia.org/T85291
[3] - https://phabricator.wikimedia.org/T100270
[4] - https://phabricator.wikimedia.org/T100279
Yours,
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Hello,
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
Pygments.
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
code.
The wikitext syntax for highlighting code will remain the same.
-- Ori
Hello all together,
some time ago, WMF started to re-organize into a new structure to focus on
specific topics. Now, I think, the main tasks are done, so that I want to
bring a (for me, and I think and hope for some others, too) very important
topic back to the ToDo list: mobile editing.
In the past, the mobile web team (in which I mostly contributed, too)
maintained the mobile wikitext editor in a very basic state, and the
VisualEditor team maintained the VisualEditor for tablet users. Now, most
people of the former mobile web team moved to the new vertical
“Readership”, so I’m pretty sure, that the responsibility for all editing
stuff on mobile isn’t in this team anymore (reading ≠ editing), so I
think, that the new editing vertical maintains all the editing stuff,
including mobile editing. Now I have some questions around this topic:
1. I’m missing MobileFrontend in the list of maintained extensions on
https://www.mediawiki.org/wiki/Editing ? Are there plans to move all editing
features away from MobileFrontend, or is the editing code in MobileFrontend
unmaintained now? How volunteers are able to contribute to the right place?
What is the bigger image for editing code in mobile?
2. Is there a roadmap for the mobile VisualEditor? At the moment it’s
only available for tablet users (which makes contributing on smartphones a
bit hard, there is only a clean wikitext editor, see one of my next points).
I know task T93325[1], is that meant to enable mobile VE on smartphones,
too? What is the roadmap for it?
3. Are you planning to support a wikitext editor on mobile, too (Like
a light WikiEditor)? At the moment, the wikitext editor in mobile is very
very basic (basically without any feature). I submitted a change[2] to
enable some rally basic features to it, which, technically seems to be
merge able, but no-one of editing reviews it, neither it’s possible for a
volunteer (me :)) to find out, if such a feature matches the global vision
for mobile editing.
4. And the last point (any maybe the most important one): Who is the
person (or the group of person) I can contact for mobile related editing
things? In the time of the former mobile web team I have known the persons I
can ping on irc, e-mail or via mailing lists, now I’m a bit confused, who
is responsible for mobile editing, it’s like a gray veil :)
It would be great to have these points answered :)
[1] https://phabricator.wikimedia.org/T93325
[2] https://gerrit.wikimedia.org/r/#/c/194945/
Have a nice weekend!
Best,
Florian
http://devhub.wmflabs.org is a prototype of the "Data and developer hub", a
portal and set of articles and links whose goal is to encourage third-party
developers to use Wikimedia data and APIs. Check it out, your feedback is
welcome! You can comment on the talk page of the project page
https://www.mediawiki.org/wiki/dev.wikimedia.org , or file Phabricator
tickets in the project dev.wikimedia.org [1].
Since December 2013 Moiz Syed and others discussed creating "a thing" to
expose our APIs and data to developers. When S Page moved to WMF tech
writer, he wrote some articles for this on mediawiki.org and with Quim Gil
developed a landing page from the wireframe designs [2].
The prototype is using the Blueprint skin and running on a labs instance,
but the articles are all regular wiki pages on mediawiki.org that we
regularly import to http://devhub.wmflabs.org
Thanks to everyone who participated in the gestation of this idea!
-- S Page and Quim Gil
== FAQ ==
Q: How can I feature my awesome API or data set?
A: Create a task in the #dev.wikimedia.org and #documentation projects [3]
with "Article" in the title. You can draft an article yourself, following
the guidelines [4].
Q: Yet another site? Arghh!
A: Agreed, T101441 "Integrate new Developer hub with mediawiki.org" [5].
It's a separate site for now in order to present a different appearance.
Q: But why a different appearance? Why a separate skin?
Our competition for developer mindshare is sites like
https://developers.google.com/ . We believe looking like a 2000s wiki page
is a *deterrent* to using Wikimedia APIs and data. We hope that many
third-party developers join our communities and eventually contribute to
MediaWiki, but "How to contribute to MediaWiki" [6] is not the focus,
providing free open knowledge is.
Q: Why the Blueprint skin?
A: The Design team (now Reading Design) developed it for the OOUI Living
Style Guide [7] and it has some nice features: a fixed header, and a
sidebar that gets out of the way and combines page navigation and the TOC
of the current page.
Q: So why not use the Blueprint skin on mediawiki.org?
A: Agreed, T93613 "Deploy Blueprint on mediawiki.org as optional and
experimental skin" is a blocker for T101441. We appreciate help with it and
its blockers.
Q: I hate the appearance.
A: That's not a question :) You can forget the prototype exists and view
the same content at
https://www.mediawiki.org/wiki/API:Data_and_developer_hub
Q: What is "dev.wikimedia.org"?
A: http://dev.wikimedia.org will be the well-known shortcut to the landing
page. And dev.wikimedia.org is the project name for this "Data and
developer hub".
Q: I thought dev.wikimedia.org was going to integrate source
documentation/replace doc.wikimedia.org/enumerate all Wikimedia software
projects/cure cancer, what happened?
A: One step at a time. For now, its goal is, to repeat, "to encourage
third-party developers to use Wikimedia data and APIs".
Q: Why are the pages in the API: namespace?
A: That's temporary, they will probably end up in a dev: namespace on
mediawiki.org that uses the Blueprint skin by default (T369).
Q: Where are the talk pages?
A: It's a bug that the sidebar doesn't have a "Discussion" link (T103785).
The talk pages on the prototype all redirect to the talk pages for the
original pages on mediawiki.org, and Flow is enabled on them.
[1]
https://phabricator.wikimedia.org/maniphest/task/create/?projects=dev.wikim…
[2] https://www.mediawiki.org/wiki/Dev.wikimedia.org#Structure
[3]
https://phabricator.wikimedia.org/maniphest/task/create/?projects=dev.wikim…
[4] https://www.mediawiki.org/wiki/dev.wikimedia.org/Contributing
[5] https://phabricator.wikimedia.org/T93613 and its blockers
[6] https://www.mediawiki.org/wiki/How_to_contribute (a fine general entry
point)
[7] http://livingstyleguide.wmflabs.org/
--
=S Page WMF Tech writer
As has been announced several times (most recently at
https://lists.wikimedia.org/pipermail/wikitech-l/2015-April/081559.html),
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
<https://www.mediawiki.org/w/api.php?action=query&list=allpages>, for
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 (
example
<https://www.mediawiki.org/w/api.php?action=query&list=allpages&rawcontinue=1>).
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
(example
<https://www.mediawiki.org/w/api.php?action=query&list=allpages&continue=>),
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.
AAlertBot
AboHeidiBot
AbshirBot
Acebot
Ameenbot
ArnauBot
Beau.bot
Begemot-Bot
BeneBot*
BeriBot
BOT-Superzerocool
CalakBot
CamelBot
CandalBot
CategorizationBot
CatWatchBot
ClueBot_III
ClueBot_NG
CobainBot
CorenSearchBot
Cyberbot_I
Cyberbot_II
DanmicholoBot
DeltaQuadBot
Dexbot
Dibot
EdinBot
ElphiBot
ErfgoedBot
Faebot
Fatemibot
FawikiPatroller
HAL
HasteurBot
HerculeBot
Hexabot
HRoestBot
IluvatarBot
Invadibot
Irclogbot
Irfan-bot
Jimmy-abot
JYBot
Krdbot
Legobot
Lowercase_sigmabot_III
MahdiBot
MalarzBOT
MastiBot
Merge_bot
NaggoBot
NasirkhanBot
NirvanaBot
Obaid-bot
PatruBOT
PBot
Phe-bot
Rezabot
RMCD_bot
Shuaib-bot
SineBot
SteinsplitterBot
SvickBOT
TaxonBot
Theo's_Little_Bot
W2Bot
WLE-SpainBot
Xqbot
YaCBot
ZedlikBot
ZkBot
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Some of you may have noticed a bot [1] providing reviews for the
Mobilefrontend and Gather extensions.
This is a grass routes experiment [2] to see if we can reduce
regressions by running browser tests against every single commit. It's
very crude, and we're going to have to maintain it but we see this as
a crude stop gap solution until we get gerrit-bot taking care of this
for us.
Obviously we want to do this for all extensions but we wanted to get
something good enough that is not scaleable to start exploring this.
So far it has caught various bugs for us and our browser test builds
are starting to finally becoming consistently green, a few beta labs
flakes aside [3].
Running tests on beta labs is still useful but now we can use it to
identify tests caused by other extensions. We were finding too often
our tests were failing due to us neglecting them.
In case others are interested in how this is working and want to set
one up themselves I've documented this here:
https://www.mediawiki.org/wiki/Reading/Setting_up_a_browser_test_bot
Please let me now if you have any questions and feel free to edit and
improve this page. If you want to jump into the code that's doing this
and know Python check out:
https://github.com/jdlrobson/Barry-the-Browser-Test-Bot
(Patches welcomed and apologies in advance for the code)
[1] https://gerrit.wikimedia.org/r/#/q/reviewer:jdlrobson%252Bbarry%2540gmail.c…
[2] https://phabricator.wikimedia.org/T100293
[3] https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
Hi,
In the last few days I've been looking for reasons for the appearance of
unnecessary <nowiki> tags. This mostly happens because of various
VisualEditor and Parsoid issues. The developers have been very good at
fixing them, and now it happens very rarely, but there are still lots of
these useless tags lurking in pages.
Two examples are:
* '''<nowiki/>''' - this doesn't do anything at all. I couldn't reproduce
it in any way, so it's probably a bug that was fixed.
* <nowiki> </nowiki> in the beginning of a paragraph. This was added in the
past to avoid putting the paragraph in <pre>, but it's entirely useless,
because the spaces are trimmed. Now they are pre-trimmed, so this is also a
fixed bug, but a lot of pages still have it.
There may be more - I'm still looking for these.
It would be easy to write bots to fix such easy common cases, but they
would have to run on every project. Would it make sense to write them as
maintenance scripts that update them everywhere when people upgrade VE?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
cc wikitech
(thanks!)
On Tue, Jun 30, 2015 at 3:05 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> Thanks for the quick reply! :)
> Yes site notices should be disabled on mobile, but site notices on
> mobile are currently treated different to central notice banners
> (rightly or wrongly) so I can only assume that this is served via
> CentralNotice?
>
> The campaign has to be set specifically for mobile browsers however...
> without seeing the campaign in Central Notice I'm not able to provide
> much more help but options would be to not target mobile phones, or
> add some additional styles to make it work on mobile (it looks like it
> has a fixed width)
>
>
> On Tue, Jun 30, 2015 at 3:00 PM, Legoktm <legoktm.wikipedia(a)gmail.com> wrote:
>> Hi,
>>
>> On 06/30/2015 02:49 PM, Jon Robson wrote:
>>> I noticed a banner on the mobile site that renders the site unusable:
>>> http://imgur.com/qVGz3mZ
>>>
>>> I'm not sure who is responsible for "Freedom of Panorama in Europe in
>>> 2015" but can someone disable this on mobile asap or make it work on
>>> mobile?
>>
>> The sitenotice been temporarily disabled for other reasons right now.
>>
>>> Please also reach out to us on the mobile-l mailing list ahead of
>>> running these campaigns if you are unsure how to test campaigns, we're
>>> happy to help.
>>
>> In InitialiseSettings.php, I see:
>>
>> 'wmgMFEnableSiteNotice' => array(
>> 'default' => false,
>> ),
>>
>> So I assumed that it wouldn't show up on mobile at all. Is that no
>> longer the case?
>>
>> -- Legoktm
>>
>> _______________________________________________
>> Mobile-l mailing list
>> Mobile-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
I noticed a banner on the mobile site that renders the site unusable:
http://imgur.com/qVGz3mZ
I'm not sure who is responsible for "Freedom of Panorama in Europe in
2015" but can someone disable this on mobile asap or make it work on
mobile?
Please also reach out to us on the mobile-l mailing list ahead of
running these campaigns if you are unsure how to test campaigns, we're
happy to help.
Jon