Developer Wishlist/2017/Frontend

From mediawiki.org
Developer Wishlist 2017
Frontend

17 proposals, 83 editors, 216 votes

The voting phase has concluded. Thanks for participating!

You can view the results or discuss how to follow up.


Support a responsive grid system

Tracked in Phabricator
Task T90687

In order to consistently accommodate multiple screen sizes we need a responsive grid system.

We had an RFC and an initial implementation that needs some polishing. Additional work may be needed to make sure it works well with OOjs-UI components.

Endorsements (T90687)

Support (T90687)

  1. Shizhao (talk) 06:59, 6 February 2017 (UTC)[reply]
  2. —TheDJ (Not WMF) (talk • contribs) 09:00, 6 February 2017 (UTC)[reply]
  3. RHo (WMF) (talk) 11:35, 6 February 2017 (UTC)[reply]
  4. ThurnerRupert (talk) 12:05, 6 February 2017 (UTC)[reply]
  5. Osnard (talk) 12:55, 6 February 2017 (UTC)[reply]
  6. NKohli (WMF) (talk) 13:24, 6 February 2017 (UTC)[reply]
  7. Amir E. Aharoni (talk) 14:03, 6 February 2017 (UTC)[reply]
  8. BDavis (WMF) (talk) 16:25, 6 February 2017 (UTC)[reply]
  9. EBernhardson (WMF) (talk) 18:01, 6 February 2017 (UTC)[reply]
  10. CMadeo (WMF) (talk) 20:11, 6 February 2017 (UTC)[reply]
  11. SamanthaNguyen (talk) 22:10, 6 February 2017 (UTC)[reply]
  12. Daniel Mietchen (talk) 22:29, 6 February 2017 (UTC)[reply]
  13. — MusikAnimal talk 22:44, 6 February 2017 (UTC)[reply]
  14. [[kgh]] (talk) 23:27, 6 February 2017 (UTC)[reply]
  15. Santhosh.thottingal (talk) 03:36, 7 February 2017 (UTC)[reply]
  16. Nikerabbit (talk) 08:05, 7 February 2017 (UTC)[reply]
  17. Chico Venancio (talk) 13:23, 7 February 2017 (UTC)[reply]
  18. Jaider msg 19:11, 7 February 2017 (UTC)[reply]
  19. MHolloway (WMF) (talk) 22:09, 7 February 2017 (UTC)[reply]
  20. Trizek (talk) 13:08, 8 February 2017 (UTC)[reply]
  21. Cindy.cicalese (talk) 14:12, 8 February 2017 (UTC)[reply]
  22. Calexit (talk) 21:48, 9 February 2017 (UTC)[reply]
  23. RichardHeigl (talk) 23:39, 9 February 2017 (UTC)[reply]
  24. Sam Wilson 01:26, 10 February 2017 (UTC)[reply]
  25. BSitzmann (WMF) (talk) 22:45, 11 February 2017 (UTC)[reply]
  26. Helder 14:51, 12 February 2017 (UTC)[reply]
  27. Mglaser (talk) 10:14, 13 February 2017 (UTC)[reply]
  28. James Martindale (talk) 16:58, 13 February 2017 (UTC)[reply]
  29. 47.222.203.135 17:54, 13 February 2017 (UTC)[reply]
  30. TerraCodes (talk) 20:59, 13 February 2017 (UTC)[reply]
  31. PaleAqua (talk) 01:57, 14 February 2017 (UTC)[reply]
  32. Framawiki (talk) 17:33, 14 February 2017 (UTC)[reply]
  33. Quiddity (WMF) (talk) 19:40, 14 February 2017 (UTC)[reply]
  34. Daniel Renfro 20:38, 14 February 2017 (UTC)[reply]

Remove IE8 hacks/workarounds/etc. from extensions

Tracked in Phabricator
Task T123218

As of rMWdf1019c49d30: startup.js: Move IE8 down from Grade A to Grade C, MediaWiki no longer serves JavaScript to IE8 users. There are a lot of IE8 hacks lying around that can now be removed. grepping for "IE8" will likely find a lot.

Endorsements (T123218)

