User:Waldyrious

Waldir@meta.wikimedia

Projects

• MediaWiki documentation (especially reference, index-like ones)
• MediaWiki skins
• Potential bugs for hacking sessions
• Plans/notes of my participation in Wikimedia Hackatons (some of these may be useful for guiding future work)
• Notes on using Toolforge (previously Toolserver)

Installation

• includes/installer, mw-config, maintenance/install.php (Manual:install.php), Manual:Installing MediaWiki, INSTALL
• Using maintenance/install.php (TODO: test and confirm the parameter values; add some documentation to the file itself, as comments, and to its Manual entry):

  Step 1:
  rm -rf LocalSettings.php database/* && mkdir -p database/ && chmod a+w database/

  Step 2:
  php maintenance/install.php [wikiname] [username] --pass=[password] --dbtype=sqlite --dbpath=database/

• See also: MediaWiki-Vagrant
• https://bitnami.com/stack/mediawiki

Useful stuff

• Writing an extension for deployment
• http://shorturls.redwerks.org (see Manual:Short URL)
• Manual:JS/API/UI Extension Developer Library
• Git/TLDR and PHPunit/TLDR
• investigate withJS url param (possibly only enabled in commons, i.e. not a mediawiki feature)
• Lua: slideshow, tutorial
• Check commons:MediaWiki:Gadget-Hotcatcheck.js (also Cat-a-lot) for direct, non-refresh, no-edit-view editing
• patch that enabled direct linking to diffs: 63395
• Help:CirrusSearch for documentation on search operators/prefixes.
  • insource: for searching in wikicode rather than rendered text
• Subscribe to patches in Gerrit to review: Git/Reviewers
• Customizing the WikiEditor toolbar: adding new buttons (Krinkle's more convenient alternative)
• Parameters for URL address bar:
  • ?safemode=1 to load the page without gadgets/common.css/common.js (src)
  • ?uselang=xx to load the page using the given language as the MediaWiki interface. Use the special value qqx to display the name of the interface messages instead.
• For finding things in the API, open api.php?action=help&recursivesubmodules=1 and search that page using the browser's search function (Ctrl+F)

Wikicode markup

• Parsers
  • Parsoid, in particular Parsoid/Parser Unification
  • Alternative parsers
  • Manual:Parser#History
• Editors
  • Extension:WikiEditor (aka 2010 wikitext editor)
  • 2017 wikitext editor (integrated with VisualEditor, shown in source editing mode)

API + JavaScript (client-side apps)

• API:Client code#JavaScript and API:Client code/All#JavaScript. Some interesting options that are usable in-browser:
  • Conrad.Irwin/JsMwApi
  • lucaswerkmeister/m3api
  • brettz9/mediawiki-js
• API:Data formats#JSON callback restrictions and Manual:Ajax#Limitations
• Bug 20814 (fixed) - Enable $wgCrossSiteAJAXdomains for wikimedia sites (only WMF wikis allowed to make AJAX requests to each other)
• bugzilla:19907#c14 -- "For non-credentialed requests, we can send Allow-Origin: *" -- i.e., for actions that don't require login, allow third-party apps
• Could w:Cross-document messaging help here?
• Thread:Talk:Requests for comment/API Future/CORS and third-party web apps
• bug 62807 - Create TODO list for best MediaWiki API client library in JavaScript
• Getting HTML fragments via the API
  • The old API does not support HTML as a response format. It supports action=parse&prop=text, and even allows adding e.g. &section=3 to get only the contents of the third section of the page, but the output is an HTML string wrapped in a JSON object.
  • The new REST API does HTML responses, but apparently only for entire pages (docs), not for e.g. individual sections.
  • This might allow using HTMX (which expects HTML responses, and does so out of principle) to build low-JS apps.
• From Lucas Werkmeister's blog post about the Wikimedia Hackathon 2023:
  • One of my first achievements was to get a Gerrit change merged: I had uploaded Add Authorization to default $wgAllowedCorsHeaders the previous week, and found some people at the hackathon to review it: Reedy and Legoktm. The intention here was to make it possible to have purely client-side (in-browser) web apps that interact with Wikimedia wikis using OAuth 2.0 (e.g. making edits), which requires making CORS-enabled authenticated requests. Unfortunately, this still doesn’t work; in addition to the Gerrit change mentioned above, we probably need to tweak the way the API processes the origin parameter a little bit – I’ll keep looking into this issue. (You can find the example web app I’m trying to make work on GitHub already.)

Developers

• Developers/Accounts
• Special:Code/MediaWiki/author
• http://toolserver.org/~krinkle/TSUsers.php
• http://toolserver.org/~krinkle/wikimedia-svn-users.php
• http://korma.wmflabs.org/browser/contributors.html
• Gerrit watchlist:
  • === mediawiki/core ===\n* {{Gerrit-reviewer|Waldir|file_regexp=<nowiki>^skins|^includes/installer|patrol|docs|MessagesPt.php|match_all_files}}</nowiki>
  • === mediawiki/extensions/Configure ===\n* {{Gerrit-reviewer|Waldir}}
  • === mediawiki/extensions/skins ===\n* {{Gerrit-reviewer|Waldir}}
  • === mediawiki/extensions/TextExtracts ===\n* {{Gerrit-reviewer|Waldir}}
  • === mediawiki/extensions/Theme ===\n* {{Gerrit-reviewer|Waldir}}
  • === mediawiki/extensions/ThemeDesigner ===* {{Gerrit-reviewer|Waldir}}
  • === mediawiki/skins ===\n* {{Gerrit-reviewer|Waldir}}

Languages and internationalization

• Localisation
  • Central hub with various links
• Manual:MediaWiki architecture#Languages
  • High-level overview of localization in MediaWiki
  • Subsection §Localizing messages is outdated, as it still refers to the MessagesXx.php files.
• Manual:Language
  • Another high-level overview of localization in MediaWiki
  • Section §Names.php is short but very informative:

    Names.php is the master registry of languages supported by MediaWiki. This is not the same as languages of which MediaWiki will show l10n (JSON files) nor languages of which MediaWiki knows the names (via CLDR ), mind you!

• Manual:Code#languages/
  • Explains the contents of the languages/ directory of MediaWiki
  • Appears to be slightly outdated, since there's no longer a classes/ subdirectory, and instead there's a data/ subdirectory that isn't described.
• Manual:Messages API
• Help:System message
  • Section §Localisation file format, is particularly useful, as it offers historical context of how the format evolved over time.

Misc.

• WikiOverflow (deleted), Wikis@SE (deleted), MediaWiki IdeaTorrent (deleted; thread 1, thread 2). Also, according to my analysis at w:Talk:OSQA, a potential platform for this sort of thing could be w:Askbot.
• It could be interesting to make diffs flattrable. See Extension:Flattr.
• For code review in gerrit, it would be nice to have a query url that shows only changes that haven't been reviewed before (in the "my changes" view, the CR column is often empty but there's already been a lot of discussion before, but a new patch reset the CR scores). Something like https://gerrit.wikimedia.org/r/#/q/reviewer:self+status:open+-is:reviewed,n,z should work, but according to the docs it covers both Code-Review and Verified scores, and the latter is pretty much always there as it's added by Jenkins, so the query shows nothing. One can build a query to show specifically patchsets with no Code-Review score, but that still doesn't fix the "previous discussion" issue above, which would enable one to find patchsets that haven't received any external feedback since being submitted. As an alternative to find unloved patches, one can amend that search query to show patchsets whithout CR that are over a year old (there are four such ones at the time of writing). Another approach is to limit to those who don't have a +2'er in the reviwers, by using -reviewerin:mediawiki in the query (the docs say reviewerin matches changes that have been, or need to be, reviewed by a user in the specified group).
  • Update: Krinkle on IRC says: the gerrit query command line API over ssh might have a way to filter for such things. Ask hashar or Reedy maybe next time they're on.
• History of MediaWiki version control (see also MediaWiki history and Git/Conversion). Commits graph @ Ohloh. Commits graph @ GitHub (empty before 2009-11-14 although the graph does go all the way back to 2003-04-13, how come?).
• Since gerrit:921379 it is possible to set wgSVGNativeRendering to make MediaWiki render SVGs natively
  • Reasons why we might not want to activate it:
    • Font rendering (positioning, presence of glyphs for less popular languages, etc.)
    • Non-guaranteed proper SVG rendering by the user's browser