TL;DR: Parsoid isn't i18n friendly and uses English keywords instead of
localized.[1] Is it a bug or feature? Please voice your opinion!
Longer version:
For some funny reasons Parsoid is reading arrays from "right to left"[1],
that is, it uses the LAST alias of the magic words rather than the first
one[2].
One of the reasons for this is because in English the shorter "thumb" is
preferred compared to the long "thumbnail". However, instead of fixing
MessagesEn.php to define thumb as the first option, parsoid uses the last
option.
This choice result in all other wikis using the English alias (which
appears last in magic words) rather than the localized one - so Parsoid
isn't i18n friendly.
However there are different POVs regarding the correct solution for it:
1. Use English aliases in all projects - these are the most used aliases
[and one of the reasons is people copying code from enwiki or using biased
tools such as Parsoid]
2. Use localized aliases - keep the article content and syntax in the same
language. This is especially important for non-latin languages with
different alphabet.
And there is a consensus for English being bad choice for RTL languages as
it cause mixed directional content which should be avoided. So if we go
with 1 choice, RTL languages should be exception.
I believe there is a cultural point of view here, and would like to hear
what do you think (especially non RTL and non English speakers): Do you
prefer mini (German), vignette (French), miniaturadeimagen (Spanish), мини
(Russian) instead of thumb (for example)?
I did some dump-minning to get the usage statistics:
https://phab.wmfusercontent.org/file/data/bskxfupspqo64dnnkdr7/PHID-FILE-v4…
And based on this I wrote a python script to suggest a reordering of the
aliases by usage[3], so if choice 2 is selected, we can merge[2] and all
languages will use the preferred choice.
[1] https://phabricator.wikimedia.org/T53852
[2] https://gerrit.wikimedia.org/r/#/c/244254/3/lib/wts.LinkHandler.js
[3] https://gerrit.wikimedia.org/r/#/c/247914
Hey all,
I'm writing to let you know of a cool new facility for debugging MediaWiki
code on the Wikimedia production cluster -- the X-Wikimedia-Debug
<https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug> HTTP header.
By setting this header on requests to Wikimedia wikis, you can:
- Bypass the cache.
- Force Varnish to pass your request to a specific backend server.
- Profile request and log profiling data to XHGui.
- Turn on all log channels and send log messages to a special view in
Kibana / Logstash.
- Force MediaWiki to process the request in read-only mode.
And the best part: there are browser extensions for Chrome and Firefox that
provide a friendly user-interface for these features:
http://i.imgur.com/XzWUk0h.gifvhttp://i.imgur.com/lJ7l6Vl.gifv
Cool? Cool.
Read the docs on Wikitech
<https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug> for more
information.
Hi,
this week's RFC update sees two RFCs entering the discussion, and one RFC (on
requiring mbstring <https://phabricator.wikimedia.org/T129435>) entering
the "final comment period", after which a decision will be made.
Gabriel
RFC inbox:
T130567: WIP RFC: Hygienic transclusions for WYSIWYG, incremental parsing &
composition <https://phabricator.wikimedia.org/T130567>: High-level
companion task to T114444 DOM scopes
<https://phabricator.wikimedia.org/T114444> and T114445 Balanced templates
<https://phabricator.wikimedia.org/T114445>. Moving to “Needs shepherd”.
Tim?
T16950: Support global preferences
<https://phabricator.wikimedia.org/T16950>: "It would be nice if users and
developers could designate certain preferences to automatically apply
across all wikis. This will require A Lot of Work™.
Extension:GlobalPreferences is a rough draft of the functionality."
Leaving in inbox, RobLa will ask Kunal.
Today's IRC session:
Open discussion about the following RFCs
-
T124504 <https://phabricator.wikimedia.org/T124504> Transition WikiDev
'16 working areas into working groups
-
T123753 <https://phabricator.wikimedia.org/T123753> Establish
retrospective reports for Security
<https://phabricator.wikimedia.org/tag/security/> and Performance
<https://phabricator.wikimedia.org/tag/performance/> incidents
-
T119908 <https://phabricator.wikimedia.org/T119908> [RfC]: Migrate code
review / management to Phabricator from Gerrit
-
T120164 <https://phabricator.wikimedia.org/T120164> RfC: Institute "last
call" period for MediaWiki RfCs (WIP)
Much of the discussion was on T119908: [RfC]: Migrate code review /
management to Phabricator from Gerrit
<https://phabricator.wikimedia.org/T119908>, and some on T123753
<https://phabricator.wikimedia.org/T123753> (retrospectives). RobLa has
posted a full summary of the discussion
<https://phabricator.wikimedia.org/E152#1603> on phabricator.
Entering Final Comment Period:
RFCs which are reaching a decision are entering a week-long 'final comment
period', after which the ArchCom makes a final decision based on the
discussion. Express your opinions now. This week's FCPs are:
T129435 RFC: Drop support for running without mbstring
<https://phabricator.wikimedia.org/T129435> (Gabriel): The PHP mbstring
module enables multi-lingual string handling. Given good distribution
support and significant performance benefits, most participants have
expressed support for requiring the module. If you think that we should
continue to provide fall-backs despite relatively poor performance, then
please comment now.
Under discussion:
T108655 Standardise on how to access/register JavaScript interfaces
<https://phabricator.wikimedia.org/T108655> (Roan) Minimal version was
approved and being implemented. Waiting for drafting of second RFC for the
more contentious changes.
T122942 RFC: Support language variants in the REST API
<https://phabricator.wikimedia.org/T122942> (Gabriel): Different options
for supporting language variant selection in the REST API. Needed for
languages like Chinese.
T39902 RFC: Implement rendering of redlinks (in a post-processor?)
<https://phabricator.wikimedia.org/T39902> (Gabriel): Solutions for
highlighting links to non-existing pages in Parsoid HTML. Main question is
preprocessing vs. separate metadata processed on client. Parsing and
Services teams investigating performance trade-offs.
T130663 WIP RFC: Reference API requirements and options
<https://phabricator.wikimedia.org/T130663> (Timo): Working with Gabriel
and others to better define the scope of the RFC and come up with a solid
proposal. Relates to other on-going product goals and may be delayed on
better clarification on those and gathering of other use cases /
requirements.
T18691 RFC: Section headings should have a clickable anchor
<https://phabricator.wikimedia.org/T18691> (Timo): Working on better
understanding of the problem space and possible solutions. Volker gathered
various considerations and challenges on the RFC’s talk page at
mediawiki.org. Check them out!
T124504 Transition WikiDev '16 working areas into working groups
<https://phabricator.wikimedia.org/T124504> (RobLa): Highlighting in E152
T66214 Use content hash based image / thumb URLs & define an official thumb
API <https://phabricator.wikimedia.org/T66214> (Brion): No changes in the
last week.
T124792 Service Locator for MediaWiki core
<https://phabricator.wikimedia.org/T124792> (Daniel): Discussed in E150
last week. Daniel is interested in a possible working group; will discuss
at Hackathon.
T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap
<https://phabricator.wikimedia.org/T113034> (Daniel): No update since March
17.
No activity since March 16:
T122825 Service ownership and minimum maintenance requirements
<https://phabricator.wikimedia.org/T122825> (Gabriel)
T128351 RFC: Notifications in core
<https://phabricator.wikimedia.org/T128351> (Brion)
T118517 RFC: Use <figure> for media
<https://phabricator.wikimedia.org/T118517> (Brion)
T88596 Improving extension management
<https://phabricator.wikimedia.org/T88596> (Daniel)
T114444 RFC: Introduce notion of DOM scopes in wikitext
<https://phabricator.wikimedia.org/T114444> (Tim)
T130528 RFC: PSR-6 Cache interface in Mediawiki core
<https://phabricator.wikimedia.org/T130528> (No shepherd)
--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation
We’ve gotten good participation as we’ve worked on sections of the Code
of Conduct over the past few months, and have made considerable
improvements to the draft based on your feedback.
Given that, and the community approval through the discussions on each
section, the best approach is to proceed by approving section-by-section
until the last section is done.
So, please continue to improve the Code of Conduct by participating now
and as future sections are discussed. When the last section is
completed and approved on the talk page, the Code of Conduct will become
policy and no longer be marked as a draft.
Also, two more discussions regarding the Code of Conduct have been
resolved and incorporated into the draft.
* "Enforcement issues" addressed the reporting process and clarified
that Committee decisions could not be circumvented
* "Marginalized and underrepresented groups" forbids discrimination
Thanks,
Matt Flaschen
Hello,
A heads up that the Reading Web team has been updating the MobileFrontend
schema code to use mw.eventLog rather than the custom Schema class [1].
This will mean that MobileFrontend won't support logging events anymore if
sendBeacon is not supported. We used to use localStorage to support
non-sendBeacon browsers.
Baha
[1] https://phabricator.wikimedia.org/T122504
Process update starting next week: * If you'd like something you say to
make it into the weekly Tech News, tag it with #technews
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-03-30
= *2016-03-30* =
== Technology ==
=== Analytics ===
* '''*Blocking'''*: none
* '''*Blocked'''*: none
* '''*Updates*'''*:*
** Unique Devices data released, pageviews data officially released,
pagecounts-raw, pagecounts-all-sites deprecated,
dumps.wikimedia.org/analytics has details
** Request Breakdown reports from Hadoop are ready, they replace the old
Wikistats squid reports, some UI improvements coming shortly
-
=== Architecture ===
* '''*Blocking'''*:
** ???
* '''*Blocked'''*:
** ???
* '''*Updates*'''*:*
** ???
=== Performance ===
* '''*Blocking'''*:
** ???
* '''*Blocked'''*:
** ???
* '''*Updates*'''*:*
** ???
=== Release Engineering ===
* '''*Blocking'''*:
** ???
* '''*Blocked'''*:
** ???
* '''*Updates*'''*:*
** scap 3.1 will be in production on Tuesday April 5th, now with large
binary support! (via git-fat (what trebuchet used for feature parity))
** Code freeze week of April 18th (DC switchover)
=== Research ===
* '''*Blocking'''*:
** none
* '''*Blocked'''*:
** none
* '''*Updates*'''*:*
** Deployed ORES swagger & v2 paths. Can now ask for feature lists and do
feature injection when scoring. Announcement coming.
=== Security ===
* '''*Blocking'''*:
** ???
* '''*Blocked'''*:
** ???
* '''*Updates*'''*:*
** ???
=== Services ===
* '''*Blocking'''*:
** /
* '''*Blocked'''*:
** /
* '''*Updates*'''*:*
** RESTBase
*** Redirects for File: titles active only for the native moblie apps
*** general availability blocked on VE -
https://phabricator.wikimedia.org/T130757
*** bumped s-maxage for purged content to 1 week
** deployed the change-propagation service (via scap3)
** working on docs - https://www.mediawiki.org/wiki/Documentation/Services
=== Technical Operations ===
* '''*Blocking'''*:
** noone
* '''*Blocked'''*:
** by noone
* '''*Updates*'''*:*
** changeprop is live, worked with Marko from Services team
** working on ORES and scap3 integration with Amir
== Product ==
=== Community Tech ===
* '''*Blocking'''*:
** ???
* '''*Blocked'''*:
** ???
* '''*Updates*'''*:*
** ???
=== Discovery ===
* '''*Blocking'''*:
** Not that we are aware of
* '''*Blocked'''*:
** Quick Surveys:Not known to be blocked on anyone in SoS, but we might ask
for help
** Existing: ops https://phabricator.wikimedia.org/T127014 and security
https://phabricator.wikimedia.org/T127014
* '''*Updates*'''*:*
** We are experimenting publishing weekly status updates:
https://www.mediawiki.org/wiki/Discovery/Status_updates
=== Editing ===
==== Collaboration ====
* '''Blocking''':
** External store work
* '''Blocked''':
* '''Updates''':
** Working on support for Flow notifications being properly hidden on
moderation
** Work on the Echo special page
==== Language ====
* '''*Blocking'''*:
** None
* '''*Blocked'''*:
** None
* '''*Updates*'''*:*
** Work on Parallel Corpora dump (will) need some time from Ops (Ariel),
See: https://phabricator.wikimedia.org/T127793
==== Multimedia ====
* '''*Blocking'''*:
** ???
* '''*Blocked'''*:
** ???
* '''*Updates*'''*:*
** ???
==== Parsing ====
[ Subbu: I am feeling under the weather and will probably be napping /
resting and won't show up for this SoS .. Scott might show up if he sees
his email in time, but I've updated the etherpad in any case ]
* '''*Blocking'''*:
** None
* '''*Blocked'''*:
** None
* '''*Updates*'''*:*
** VE team and CX teams already knows about the tasks I've filed against
them for setting user-agent headers, accept headers. I've filed a ticket
against Flow as well to set user-agent header in your request. Not urgent,
but good to get it done sooner than later.
** Work ongoing to move data-mw out from an inlined attribute .. CX, VE,
Flow: please start thinking about what this means and how you will process
data-mw and html from separate api requests. The Parsoid and RESTBase side
work will be done in 2-3 weeks time (which includes performance evaluation
and impact of supporting old versions, etc.). We'll not turn this on in
production (3-4 weeks away at least) without consulting with all affected
clients, but the accept: header is your way of getting the old version till
you are ready to switch, but we prefer that the switch not be delayed
inordinately. I've already filed tickets against these projects, but this
is just a heads up.
==== VisualEditor ====
* '''*Blocking'''*:
** ???
* '''*Blocked'''*:
** ???
* '''*Updates*'''*:*
** ???
=== Fundraising Tech ===
* '''*Blocking'''*:
** None
* '''*Blocked'''*:
** None
* '''*Updates*'''*:*
** More DonationInterface refactoring
** Investigating ActiveMQ replacement options
** More work towards mass (reversible) contact de-duping in CiviCRM
** Scoping work to update PayPal integration
=== Reading ===
==== Android ====
* '''*Updates*'''*:*
** Content Service is rolling out successfully. (25% of Android production
app as of Monday evening)
==== iOS =====
* '''*Blocking'''*:
** None
* '''*Blocked'''*:
** None
* '''*Updates*'''*:*
** 5.0.1 Deployed last week
** 5.0.2 Being deployed this week
(Just decided this on Monday - we received a call from Apple that there is
an OS bug causing our app to crash and we needed to work around it)
==== Web ====
* Language switcher overlay being deployed
==== Reading Infrastructure ====
* Gather
* AuthManager for 1.27 branch in progress (disabled switch for now)
* Flow, able to tackle https://phabricator.wikimedia.org/T129397 ?
* Wikidata, https://phabricator.wikimedia.org/T131176 ?
Hello all,
I'm prepared to participate in IEG and has an idea closely linked to the Accuracy Review Project raised by James Salsman. Here is a brief summary of my proposal:
Out-of-date information and references are common in Wikipedia entries, especially in Chinese Wikipedia. Therefore, I would like to evaluate some existed solutions of identifying those out-of-date contents, and create a new bot to identify the information based on the results of testing. More detailed tests will be arranged after that by selected entries from Wikipedia and the cases that we compile.
And here is the URL of the project the proposal:
https://meta.wikimedia.org/wiki/Grants:IdeaLab/Searching_for_out-of-date_in…
Because there is already relative discussion in this mailing list, please comment on the proposal in the discussion board of it at:
https://meta.wikimedia.org/wiki/Grants_talk:IdeaLab/Searching_for_out-of-da…
Li Linxuan
TL;DR:
* Review site scripts to verify that no wikibits methods[1] are used.
* If you find usage of wikibits, refactor the code to use newer methods
instead, or add a dependency on the 'mediawiki.legacy.wikibits' module.
Hi all,
The deprecation and eventual removal of the legacy "wikibits" JavaScript
module has been a long time coming. This announces another step in that
direction.
In 2011, wikibits was deprecated following the introduction of
ResourceLoader in MediaWiki 1.17. To accommodate pre-ResourceLoader code
that doesn't have a concept of dependencies, $wgIncludeLegacyJavaScript was
created to allow existing sites (such as Wikimedia wikis) to load
"mediawiki.legacy.wikibits" by default on all pages. While most code no
longer uses wikibits, it remains set to this day.
In 2013, we introduced mw.log.deprecate in MediaWiki 1.23 to help you
detect any use of deprecated methods in the browser's developer console.[2]
We have seen a big reduction in the use of such methods.[3]
In 2015, we made significant performance improvements in MediaWiki 1.26, by
running JavaScript asynchronously rather than blocking page rendering. To
avoid breaking undeclared use of wikibits, we made an exception for
wikibits and kept it as blocking other JavaScript modules on page views,
re-purposing $wgIncludeLegacyJavaScript to mean "always load wikibits
before other modules".
Now, as the last step before removing wikibits from MediaWiki, it will
first no longer load by default in MediaWiki 1.27. This change will roll
out on Wikimedia wikis in April 2016. If you find usage of wikibits
features without a dependency, please refactor this code to use the modern
replacements[1], or add an explicit dependency as temporary stop-gap while
figuring out how to refactor the code.
Before re-factoring, please remember to first check whether the associated
code is working. Many wikibits methods have become empty placeholders to
avoid cascading failures. As such, blind updates may cause old or broken
code that is currently invisible to re-activate itself. Removing dead code
speeds up wikis for all users, and reduces the risk of things going wrong
in future.
For third-party wikis, this will ship in MediaWiki 1.27.0. If needed, you
can alter LocalSettings.php and set $wgIncludeLegacyJavaScript to true.
This will give you time to fix missing dependencies on wikibits. In
MediaWiki 1.28, to be released in November 2016, the wikibits module will
be removed entirely.
-- Krinkle
[1] https://www.mediawiki.org/wiki/ResourceLoader/Legacy_JavaScript
[2]
https://lists.wikimedia.org/pipermail/wikitech-l/2013-October/072776.html
[3] https://grafana.wikimedia.org/dashboard/db/mw-js-deprecate?from=now-10M