Support (T123218)

  1. David1010 (talk) 06:40, 6 February 2017 (UTC)[reply]
  2. Consulnico (talk) 09:35, 6 February 2017 (UTC)[reply]
  3. Ladsgroup (talk) 09:58, 6 February 2017 (UTC)[reply]
  4. ThurnerRupert (talk) 12:02, 6 February 2017 (UTC)[reply]
  5. ·addshore· talk to me! 12:16, 6 February 2017 (UTC)[reply]
  6. Amir E. Aharoni (talk) 13:47, 6 February 2017 (UTC)[reply]
  7. Jdforrester (WMF) (talk) 16:21, 6 February 2017 (UTC)[reply]
  8. — MusikAnimal talk 22:42, 6 February 2017 (UTC)[reply]
  9. Santhosh.thottingal (talk) 03:32, 7 February 2017 (UTC)[reply]
  10. Info-Screen (talk) 05:41, 7 February 2017 (UTC)[reply]
  11. Chico Venancio (talk) 13:19, 7 February 2017 (UTC)[reply]
  12. Momin salman (talk) 20:29, 8 February 2017 (UTC)[reply]
  13. Enterprisey (talk) 20:30, 8 February 2017 (UTC)[reply]
  14. Headbomb (talk) 20:52, 8 February 2017 (UTC)[reply]
  15. SamanthaNguyen (talk) 21:57, 9 February 2017 (UTC)[reply]
  16. Smalyshev (WMF) (talk) 02:25, 10 February 2017 (UTC)[reply]
  17. NKohli (WMF) (talk) 12:44, 10 February 2017 (UTC)[reply]
  18. BSitzmann (WMF) (talk) 22:46, 11 February 2017 (UTC)[reply]
  19. Helder 14:51, 12 February 2017 (UTC)[reply]
  20. James Martindale (talk) 16:58, 13 February 2017 (UTC)[reply]
  21. TerraCodes (talk) 21:00, 13 February 2017 (UTC)[reply]
  22. BrentLaabs (talk) 01:07, 14 February 2017 (UTC)[reply]
  23. Framawiki (talk) 17:33, 14 February 2017 (UTC)[reply]
  24. Max Semenik (talk) 18:37, 14 February 2017 (UTC)[reply]

Core should be aware of the domain it is running on and render mobile domains where necessary

Tracked in Phabricator
Task T156847

Whenever a link to a desktop url is rendered on a mobile page, clicking it can take you to the desktop site (or at best cause you to go through an unnecessary redirect loop). This impacts Flow, Echo, MobileFrontend (languages) and causes lots of development pain.

A call to getFullURL or getFullRequestURL should be aware of the domain it is running on and give the correct result.

Endorsements (T156847)

  1. In Wikipedia Zero this stuff required a fair amount of debugging, so resolution if it would be nice for consistency's sake. It's true, of course, that upon fixing this extensions that are impacted would need some TLC to ensure non-breakage. ABaso (WMF) (talk) 18:11, 6 February 2017 (UTC)[reply]
  2. This would be an incredible first step to moving/replacing lots of the mobile detection code from MobileFrontend to core. Jdlrobson (talk) 00:58, 7 February 2017 (UTC)[reply]

Support (T156847)

  1. Shizhao (talk) 06:55, 6 February 2017 (UTC)[reply]
  2. --Шухрат Саъдиев (talk) 11:58, 6 February 2017 (UTC)[reply]
  3. Amir E. Aharoni (talk) 13:48, 6 February 2017 (UTC)[reply]
  4. Bmansurov (WMF) (talk) 14:26, 6 February 2017 (UTC)[reply]
  5. BDavis (WMF) (talk) 16:22, 6 February 2017 (UTC)[reply]
  6. Daniel Mietchen (talk) 22:24, 6 February 2017 (UTC)[reply]
  7. Jack Phoenix (Contact) 23:10, 6 February 2017 (UTC)[reply]
  8. [[kgh]] (talk) 23:24, 6 February 2017 (UTC)[reply]
  9. Jdlrobson (talk) 00:57, 7 February 2017 (UTC)[reply]
  10. Santhosh.thottingal (talk) 03:33, 7 February 2017 (UTC)[reply]
  11. Samuele2002 (talk) 23:25, 7 February 2017 (UTC)[reply]
  12. — Mr. Stradivarius ♪ talk ♪ 08:43, 11 February 2017 (UTC)[reply]
  13. BSitzmann (WMF) (talk) 22:47, 11 February 2017 (UTC)[reply]
  14. Mglaser (talk) 10:15, 13 February 2017 (UTC)[reply]
  15. Framawiki (talk) 17:33, 14 February 2017 (UTC)[reply]
  16. Quiddity (WMF) (talk) 19:41, 14 February 2017 (UTC)[reply]

Provide an alternative (more declarative) way to create classes in OOJS (UI)

Tracked in Phabricator
Task T156235

Problem

Creating new classes/widgets with OOJS UI feels very cumbersome (see T155567: Make OOjs UI easier to use for gadgets). E.g. method declaration is split into different statements all across the source file.

Who would benefit

Any developer that wants to work with OOJS (UI)

Proposed solution

Create a high level function that allows more declarative creation of a class. E.g.: 

