User:DavidL/New wishlist

From mediawiki.org

User page on meta without deleting local page[edit]

Currently a user can create a user page on meta which is visible on every other projects where there is no user page. User have to ask administrators for deleting local user page when it exists to display the global meta user page.

Problems:

  • Administrators can see the following message (example) at top of user page:
    • (en) "View or restore 30 deleted edits? (view logs for this page | view abuse log)"
    • (fr) « Désirez-vous afficher ou restaurer 30 modifications effacées ? (afficher les journaux pour cette page | voir le journal des abus) »
    This is a difference (for administrators) with page that never existed locally, and user may not want this special message be visible.
  • Response time from administrators may be long on wiki projects with few activities.

Solution:

  • Display the meta user page when user page is empty or only contains an hyphen.
    This would avoid administrators actions (deleting or restoring) on local user pages.

Server cache update for project CSS/JS is highly too long[edit]

Currently when modifying project CSS/JS we have to wait for at least 5 minutes, up to 30 minutes before server updates its cache.

  • It's not a browser cache problem: clearing or explicit refresh (F5, Ctrl+F5, ...) on the CSS/JS wikipage and content wikipages have no effect.
  • action=purge have no effect (on the CSS/JS wikipage and content wikipages).

Problem:

  • Server cache refresh delay is too too too ...(5 to 30 minutes writing "too") long.

Image cache update is too long[edit]

When new version of picture is uploaded to commons, only wikipedia get updated immediatly. Other project needs to wait or purge page using it to get the new version.

Update should be done immediatly for every projects; wikipedia should not be favored.

Relative links resolution in templates[edit]

Currently a template (any wiki page in fact) may include relative links both to avoid typing too long hierarchies of pages (particularly on wikibooks projects) and to have independence from book renaming.

Problem:

  • When template or page (ex: wikibooks including content page from all book chapters in printable version), links are resolved from the page using the template, not from the template. This gives a different result: a list of red links.

Solution:

  • When path doesn't use any variable (like {{PAGENAME}}, {{BASEPAGENAME}}, {{ROOTPAGENAME}}), resolve relative links when page is created and modified, from the page itself, not from the page including it.
  • For specific usages where template defines a relative link from page using it, it should be possible to use . and .. anywhere in the path.
    For example: {{PAGENAME}}/../Authors

Improve Lua module editing[edit]

Problem: When creating Lua module with syntax error, module cannot be saved and a useless error message (like missing 'end' somewhere) doesn't help localize the true syntax error or fixing it. Also Preview is not available, so we do not have syntax coloration to see error.

Solution: Provide a Preview button to see code with syntax coloration to help debugging syntax error, and improves error messages like saying when literal string are not closed instead of "missing end" somewhere in the code.

Workaround: Create the module talk page with code between <syntaxhighlight lang="lua"> and </syntaxhighlight> to see syntax coloration.

Don't convert SVG to PNG[edit]

Problem: Currently, when an SVG image is used in wiki pages, Mediawiki convert it into PNG. But conversion outputs a bad quality PNG image: gray/transparent borders around the image, text not rendered as expected (wrong font, wrong size at some scale).

Solution: Don't convert SVG image, just let the browser managing rendering SVG directly. Browsers support SVG since many years: https://caniuse.com/svg

Workaround: Use a PNG image when alternative exists.

Improve performance and highly raise limits[edit]

Problem: On wikibooks projects, a printable or PDF version of books should be downloadable. There was such feature on wiki project, but having some bugs. Bugs were never fixed and feature was abandoned.

Workaround would be to make one printable version page including all book chapters, and then print it or generate a PDF file from it. But MediaWiki has a limit of 2,097,152 bytes (2MB) for total page inclusion bytes, which is too low for books.

Solution: Improve MediaWiki performance and highly raise limits.

Incoherent table HTML generation[edit]

Problem: When creating tables in wiki, the generated HTML put header rows in <tbody> instead of <thead>, unless CSS classes include "sortable".

Solution: Put header rows in <thead> even if table is not sortable.