I've just now enable the feature flag on the Beta Cluster[1] that allows
MediaWiki to store comments longer than 255 bytes.
The web UI has not been updated to allow longer comments in places where it
enforces a limit, such as the edit summary box. But if you use the API to
edit, or perform page moves or do other things where long comments could be
entered and were truncated, you should now find that they're truncated at
1000 Unicode characters rather than 255 bytes.
Please test it out! If you find errors, or places in core features (not
comments in extensions such as SecurePoll, AbuseFilter, CheckUser, or Flow)
where *new* comments are still being truncated to 255 bytes, or places
where comments aren't showing up at all, please let me know. You can reply
to this message or post a task in Phabricator and add me as a subscriber.
If things go well, we'll look at rolling this out to production wikis once
the schema changes to the production databases are complete. See
https://phabricator.wikimedia.org/T174569 to follow progress there.
If anyone is interested in submitting patches for the web UI to reflect the
changed length limits, please do. I'll try to review them if you add me as
a reviewer.
[1]: https://deployment.wikimedia.beta.wmflabs.org/wiki/Main_Page
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Hey there.
I love MediaWiki and have been using it everywhere for years. Recently
I've been doing some rather major documentation and I realised there
were three features which would be really handy for me (if these or
similar already exist I would love to know!):
1. For links to articles in sections on the same page it would be really
handy if we had syntax like: [[#unity|]] which would auto-complete to
[[#unity|unity]] for you.
2. For duplicated content it would be handy if you could define a bunch
of "variables" down the bottom of a page and then reference them from
elsewhere. I am aware of templates, but those are overkill and difficult
to maintain per my use case (my use case is documenting the "purpose" of
a computer, I duplicate this in various places, but don't want to
maintain templates for that).
3. It would be cool if for any given wiki page an "estimated reading
time" could be provided. Along with maybe a word count, character count,
etc.
Since I'm here, quick thanks to the MediaWiki community for creating
such wonderful wiki software!
Regards,
John Elliot V
--
E: jj5(a)jj5.net
P: +61 4 3505 7839
W: https://www.jj5.net/
Hi everyone,
The third annual Community Wishlist Survey starts today, and you're invited
to post proposals for projects that you'd like WMF's Community Tech team to
work on:
https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey
The Community Tech team builds features and makes changes that active
Wikimedia contributors want, and the Wishlist Survey sets the team's agenda
for the year.
The Wishlist Survey starts with a two-week proposal period, when
contributors from all Wikimedia projects are invited to post, discuss and
improve propsals. After that, there's a two-week voting period, when
everyone can post support-votes on the proposals that they think are
worthwhile. We end up with a ranked list of wishes, measured by the
participants' enthusiasm for each idea.
Community Tech is responsible for addressing the top 10 wishes on the list,
as well as some wishes from smaller groups and projects that are doing
important work, but don't have the numbers to get their proposal into the
top 10. The Wishlist is also used by volunteer developers and other teams,
who want to find projects to work on that the community really wants.
So I hope that everybody comes and participates; it's an opportunity to set
the agenda for a Wikimedia Foundation product team.
We would also ask that you help us spread the word. Please do post on your
wikis and tell others this is happening, and that if they don't feel
comfortable writing in English, proposals are welcome in any language.
I hope to see everyone there!
Danny Horn
WMF Community Tech
Hello,
There was a badly timed database failure today that has caused all
deployments to be on hold until the situation is resolved.
See: https://phabricator.wikimedia.org/T180714 "db1063 crashed"
The MW Train blocker task, https://phabricator.wikimedia.org/T178635,
will be updated when we move forward.
Sorry for the inconvenience,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |
Hello all!
Here are the minutes from this week's meeting:
* Marko Obrovac joined the Technical Committee. We are looking forward to
working with him. Welcome Marko!
* Last Call: RFC on imported user names
<https://phabricator.wikimedia.org/T179832>. After the public discussion on
November 15, it was agreed that this RFC should enter the last call period. If
no pertinent concerns remain unaddressed by November 29, this RFC will be
approved for implementation.
* Next week’s RFC discussion: Bump PHP requirement to 7.0 in MW 1.31
<https://phabricator.wikimedia.org/T172165>. This is a reiteration of the RFC
discussion from a few weeks ago, which ended with a last call for the proposal
to go to PHP 5.6 for MW 1.31. The last call did not lead to approval, due to a
suggestion made by Anomie, namely to go for a subset of PHP 7 that is supposed
by hhvm in default mode, without the PHP7 flag set.
As always, the discussion will take place in the IRC channel
#wikimedia-office on Wednesday, at 2pm PST / 23:00 CET / 22:00 UTC.
* Roan is experimenting with RemexHTML for tag stripping
You can also find our meeting minutes at
<https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes>
See also the TechCom RFC board
<https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>.
--
Daniel Kinzler
Principal Platform Engineer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.