OO.defineClass({
    className: 'MyExtension.ui.dialog.Edit' //"namespace" get's created automatically
    extends: 'OO.ui.Dialog',
    titleMsg: 'myext-dialog-edit-title',
    initialize: function () {
        MyExtension.ui.dialog.Edit.super.prototype.initialize.call( this );
        this.content = new OO.ui.PanelLayout( { padded: true, expanded: false } );
        this.content.$element.append( '<p>A simple dialog window. Press \'Esc\' to close. </p>' );
        this.$body.append( this.content.$element );
    }
});

Endorsements (T156235)

Support (T156235)

  1. SamanthaNguyen (talk) 22:09, 6 February 2017 (UTC)[reply]
  2. Prtksxna (talk) 07:48, 7 February 2017 (UTC)[reply]
  3. Samuele2002 (talk) 23:26, 7 February 2017 (UTC)[reply]
  4. RichardHeigl (talk) 23:40, 9 February 2017 (UTC)[reply]
  5. — Mr. Stradivarius ♪ talk ♪ 08:44, 11 February 2017 (UTC)[reply]
  6. Mglaser (talk) 10:16, 13 February 2017 (UTC)[reply]
  7. Osnard (talk) 11:35, 13 February 2017 (UTC)[reply]
  8. Thiemo Mättig (WMDE) 15:45, 14 February 2017 (UTC)[reply]
  9. 0x010C (talk) 18:56, 14 February 2017 (UTC)[reply]
  10. Quiddity (WMF) (talk) 19:42, 14 February 2017 (UTC)[reply]

Provide an easy to use HTML mail system

Tracked in Phabricator
Task T156231

Problem

By default MediaWiki sends only oldfashioned plain text mails. With Extension:Echo there is at least a way to deliver some kind of HTML mail, but it is still very hard to customize the layout and design of those mails (need to override/extend classes).

Who would benefit

All developers that need to customize notification mails. This is especially a need in business contexts.

Proposed solution

There could be some directory that contains an HTML template and all required resources. E.g <mediawiki>/resources/mail/default which contains body.html, header.jpg, styles.css, ... Also the use of a library like SwiftMailer or PHPMailer should be considered.

There has been some approaches in the past, and I believe something like this is already planned for the Outreachy T15303: Implement HTML e-mail support in MediaWiki


Endorsements (T156231)

Support (T156231)

  1. SSethi (WMF) (talk) 04:41, 6 February 2017 (UTC)[reply]
  2. David1010 (talk) 06:40, 6 February 2017 (UTC)[reply]
  3. --Шухрат Саъдиев (talk) 12:01, 6 February 2017 (UTC)[reply]
  4. ·addshore· talk to me! 12:18, 6 February 2017 (UTC)[reply]
  5. SamanthaNguyen (talk) 22:11, 6 February 2017 (UTC)[reply]
  6. [[kgh]] (talk) 23:25, 6 February 2017 (UTC)[reply]
  7. Reasno (talk) 16:43, 8 February 2017 (UTC)[reply]
  8. Edward Chernenko (talk) 22:20, 9 February 2017 (UTC)[reply]
  9. RichardHeigl (talk) 23:35, 9 February 2017 (UTC)[reply]
  10. Mglaser (talk) 10:16, 13 February 2017 (UTC)[reply]
  11. Osnard (talk) 11:35, 13 February 2017 (UTC)[reply]
  12. Ideally with server-side email-HTML-output-support which co-operates with aka builds upon the new responsive-grid-layout feature. 47.222.203.135 17:54, 13 February 2017 (UTC)[reply]
  13. B20180 (talk) 13:43, 14 February 2017 (UTC)[reply]
  14. Framawiki (talk) 17:34, 14 February 2017 (UTC)[reply]

Make it easier to create an OOUI theme

Tracked in Phabricator
Task T155562

