Hello all,
I would like to announce the release of MediaWiki Language Extension
Bundle 2016.01. This bundle is compatible with MediaWiki 1.25.x and
1.26.x.
Next MLEB is expected to be released in 3 months. If there are major
changes or important bug fixes, we will do intermediate release.
Please give us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2016.01.tar…
* sha256sum: 7a46bb96f852aa42f728c68e4e21558878c8cba703ce9f8f6c2316af7bbe03e3
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, CleanChanges and LocalisationUpdate ==
* Localisation updates only.
== CLDR ==
* Hebrew names for Cebuano and Norwegian are fixed.
* cldr converted to extension registration. Please update your
LocalSettings.php!
== Translate ==
* Old custom tokens were deprecated in favor of using regular "csrf"
(previously known as "edit") token. If you are using Translate WebAPIs
you might need to migrate.
* Special:Translations no longer shows PHP notices for pages with
invalid language codes
* Special:Translate now longer shows deprecation warnings about access
keys in the JavaScript console.
* Translate is now syntactically compatible with PHP7.
* Message group selector on Special:SearchTranslations no longer has
glitchy behavior after selecting a group.
* MessageIndex code was optimized. It now ignored messages not in
$wgTranslateMessageNamespaces. By default this should be fine, but if
you have translations in custom namespaces, check that they are
included.
* Pages with <languages /> now load faster with cold caches.
* MachineTranslationAid no longer throws uncaught exceptions with
default configuration that broke other translation aids.
== UniversalLanguageSelector ==
* ULS now uses extension registration and thus requires MediaWiki 1.25 or later
* Input methods should now work inside Visual Editor.
* Fonts:
** OpenDyslexic font updated to latest upstream.
** Akkadian font should work again.
* Input Methods:
* New input methods:
** Rodali (Assamese) layout.
** OdiScript (Oriya) layout.
** Yoruba layout.
* Updated input methods:
** Updated Oriya Lekhani layout.
** Digit fixes in Southern Kurdish layout.
** Minor fixes in Sinhala layout.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
Hi everyone,
Those with a keen eye will notice that I filed T124255
<https://phabricator.wikimedia.org/T124255>, which calls for renaming
#MediaWIki-RfCs in Phab to "#ArchCom-RfC". This would be a boring Phab
administrivia email if it was simply that.
The reason I want the rename: ArchCom is the mechanism we hope to ensure
we build and deploy increasingly excellent software on the Wikimedia
production cluster in a consensus-oriented manner. MediaWiki is at the
center of this, but ArchCom's responsibility doesn't end with MediaWiki.
T124255 <https://phabricator.wikimedia.org/T124255> is an odd place to have
a more sweeping conversation about the scope of ArchCom, but it'll do for
now. Feel free to comment there or on this mailing list.
Thanks
Rob
In the last weeks we have been exploring ways to improve our technical
consensus building and decision making process. I wrote a short RFC
[1] describing some issues, and proposed to adopt ideas from the Rust
community [2] to address them. The discussion on the task and in an
IRC meeting showed broad support for the proposals.
In yesterday's architecture committee meeting, we decided to adopt
much of the Rust RFC decision making process [3] on a trial basis.
Concretely, this means:
- We will nominate a member of the architecture committee as a
shepherd, guiding an active RFC through the process. Among other
things, the shepherd is responsible for informing all relevant
stakeholders of the ongoing discussion on the task. The shepherd might
also lead an IRC discussion on the RFC, which will be summarized on
the task.
- Once the discussion on a task plateaus or stalls, the shepherd (in
coordination with the RFC author(s)) announces and widely publicizes a
"Final Comment Period", which is one week.
- At the end of the "Final Comment Period", the architecture committee
decides based on the points made in the RFC discussion, and justifies
its decision based on the overall project principles and priorities.
If any new facts or aspects are surfaced in this discussion, a new
Final Comment Period needs to be started before making a decision.
For now, we are holding off on the second part of the RFC, the
introduction of working groups. There is agreement that we need to
broaden the involvement and scale the process, but the details of how
are still under discussion.
Gabriel
[1]: https://www.mediawiki.org/wiki/Requests_for_comment/Governance
[2]: https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md
[3]: https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md#…
TLDR: The backend server used for releases.wikimedia.org has moved.
use bromine.eqiad.wmnet instead of caesium.eqiad.wmnet
Do i care? You do if you are a "releaser" in one of the admin groups
who upload files to releases.wm.org.
Hi,
the backend of releases.wm.org has moved away from caesium.eqiad.wmnet over
to bromine.eqiad.wmnet. The reason was to get rid of yet another outdated
Ubuntu system and replace it with a Debian jessie system.
All the releases files in /srv/org and your /home directories have been
copied over,
everything should be like before, just use the new server name please.
The task for that was https://phabricator.wikimedia.org/T124261
While on it i made the directory index page look a bit nicer and sort
files differently so that new release versions are on top.
The details for that were in https://phabricator.wikimedia.org/T125164
Let me know if you see any issues,
Best, Daniel
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
With the merge of Gerrit change 264309,[1] to be deployed with
1.27.0-wmf.12, note the following changes to the PHP interface around login
and account creation tokens:
- LoginForm::setLoginToken() and LoginForm::setCreateaccountToken() are
deprecated and no longer do anything. The token is automatically created
when fetched.
- LoginForm::getLoginToken() and LoginForm::getCreateaccountToken() now
return a MediaWiki\Session\Token object rather than a string. This object
implements __toString(), so automatic casting to a string is supported and
will likely mask this change for many uses.
- The token strings themselves are now similar to edit tokens: they're
longer, end in "+\", and include an embedded timestamp for expiration.
- Due to the embedded timestamp, tokens must now be compared using the
->match() method on the Token object. String equality comparison will no
longer work.
- It is no longer possible to determine if the token was not already
generated for the session by looking for an empty response from
LoginForm::getLoginToken() and LoginForm::getCreateaccountToken(). If
this is necssary (it shouldn't be), use the ->wasNew() method on the Token
object.
If your PHP code makes use of login or account creation tokens for some
reason, please check to see if your code needs updating for these changes.
For the record, a new method User::getEditTokenObject() has been added to
fetch edit tokens as MediaWiki\Session\Token objects as well, but
User::getEditToken() and User::matchEditToken() have not been changed or
deprecated at this time.
Note that API clients and other non-PHP users of these tokens are unlikely
to be broken by this change. See
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/0…
for details on changes to the API related to this change.
[1]: https://gerrit.wikimedia.org/r/#/c/264309/
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
As you may be aware, the reading team was unhappy with its current release
process and shared its rationale
<https://www.mediawiki.org/wiki/Reading/Web/Release_process/experiment#Ratio…>
for a different release process. This resulted in an experiment on Gather,
QuickSurveys, Cards and RelatedArticles where the team developed on the dev
branch by default. When the team was happy that the dev branch was stable,
it would tag a release and merge to master. The idea was to minimise the
deployment of incomplete features and SWAT deploys.
This process saw mixed success. Although we felt more comfortable and in
control of the code we shipped due to more time for designers and product
owners to input into our process it was clear there was an impedance
mismatch with the expectations in the MediaWiki developer community and for
a small team of 5, we were unable to keep up with the periodic releases of
extensions we were not actively maintaining.
As a result we are abandoning this experiment and going back to
the Mediawiki Way™ of releasing and merging directly to master.
When we work on new features, we will be more mindful of +2, marking the
initial commit of a chain of commits that requires sign off from a designer
and product owner with a -2.
We think this will be a better approach for everyone. Our only remaining
question is when and if to do release number bumps in future. We'll be back
with an answer about that shortly... ideas welcomed.
Thank you for your patience while we experimented and let us know if there
is anything else of interest to you in this experiment we have run.
Notes from post-mortem are on wiki
<https://www.mediawiki.org/wiki/Reading/Web/Notes/2016-Q3_Branching_strategy…>
I will be presenting at FOSDEM on the LiquidThreads to Flow conversion,
at 2016-01-30, 16:00 Belgium time:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=FOSDEM+LiquidThrea…
It will be live-streamed at
https://live.fosdem.org/watch.php?room=H.2215%20(Ferrer) (from what I
can tell in advance).
Thanks,
Matt Flaschen
-------- Forwarded Message --------
Subject: Your speaking schedule at FOSDEM
Date: Fri, 15 Jan 2016 22:13:33 +0100 (CET)
From: FOSDEM Programme Team <speakers(a)fosdem.org>
Reply-To: speakers(a)fosdem.org
Organization: FOSDEM - https://fosdem.org/
To: Matt Flaschen <mflaschen(a)wikimedia.org>
CC: speakers(a)fosdem.org
Dear speaker,
Thank you for agreeing to speak at FOSDEM!
Our programme is now complete:
https://fosdem.org/2016/schedule/
This is your schedule:
.----------------------------------------------------------------------------.
| day | time | room | title
|
+------------+----------+-----------------+----------------------------------+
| 2016-01-30 | 16:00:00 | H.2215 (Ferrer) | Converting LiquidThreads to
Flow |
'------------+----------+-----------------+----------------------------------'
.---------------------------------------------.
| links |
+---------------------------------------------+
| https://fosdem.org/2016/schedule/event/flow |
'---------------------------------------------'
Please check these links carefully. If you already created an account at:
https://fosdem.org/submit
you can login and update the information if need be.
In particular, please upload a photograph if you have not already done
so and enter or update your biography.
Changes take a few minutes to reach the website - the time it was last
updated appears at the bottom of this page:
https://fosdem.org/2016/schedule/events/
If you find yourself unable to attend, please let your room's organiser
know this as soon as possible.
FOSDEM intends to record and stream the entire conference live - that's
over 300 hours of content! The recordings will be published under the
same licence as all FOSDEM content (CC-BY). You are agreeing to this by
taking part in the event.
Any slide decks you present should be uploaded by about half-an-hour
before the start of your talk so that people watching the live stream
can follow them locally if their video resolution leaves slide content
indistinct. (Our system does not hold back publication, so if you don't
want people to see them too far in advance, don't upload them yet.)
Projectors work at 1024x768 but expect slides (and any demonstrations)
to be scaled down to 720x576 for the video, so try to make them
readable at this lower resolution if you can.
Please don't forget to bring a VGA adaptor if you hope to present from a
laptop that only has a different type of output connector! We also
recommend bringing a spare copy of any slides on a USB stick.
As usual, we aim to provide free high-quality wireless network
connectivity throughout the event.
Best wishes,
The FOSDEM Programme Team
Good evening. For the past week, my bot has intermittently been seeing this
error when it tries to edit or upload:
API Error: Array
(
[code] => badtoken
[info] => Invalid token
[*] => See http://commons.wikimedia.org/w/api.php for API usage
)
It is unpredictable; it will occasionally fail for one thread, and then
work for a thread an hour later. Deleting the cookies has on occasion fixed
the issue for a few days.
Is there anything that can be done to fix this?
Magog