Wikitech-l March 2016

wikitech-l@lists.wikimedia.org

109 participants
98 discussions

The future of Related Pages feature
by Moushira Elamrawy 04 Apr '16

04 Apr '16

Hello everyone, Related pages feature has been in beta for over two months now, the future of the feature depends on our discussions. While we currently don't have a clear process for deciding collaboratively on an all languages product, Alsee and the reading team have put together this document on meta [0], as a request for comment, seeking comments and ideas on modifications required, and how to further test the feature. In fact, we are not sure if an rfc is the best strategy to move forward with product decisions, but lets see how the discussion evolves, and we might explore the need for a different process, as we move on with this one. We managed to translate a brief introduction about the topic, please feel free to fully translate the document and/or further promote the discussion on your wiki. We are trying hard to avoid having an English centric discussion for a feature that could be available across all language projects, and while we don't have a clear solution for this, we are trying this method as an experiment, where at least our communities can leave comments in their preferred language if they aren't comfortable writing in English but they can understand it. Please check the page, help with translation or promotion in your Wikipedia, and most importantly, comment on how you think it can evolve. :) Lets see how this works! All the best, M [0] https://meta.wikimedia.org/wiki/Requests_for_comment/Related_Pages

8 7

Let's make parsoid i18n great again
by Eran Rosenthal 02 Apr '16

02 Apr '16

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

6 9

X-Wikimedia-Debug, your new secret side-kick
by Ori Livneh 01 Apr '16

01 Apr '16

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.gifv http://i.imgur.com/lJ7l6Vl.gifv Cool? Cool. Read the docs on Wikitech <https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug> for more information.

7 7

ArchCom RFC update
by Gabriel Wicke 31 Mar '16

31 Mar '16

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

2 1

Sections of Code of Conduct resolved and Code of Conduct approval process
by Matthew Flaschen 31 Mar '16

31 Mar '16

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

1 0

MobileFrontend schema code (EventLogging) changes
by Baha Man 30 Mar '16

30 Mar '16

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

1 0

2016-03-30 Scrum of Scrums meeting notes
by Grace Gellerman 30 Mar '16

30 Mar '16

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 ?

1 0

Reminder: CREDIT showcase Wednesday, 6-April-2016
by Adam Baso 30 Mar '16

30 Mar '16

Hello world - Reminder: the next CREDIT showcase will be 6-April-2016 at 1800 UTC (1100 SF). Looking forward to your demos! Please see the following links for information and to add your demo :) https://www.mediawiki.org/wiki/CREDIT_showcase https://etherpad.wikimedia.org/p/CREDIT -Adam

1 0

[IEG] Sharing of my Individual Engagement Grant application, please common on it
by DJAKN 30 Mar '16

30 Mar '16

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

1 0

[BREAKING CHANGE] Legacy wikibits will no longer loaded by default on Wikimedia wikis and MediaWiki 1.27
by Krinkle 30 Mar '16

30 Mar '16

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

5 7

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l March 2016