OOjs UI 0.8.0 has been released today. It will be in MW from 1.25wmf19+.
*Breaking changes since last release:*
- [BREAKING CHANGE] Make default distribution provide SVG with PNG
fallback (Bartosz Dziewoński)
We've tagged this as a breaking change, but the only breakage is renaming
the stylesheet files. This will only "break" for systems which are
responsible for importing the library. This is fixed for MediaWiki and
for VisualEditor
standalone; no other users should be affected.
As part of this change, from MediaWiki 1.25wmf19 onwards, OOjs UI will
provide raster icon fallbacks for the vector icons, which we were
previously not using.
*Deprecations since last major release:*
- DEPRECATION: TextInputWidget: Deprecate 'icon' and 'indicator' events
(Bartosz Dziewoński)
The functionality they expose (user clicking on the icon/indicator) is
fundamentally not accessible: the icon/indicator is not focusable (has no
tabindex), has no keyboard events, doesn't have a label associated or a
tooltip, and has no sensible way of fixing all of this. If something needs
to be clickable separately, it should probably be a separate Widget with
the appropriate mixins added.
- DEPRECATION: ButtonWidget: Rename nofollow config option to noFollow (C.
Scott Ananian)
We're switching this feature (added just last release) to use consistent
camel case. The old `nofollow` property still works for backward
compatibility, but it is deprecated and will be removed in the next major
release but one.
If you have any further questions or need help dealing with
deprecations, please
let me know. General library documentation is available at mediawiki.org
<https://www.mediawiki.org/wiki/OOjs_UI> and generated code-level
documentation at doc.mediawiki.org
<https://doc.wikimedia.org/oojs-ui/master/#!/api>.
- Trevor
Here are the minutes for this week's VisualEditor weekly triage meeting on
2015-02-18.
*Item 1 – Release criteria*
The release criteria at
https://phabricator.wikimedia.org/project/sprint/profile/1015/
(note new URL)
were
considered.
It was proposed and agreed that the wording for "Qualitative UX testing"
be changed from "Most users" to a specific number of 75%, and similarly in
"Meets specified performance benchmarks", that "reasonable" was changed to
a specific number of 150%. These changes have been made.
*Item 2 – Review of fixed tickets since last week*
These accepted items were fixed and so will be released in this week's
production release unless otherwise noted.
…
in VisualEditor:
- https://phabricator.wikimedia.org/T88650 – Support data-mw.body.id for
reference contents
- https://phabricator.wikimedia.org/T88148 – class="wikitable wikitable"
corrupted to class="wikitable"
- https://phabricator.wikimedia.org/T87161 – Default to not performing
sanity checks
- https://phabricator.wikimedia.org/T86401 – Cutting and pasting a
paragraph causes (only) the last inline template to be replaced by HTML
- https://phabricator.wikimedia.org/T74929 – Using browser native
interactive spell-check when the changed word in the only item in the
paragraph causes endless insertions in Firefox [*fixed in our IME work
in January*]
- https://phabricator.wikimedia.org/T74398 – Actually run
MediaWiki-VisualEditor's tests for MWHeadingNode / MWPreformattedNode
- https://phabricator.wikimedia.org/T67873 – Cannot go to the next line
of an article after inserting a special character in a block slug and
"TypeError: Inserted data is trying to close the root node (at index 0)"
appears [*fixed earlier*]
- https://phabricator.wikimedia.org/T65462 – Using browser native
interactive spell-check tool causing repeated automatic deletion in Chrome
[*fixed in our IME work in January*]
- https://phabricator.wikimedia.org/T61748 – Native browser interactive
spell-check tool fails to get content into DM, just CE, in Safari [*fixed
in our IME work in January*]
The fixed tickets represent 83 "story points". There are 1020 remaining
points in the list of items accepted as of the end of the meeting.
… in dependencies:
- https://phabricator.wikimedia.org/T88660 – Parsoid Cite: Render
missing reflists
- https://phabricator.wikimedia.org/T88019 – Transclusion marker meta
tags being left behind in some nested extension/transclusion scenarios
- https://phabricator.wikimedia.org/T85870 – Parsoid performance analysis
- https://phabricator.wikimedia.org/T75955 – RESTBase / Parsoid
integration - waiting for parsoid deploy
- https://phabricator.wikimedia.org/T69787 – Investigate remaining
rtselser errors in parserTest runs
*Item 3 – Review of nominated tickets*
Nominated tickets accepted:
… as corruption & stability issues:
- https://phabricator.wikimedia.org/T89192 –
[Regression wmf-16] Including a template/comment/table/gallery/math
node in a slug makes the editor completely unresponsive
- https://phabricator.wikimedia.org/T89309 –
[Regression wmf-17] Safari - cannot click in any check-box
… as performance issues:
- https://phabricator.wikimedia.org/T89543 –
ve.init.mw.ViewPageTarget.transformPage triggers recalculate style due
to $.fn.animate
- https://phabricator.wikimedia.org/T89423 –
Massive recalculate style triggered by OO.ui.Widget.setDisabled
- https://phabricator.wikimedia.org/T89536 –
Instrument (i.e., track) additional progress markers for VE load
- https://phabricator.wikimedia.org/T89735 –
VisualEditor is emitting event
"timing.ve.behavior.firstTransaction.undefined"
… as testing issues:
- https://phabricator.wikimedia.org/T89075 –
Investigate Chrome disconnect failures when running MediaWiki tests on
labs slaves
… as feature issues:
- https://phabricator.wikimedia.org/T88152 –
Cite: 'Autofill from URL' initially shows Basic as a type for inserted
citation in context menu, then corrects when re-selected
- https://phabricator.wikimedia.org/T89352 –
Make slugs keyboard accessible again
- https://phabricator.wikimedia.org/T76398 – External link interface for
link dialogue [high risk area; accepted with provision that we will
likely have to modify work based on user testing]
- https://phabriactor.wikimedia.org/T76397 – Search interface for link
dialogue [
high
technological
risk area; accepted with
lower priority, to be re-assessed
later
]
- https://phabricator.wikimedia.org/T52036
–
Focus highlights for elements using CSS column-count are too tall in
Chrome
[accepted as a "polish" issue]
- https://phabricator.wikimedia.org/T73085
– Comments in "unsafe" content locations are not displayed [accepted
as a lower-priority issue; needs technological investigation for
feasibility]
… as dependencies:
- https://phabricator.wikimedia.org/T89788
–
Report on the central tendency for length of pages which are edited for
VisualEditor performance benchmarking
… for investigation and re-triage:
- –
None this week
Nominated tickets rejected:
- https://phabricator.wikimedia.org/T89074
– Create a guided tour for VisualEditor using Getting Started tooltips
Rejected for now based on product concerns raised about targeting the
right user groups and in the right way, and technological risk/feasibility
about bringing in new systems into contact with VisualEditor. Likely to be
re-cast and re-nominated next week.
- https://phabricator.wikimedia.org/T89072 – Change Welcome dialogue
content to more helpful message to new users based on the GuidedTour
Rejected as dependent on the above ticket.
*Item 4 – Other business*
The process was very briefly discussed, without suggestion of changes.
Hope this is of interest. Next week's meeting will be at
00
<http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150225T16&p1=224…>
:00 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150225T16&p1=224…>
(
16
:00 PST) on Wednesday
25
February; hope to see many of you there. Joining instructions are on
mw:Talk:VisualEditor/Portal
<https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal#How_to_join_the_tri…>
. We'll send a reminder before the meeting.
Yours,
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Can someone explain the point of these lines to me?
https://github.com/wikimedia/mediawiki/blob/master/includes/Html.php#L269
If these tags are optional, they can be there, so why remove them? If
you remove them, you should probably also care about them in
closeElement() so that mediawiki doesn't produce html which has only
ending tags for html and head.
It seems that on WMF installation we don't use anyway as there is head
tag. So why is it there? What purpose does it server?
Hello,
A quick reminder about Language Engineering team's monthly IRC office hour
thats happening later today at 1300 UTC on #wikimedia-office. Please see
below for the original announcement, local time, and agenda. We will post
logs on metawiki[1] after the event.
Thanks
Runa
[1] https://meta.wikimedia.org/wiki/IRC_office_hours#Office_hour_logs
---------- Forwarded message ----------
From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org>
Date: Fri, Feb 13, 2015 at 7:47 PM
Subject: [x-post] Language Engineering IRC Office Hour on 18 February 2015
(Wednesday) at 1300 UTC
To: MediaWiki internationalisation <mediawiki-i18n(a)lists.wikimedia.org>,
Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>, Wikimedia
developers <wikitech-l(a)lists.wikimedia.org>, "Wikimedia & GLAM
collaboration [Public]" <glam(a)lists.wikimedia.org>
[X-posted announcement]
Hello,
The next monthly IRC office hour of the WMF Language Engineering team will
be on February 18, 2015 (Wednesday) at 1300 UTC on #wikimedia-office.
Please note that for this instance the session has been set to a much
earlier hour.
We will be taking questions and discussing about our ongoing projects,
particularly the recent activation of Content Translation as a beta feature
on several Wikipedias[1]. We’d love to hear comments, suggestions and any
feedback that will help us make this tool better.
Please see below to check local time and event details. Logs from our
earlier office hours are available at:
https://meta.wikimedia.org/wiki/Category:Language_Engineering
Thanks
Runa
[1] http://blog.wikimedia.org/2015/01/20/try-content-translation/
Monthly IRC Office Hour:
==================
# Date: February 18, 2015 (Wednesday)
# Time: 1300 UTC (Check local time:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150218T1300)
# IRC channel: #wikimedia-office
# Agenda:
1. Ongoing projects - Content Translation beta feature
2. Q & A (Questions can be sent to me ahead of the event)
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
Hi folks,
I was too tired of semi-working unstable random IRC services that
provides IRC commit messages from github to your channel, so I created
a simple plugin to wm-bot which can handle that now.
Features:
* It's incredibly easy to setup (10 seconds setup)
* Requires no registration
* Pretty stable (running on wikimedia labs)
* Self-service - everyone can configure the bot as they want directly from IRC
How it works in few steps:
1) Get wm-bot to your channel (just join #wm-bot and type @add #somechannel
2) type @github+ <full name of repository> for example for repository
http://github.com/benapetr/test it would be @github+ benapetr/test
3) Add web hook in github settings of your repository to
http://wm-bot.wmflabs.org/github/index.php
That's all
Example output:
(10:41:00) <wm-bot> GitHub [benapetr/test-wm] benapetr pushed 1
commits: https://github.com/benapetr/test-wm/compare/87ad2018cae6...f5b2131c10ad
(10:41:00) <wm-bot> GitHub [benapetr/test-wm] commit by benapetr
(Petr Bena) https://github.com/benapetr/test-wm/commit/f5b2131c10ad3bb1fe902db911ed0142…
test
Formatting kind of suck, but you can fix it! Handler is written in
PHP: https://github.com/benapetr/wikimedia-bot/blob/master/src/WMBot.Plugins/Git…
Hello,
We are migrating Jenkins jobs to simply invokes [test entry points] (ex:
composer test, npm test).
Some repositories have documentation generated by Jenkins and pushed
under https://doc.wikimedia.org/ . I would like to make it as trivial
as possible for developers to configure Jenkins, hence I am looking to
establish a convention to generate doc.
We would need:
- a single command we agree on (ex: make doc)
- a way to pass/override the destination directory so the jobs in
Jenkins can enforce the output where it expects it
I have filled https://phabricator.wikimedia.org/T88999 for it.
Discussions on wikitech-l preferred.
If there is no objections by next week. I will define the convention to
be 'make docs' and create all the needed Jenkins jobs templates.
Thanks!
[test entry points]
https://www.mediawiki.org/wiki/Continuous_integration/Test_entry_points
--
Antoine "hashar" Musso
It turns out we are in 2015. :D
On Tue, Feb 17, 2015 at 10:05 AM, Quim Gil <qgil(a)wikimedia.org> wrote:
> Hi, just a reminder about the deadline to submit proposals for Wikimania:
> February 28.
>
> https://wikimania2015.wikimedia.org/wiki/Submissions
>
> The Hackathon program will be more flexible in terms of deadline, process,
> etc, but if you want to have a session scheduled in the main Wikimania
> program you need to submit your proposal before the end of this month.
>
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi, just a reminder about the deadline to submit proposals for Wikimania:
February 28.
https://wikimania2015.wikimedia.org/wiki/Submissions
The Hackathon program will be more flexible in terms of deadline, process,
etc, but if you want to have a session scheduled in the main Wikimania
program you need to submit your proposal before the end of this month.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
I've opened a task on Phabricator[1] to attempt to merge the information
in extension.json with Composer's
already-used-by-several-extensions-and-skins composer.json.
Kunal has rightly pointed out that composer doesn't fit some use-cases
for MediaWiki. I see that as an opportunity to be good citizens in the
larger developer community by working to integrate MediaWiki into the
growing ecosystem available on packagist.org.
For example, if composer had been available, we might not have had to
develop our own HTTP client.
If composer had been available, Brion could have released the work under
includes/normal as its own package. As he says in the README there:
This directory contains some Unicode normalization routines. These
routines are meant to be reusable in other projects, so I'm not
tying them to the MediaWiki utility functions.
(Of course, there was PEAR, but that is ugly and centralized in a way
that composer is not.)
Using Composer for extensions also reduces the learning curve for
developers who want to adapt their work (which may already be available
via Composer) to be used in MediaWiki. It helps us increase the size of
the available developer community without too much effort.
Footnotes:
[1] https://phabricator.wikimedia.org/T89456
--
Mark A. Hershberger
NicheWork LLC
717-271-1084