To create a theme currently: get the oojs/ui repo, copy-paste the src/themes/blank directory to your own name, list the new theme in Gruntfile.js and maybe a few other places (i could find them all if you're serious about doing this), and start writing the CSS

I want a more modular approach, where themes are definable in any extension, and consist of an array of variables in json or less or something which OOUI then assembles that into the css/js itself:

  • A set of colours for different things (borders, backgrounds, text, different types of buttons, etc)
  • General properties - how much spacing in general, whether to even use any shadows, whether buttons should be gradiented or flat, whether to override fonts, that sort of thing
  • Specific properties for all the types of things (buttons, dialogs, inputs, etc) such as rounded corners, gradients, shadows, fonts, padding - none, or specific values (what sort of gradient, what sort of shadow, how much padding)
  • ...
  • Profit?


Endorsements (T155562)

  1. Instead of reinventing the wheel, let's benefit, as much as possible, from a neighboring ecosystem that is far more advanced than MW in this domain. Calexit (talk) 22:04, 9 February 2017 (UTC)[reply]

Support (T155562)

  1. Charlie Kritschmar (WMDE) (talk) 12:17, 6 February 2017 (UTC)[reply]
  2. Jan Dittrich (WMDE) (talk) 12:41, 6 February 2017 (UTC)[reply]
  3. SamanthaNguyen (talk) 22:09, 6 February 2017 (UTC)[reply]
  4. RichardHeigl (talk) 23:40, 9 February 2017 (UTC)[reply]
  5. Mglaser (talk) 10:17, 13 February 2017 (UTC)[reply]
  6. Osnard (talk) 11:36, 13 February 2017 (UTC)[reply]
  7. Framawiki (talk) 17:56, 14 February 2017 (UTC)[reply]

VE support for skins should be done by adding appropriate anchors/ids/styles to the skins, and not by editing VE itself

Tracked in Phabricator
Task T155554

Apparently the only way to make a skin work with VE is to edit VE itself. This makes it very hard to make new skins compatible with VE, despite more and more third-party projects desiring such compatibility.

It should be the other way around - compatibility should be in the skin, not VE. The skin should be edited to meet VE's expectations (maybe have appropriate ids or whatever on things where it should be showing up around the content, or a js snippet specifying how it is supposed to show up, or whatever?), and modified and styled appropriately to look right with it.

And how to do this should be documented somewhere so we can actually, well, do it.

Endorsements (T155554)

Support (T155554)

  1. SamanthaNguyen (talk) 22:09, 6 February 2017 (UTC)[reply]
  2. Daniel Mietchen (talk) 22:26, 6 February 2017 (UTC)[reply]
  3. Jack Phoenix (Contact) 23:10, 6 February 2017 (UTC)[reply]
  4. [[kgh]] (talk) 23:25, 6 February 2017 (UTC)[reply]
  5. Deryck C.Meta 11:35, 7 February 2017 (UTC)[reply]
  6. Matěj Suchánek (talk) 13:48, 7 February 2017 (UTC)[reply]
  7. Samuele2002 (talk) 23:27, 7 February 2017 (UTC)[reply]
  8. Ciencia Al Poder (talk) 11:51, 12 February 2017 (UTC)[reply]
  9. Mglaser (talk) 10:17, 13 February 2017 (UTC)[reply]
  10. Osnard (talk) 11:36, 13 February 2017 (UTC)[reply]
  11. PaleAqua (talk) 01:59, 14 February 2017 (UTC)[reply]
  12. — 0x010C ~talk~ 19:01, 14 February 2017 (UTC)[reply]

Remove QUnit CompletenessTest

Tracked in Phabricator
Task T155194

The CompletenessTest was my attempt at getting a basic code coverage report using run-time inspection instead of static instrumentation.

It was never fully developed, remained somewhat unstable, isn't used by Jenkins or otherwise enabled or encouraged, and its results are not publishable, either. (Only works locally as on the Special:JavaScriptTest HTML view).

The "export" feature for Special:JavaScriptTest introduced in 2014 for Karma and TestSwarm (ba50b3255) lacked support support for loading the CompletenessTest. And when the regular "skinned" mode was deprecated and, eventually, removed last year in 0f9e4ca0f it essentially hasn't been used anymore as far as I can see.

From a Git-wide search I see that various Wikibase repositories still have references to it, so I won't remove it just yet. But it'd be good to know for sure if and how it's being used there. There's no rush behind its removal, but if it's not being used, that I'd rather we remove it from core.


Image

Endorsements (T155194)

Support (T155194)

  1. Jdforrester (WMF) (talk) 16:21, 6 February 2017 (UTC)[reply]
  2. Quiddity (WMF) (talk) 19:48, 14 February 2017 (UTC)[reply]

Make OOjs UI easier to use for gadgets

Tracked in Phabricator
Task T155567

As I explained in T155473: Improve documentation of OOjs UI

For example when someone wants to make a dialog box in OOjs UI: 

function MyDialog( config ) {
  MyDialog.super.call( this, config );
}
OO.inheritClass( MyDialog, OO.ui.Dialog ); 
MyDialog.static.title = 'Simple dialog';

MyDialog.prototype.initialize = function () {
  MyDialog.super.prototype.initialize.call( this );
  this.content = new OO.ui.PanelLayout( { padded: true, expanded: false } );
  this.content.$element.append( '<p>A simple dialog window. Press \'Esc\' to close. </p>' );
  this.$body.append( this.content.$element );
};
MyDialog.prototype.getBodyHeight = function () {
  return this.content.$element.outerHeight( true );
};
var myDialog = new MyDialog( {
  size: 'medium'
} ); 
var windowManager = new OO.ui.WindowManager();
$( 'body' ).append( windowManager.$element );
windowManager.addWindows( [ myDialog ] );
windowManager.openWindow( myDialog );

(Copied from here).

What I would love to see is some sort of form factory in javascript. Like HTMLFormFactory in php. So we only build an array of form descriptors and call it, then bam! the form is there. Something like: 

windowManager.openWindow( 
  {
    name: 'MyDialog',
    title: 'Simple dialog',
    size: 'medium',
    elements: [
      {
        id: 'panel1',
        type: 'Panel',
        attr: { padded: true, expanded: false }
      },
      {
        tag: 'p',
        text: 'A simple dialog window. Press \'Esc\' to close.',
        parent: 'panel1'
      }
    ]
  }
);

And/or somerhing like jQuery (which can consume existing HTML divs as the source of the dialogue: 

<div id="MyDialog" title="Simple dialog">
  <p>A simple dialog window. Press \'Esc\' to close.</p>
</div>

$( function() {
   $( "#MyDialog" ).dialog();
 } );

Endorsements (T155567)

  1. It affected me personally: I tried to develop a gadget and it was hard to find the right documentation. And it will affect many people very soon: The direction of the development is to gradually replace all editing, in rich-text and in source code, with components based on VE, NWE, and OOJS. This is good, but there are hundreds of gadgets written for the old wikitext editors, and without rewriting those gadgets the transition to NWE cannot happen. Amir E. Aharoni (talk) 13:59, 6 February 2017 (UTC)[reply]

Support (T155567)

  1. Shizhao (talk) 06:57, 6 February 2017 (UTC)[reply]
  2. Ladsgroup (talk) 10:04, 6 February 2017 (UTC)[reply]
  3. Tim Landscheidt 11:37, 6 February 2017 (UTC)[reply]
  4. Jan Dittrich (WMDE) (talk) 12:41, 6 February 2017 (UTC)[reply]
  5. Osnard (talk) 12:54, 6 February 2017 (UTC)[reply]
  6. Amir E. Aharoni (talk) 13:51, 6 February 2017 (UTC)[reply]
  7. SamanthaNguyen (talk) 22:10, 6 February 2017 (UTC)[reply]
  8. — MusikAnimal talk 22:43, 6 February 2017 (UTC)[reply]
  9. Sunfyre (talk) 07:27, 7 February 2017 (UTC)[reply]
  10. Prtksxna (talk) 07:48, 7 February 2017 (UTC)[reply]
  11. Yamaha5 (talk) 09:29, 7 February 2017 (UTC)[reply]
  12. ebrahimtalk 11:36, 7 February 2017 (UTC)[reply]
  13. Chico Venancio (talk) 13:22, 7 February 2017 (UTC)[reply]
  14. Matěj Suchánek (talk) 13:48, 7 February 2017 (UTC)[reply]
  15. Iniquity (talk) 00:29, 8 February 2017 (UTC)[reply]
  16. Tgr (WMF) (talk) 08:52, 8 February 2017 (UTC)[reply]
  17. Tpt (talk) 09:13, 8 February 2017 (UTC)[reply]
  18. FFS Talk 11:01, 8 February 2017 (UTC)[reply]
  19. Trizek (talk) 13:08, 8 February 2017 (UTC)[reply]
  20. Enterprisey (talk) 20:27, 8 February 2017 (UTC)[reply]
  21. — Mr. Stradivarius ♪ talk ♪ 08:36, 11 February 2017 (UTC)[reply]
  22. Helder 14:51, 12 February 2017 (UTC)[reply]
  23. Felipe (talk) 14:11, 13 February 2017 (UTC)[reply]
  24. B20180 (talk) 13:44, 14 February 2017 (UTC)[reply]
  25. Thiemo Mättig (WMDE) 15:38, 14 February 2017 (UTC)[reply]
  26. Framawiki (talk) 17:56, 14 February 2017 (UTC)[reply]
  27. — 0x010C ~talk~ 19:01, 14 February 2017 (UTC)[reply]
  28. Quiddity (WMF) (talk) 19:49, 14 February 2017 (UTC)[reply]

MediaWiki support for Composer equivalent for JavaScript packages

Tracked in Phabricator
Task T107561

We should have an equivalent for JavaScript to what we have with Composer for PHP. A simple way to manage dependencies and install required JavaScript modules automatically.

Problem

  1. Both core and extensions depend upon 3rd party javascript libraries while we currently lack a system to manage those dependencies
  2. Instead, 3rd party libraries get duplicated into—and sometimes across—our repositories.
    • Creates higher code complexity of our own repositories as 3rd party code—with all its flaws—is effectively part of our own code now
    • High effort to manually updating those libraries by copy and paste
    • Some libraries get effectively forked into our repositories while this is not necessary and makes updating/maintaining/reusing them even harder
    • Conflict between MW coding conventions and the pasted libraries ones

Who will benefit

  1. Developers: Development efficiency
    • More predictable and maintainable code due to reduced code complexity
    • Less worries about conflicts across different MW extensions and a simple way to share JS code between them
  2. Security: Simpler to keep an eye on security issues in 3rd party libraries and to deal with them
  3. Possibly, WMF Deployment team.

What we need

  1. We need to settle on a system to track 3rd party javascript libraries. Something similar to composer.json or package.json or extension.json
  2. We need to implement a way to make the selected system scalable and usable for both end users, developers and WMF deploymen
  3. (optional) deduplication of libraries/flattened dependency trees
  4. (optional) predictability of versions used of libraries based on 1. (lock files, shrinkwrap).
  5. (optional) packaging download and update platform (npmjs etc)

Possible solutions

  1. Yarn an NPM compatible client that combines benefits of composer (vendor dir, versioncontract/lock file, package deduplication etc).
  2. Plain NPM for external users and developer, And then build a WMF specific 'vendor' concept on top and other things we need. maybe some CDNJS like system perhaps ?
  3. Specify a structure for how to import libraries into our extensions (RL flag ?), so that it is more clear what we use, what versions they are etc.
  4. Turn JS libraries into composer packages.


Endorsements (T107561)

Support (T107561)

  1. Info-farmer (talk) 05:20, 6 February 2017 (UTC)[reply]
  2. —TheDJ (Not WMF) (talk • contribs) 08:57, 6 February 2017 (UTC)[reply]
  3. Felipe (talk) 13:46, 6 February 2017 (UTC)[reply]
  4. BDavis (WMF) (talk) 16:23, 6 February 2017 (UTC)[reply]
  5. Niedzielski (talk) 19:06, 6 February 2017 (UTC)[reply]
  6. Nikerabbit (talk) 08:03, 7 February 2017 (UTC)[reply]
  7. Cindy.cicalese (talk) 14:11, 8 February 2017 (UTC)[reply]
  8. André Costa (WMSE) (talk) 15:22, 8 February 2017 (UTC)[reply]
  9. Samuele2002 (talk) 18:39, 11 February 2017 (UTC)[reply]
  10. Helder 14:51, 12 February 2017 (UTC)[reply]
  11. Mglaser (talk) 10:18, 13 February 2017 (UTC)[reply]
  12. Sebastian Berlin (WMSE) (talk) 10:21, 13 February 2017 (UTC)[reply]
  13. Strong support. 47.222.203.135 17:54, 13 February 2017 (UTC)[reply]
  14. TerraCodes (talk) 21:02, 13 February 2017 (UTC)[reply]
  15. Phuedx (WMF) (talk) 15:58, 14 February 2017 (UTC)[reply]
  16. Quiddity (WMF) (talk) 19:49, 14 February 2017 (UTC)[reply]

Special:MobileLanguages should be in core and called Special:Languages

Tracked in Phabricator
Task T104660

The mobile skin minimises payload by not serving languages in the page and instead using JavaScript to load other languages or for those without JavaScript a special page fallback

The parameter given to the page is the page to retrieve languages from. For example: https://en.m.wikipedia.org/wiki/Special:MobileLanguages/San_Francisco

This should be in core in some form so it can be used by other skins.

This is one of many non-standard language selectors which need to be consolidated; see also T73136: Improve language selection.

Endorsements (T104660)

Support (T104660)

  1. Liuxinyu970226 (talk) 08:07, 6 February 2017 (UTC)[reply]
  2. —TheDJ (Not WMF) (talk • contribs) 08:56, 6 February 2017 (UTC)[reply]
  3. Amir E. Aharoni (talk) 14:00, 6 February 2017 (UTC)[reply]
  4. Jdforrester (WMF) (talk) 16:22, 6 February 2017 (UTC)[reply]
  5. Jdlrobson (talk) 01:02, 7 February 2017 (UTC)[reply]
  6. Nikerabbit (talk) 08:04, 7 February 2017 (UTC)[reply]
  7. Smalyshev (WMF) (talk) 02:24, 10 February 2017 (UTC)[reply]
  8. Samuele2002 (talk) 18:40, 11 February 2017 (UTC)[reply]
  9. TerraCodes (talk) 21:02, 13 February 2017 (UTC)[reply]
  10. Quiddity (WMF) (talk) 19:49, 14 February 2017 (UTC)[reply]

Deploy Sentry (JavaScript error logging) to production, configured to log only a limited subset of users/pages

Tracked in Phabricator
Task T91649

Noticing, tracking and debugging errors should be easy. Wikimedia developers and users should be able to easily notice new errors (possibly only a subset of them that they are interested in), find out details, and share with others. At the same time security and privacy standards should be enforced.

Sentry is the most popular open-source software for error logging and aggregation; we should use it to (initially) collect errors from logged-in users (maybe leaving out the largest wikis, if the high traffic is problematic - those wikis are usually better at noticing problems quickly anyway) and/or errors on some specific pages with smaller traffic and more problematic history (e.g. Special:UploadWizard).

Endorsements (T91649)

  1. JavaScript errors in local gadget, user scripts, and Common.js customization is one of the most frequent causes of trouble in smaller wikis. It even happened in the Japanese Wikipedia, which is a top-ten Wikipedia—several features were quietly broken for weeks for hundreds of editors because of an error in a gadget, and it was only by a developer who could fix it thanks to a user who complained about a broken feature. There should be more proactive monitoring for this. Amir E. Aharoni (talk) 14:02, 6 February 2017 (UTC)[reply]

Support (T91649)

  1. Amir E. Aharoni (talk) 14:00, 6 February 2017 (UTC)[reply]
  2. BDavis (WMF) (talk) 16:24, 6 February 2017 (UTC)[reply]
  3. Santhosh.thottingal (talk) 03:35, 7 February 2017 (UTC)[reply]
  4. Nikerabbit (talk) 08:03, 7 February 2017 (UTC)[reply]
  5. Helder 14:51, 12 February 2017 (UTC)[reply]
  6. 47.222.203.135 17:54, 13 February 2017 (UTC)[reply]
  7. TerraCodes (talk) 21:03, 13 February 2017 (UTC)[reply]
  8. Quiddity (WMF) (talk) 19:50, 14 February 2017 (UTC)[reply]

Set $wgLegacyJavaScriptGlobals = false by default

Tracked in Phabricator
Task T35837

Per ResourceLoader Migration guide, there are plans to set $wgLegacyJavaScriptGlobals to false and remove the global JavaScript variables (such as wg*).

I'm opening this bug (similar to T35836: Set $wgIncludeLegacyJavaScript = false by default) mostly for tracking the progress on this regard.

If anyone knows if this is already scheduled to be done in some specific future version of MediaWiki, please inform us below.

See Also:

Endorsements (T35837)

Support (T35837)

  1. Jdforrester (WMF) (talk) 16:22, 6 February 2017 (UTC)[reply]
  2. Ricordisamoa 11:18, 8 February 2017 (UTC)[reply]
  3. Helder 14:51, 12 February 2017 (UTC)[reply]
  4. B20180 (talk) 13:46, 14 February 2017 (UTC)[reply]
  5. Quiddity (WMF) (talk) 19:51, 14 February 2017 (UTC)[reply]

A cached server-side HTML template should update when you change a partial template which it includes

Tracked in Phabricator
Task T113095

https://gerrit.wikimedia.org/r/#/c/223165/ has a top-level template Skin.mustache that includes the partial template sidebar.mustache using {{>sidebar}}.

I notice on my local wiki if I edit Skin.mustache and view a page with the skin, I see the change to it (good!), but if I edit the partial sidebar.mustache, I don't see the change to it, even if I use ?action=purge (bug!).

Looking at includes/TemplateParser.php in core, it does a simple 

// Read the template file
$fileContents = file_get_contents( $filename );

// Generate a quick hash for cache invalidation
$fastHash = md5( $fileContents );

this doesn't notice changes to partials included by $filename.

(This is probably hard to fix. A workaround is to make cosmetic changes to all parent templates that include the edited partial template. The bug and workaround is documented in https://www.mediawiki.org/wiki/Manual:HTML_templates#Caching.)

Endorsements (T113095)

Support (T113095)

  1. —TheDJ (Not WMF) (talk • contribs) 08:58, 6 February 2017 (UTC)[reply]
  2. Bmansurov (WMF) (talk) 14:28, 6 February 2017 (UTC)[reply]
  3. [[kgh]] (talk) 23:26, 6 February 2017 (UTC)[reply]
  4. Calexit (talk) 21:49, 9 February 2017 (UTC)[reply]
  5. Osnard (talk) 11:33, 13 February 2017 (UTC)[reply]

Dismantle ResourceLoader's "targets" system

Tracked in Phabricator
Task T127268

Endlessly discussed and griped about but apparently there's no task.

This system is carelessly leaving behind a trail of maintenance overhead. With new issues popping up all the time. Here's a quick sample just from MediaWiki core (quick Resources.php search for "target" and "mobile").

Endorsements (T127268)

Support (T127268)

  1. ThurnerRupert (talk) 12:06, 6 February 2017 (UTC)[reply]
  2. Felipe (talk) 13:47, 6 February 2017 (UTC)[reply]
  3. Amir E. Aharoni (talk) 14:03, 6 February 2017 (UTC)[reply]
  4. Jdforrester (WMF) (talk) 16:22, 6 February 2017 (UTC)[reply]
  5. Krinkle (talk) 19:34, 6 February 2017 (UTC)[reply]
  6. — MusikAnimal talk 22:44, 6 February 2017 (UTC)[reply]
  7. Santhosh.thottingal (talk) 03:35, 7 February 2017 (UTC)[reply]
  8. Nikerabbit (talk) 08:04, 7 February 2017 (UTC)[reply]
  9. FFS Talk 11:03, 8 February 2017 (UTC)[reply]
  10. Edward Chernenko (talk) 22:22, 9 February 2017 (UTC)[reply]
  11. Osnard (talk) 11:34, 13 February 2017 (UTC)[reply]
  12. Quiddity (WMF) (talk) 19:52, 14 February 2017 (UTC)[reply]

[jsduck] Various custom tags should be easily shareable between projects

Tracked in Phabricator
Task T86587

Recently we introduced the jsduck see tag in MobileFrontend [1], which isn't part of the vanilla jsduck. Actually we need to add a customTag our self [2] to use it without warnings from jsduck. The feature request for jsduck [3] isn't implemented at the moment and there is no roadmap for it (as i can see).

VisualEditor itself (like mentioned by Krinkle on the feature request) uses a set of custom tags [4] and there are other projects using this (and other) custom tag(s), too (core, VE and GuidedTours). It would be possible to use cores CustomTags.rb in jsduck, but with it it wouldn't be easy to share custom tags introduced in VE or MF, e.g.. So it would be great to have a central repository (e.g. a git project in gerrit) to manage tags used in wmf projects to simply clone it (maybe integrate it as a submodule) into the project (or a seperate directory) and use it. An update of a tag or new tags could be used without any problems by updating the local copy of the repo.

  1. ↑ https://gerrit.wikimedia.org/r/#/c/182968/
  2. ↑ https://gerrit.wikimedia.org/r/#/c/184405/
  3. ↑ https://github.com/senchalabs/jsduck/issues/558
  4. ↑ http://git.wikimedia.org/blob/mediawiki%2Fextensions%2FVisualEditor.git/213c0a2367a3a2c4555ea39401e914e741ffd505/.docs%2FCustomTags.rb

Endorsements (T86587)

Support (T86587)

  1. David1010 (talk) 06:42, 6 February 2017 (UTC)[reply]
  2. Jdforrester (WMF) (talk) 16:22, 6 February 2017 (UTC)[reply]
  3. B20180 (talk) 13:43, 14 February 2017 (UTC)[reply]

meta=siteinfo&prop=langlinks should identify RTL languages

Tracked in Phabricator
Task T74153

https://en.m.wikipedia.org/w/api.php?action=query&format=jsonfm&meta=siteinfo&siprop=general%7Clanguages&prop=langlinks&llurl=true&lllimit=max&titles=Tofu

This returns language names and article titles in many languages (which is used to construct a language switcher interface on the mobile web interface). To do that properly, mobile we need to identify which languages are RTL and which are not.

Expected: Return an rtl property when a language is RTL.

Endorsements (T74153)

Support (T74153)

  1. Liuxinyu970226 (talk) 08:08, 6 February 2017 (UTC)[reply]
  2. Amir E. Aharoni (talk) 14:03, 6 February 2017 (UTC)[reply]
  3. [[kgh]] (talk) 23:27, 6 February 2017 (UTC)[reply]
  4. Jdlrobson (talk) 01:02, 7 February 2017 (UTC)[reply]
  5. Santhosh.thottingal (talk) 03:36, 7 February 2017 (UTC)[reply]
  6. Sunfyre (talk) 07:33, 7 February 2017 (UTC)[reply]
  7. Nikerabbit (talk) 08:05, 7 February 2017 (UTC)[reply]
  8. Yamaha5 (talk) 09:27, 7 February 2017 (UTC)[reply]
  9. Smalyshev (WMF) (talk) 02:25, 10 February 2017 (UTC)[reply]
  10. Recommend dir=ltr / dir=rtl for completeness. 47.222.203.135 17:54, 13 February 2017 (UTC)[reply]
Retrieved from "https://www.mediawiki.org/w/index.php?title=Developer_Wishlist/2017/Frontend&oldid=2397340"