morebits: Use new error formats (default to html) in api; use $.parseHTML in status messages #1179
Conversation
Amorymeltzer
added
Feature request
Other wikis
Amorymeltzer
changed the title
|
Presumably there are places that could be simplified by making use of the 1st commit, but I've not done a survey and might as well leave well-enough alone atm. But block and protect for sure. |
|
Well, this was part of the plan in #1144, though I was more of expecting to rewrite Morebits.status with fancy StatusLine and StatusBlock classes. I would bat for |
That CSS should be removed. sans-serif is I think the default font on mediawiki, so there's no need to specify it. Even if it were different for someone, I don't see why it needs to be adjusted away from that choice. |
I can never keep track of these! But, this is for messages being passed to the Twinkle user, not ever being added to the wiki. The content in the Twinkle interface is... well, it's all
Jah, but figured OoS for this. IIRC from minor testing, it was basically just the select menus that would/could be affected: without this, they'd inherit from the skin, so Modern/Timeless would look different (slightly bigger). Don't think it's a big deal, but didn't look too much into it. |
In theory yes, but in practise, that's hopelessly complicated to work out. There could be situations where one could want to have a tooltip say "for xxx purposes use {{other template name}} instead". Here the "other template name" obviously has to be based on the content language, but the message itself should be in user language? You see, using one language for the UI and another for editing is a lost cause. My i18n plans (assuming they approve the grant) have been to use content lang for everything. |
Defaults to `html`, but `plaintext` and `wikitext` are acceptable; `raw`, `none`, and the legacy format `bc` will be converted to `html`. Currently limited to the first error found, which was the case with the old syntax and is assumed by our uses of `errorCode`/`errorText`. Of note, this also defaults all queries to the wiki's `content` language, see discussion in wikimedia-gadgets#1179. https://www.mediawiki.org/wiki/API:Errors_and_warnings
Amorymeltzer
force-pushed
the
morebits-errorformat
branch
from
45213b6
to
1c74c0d
Compare
|
That's a real good point — ugh! Done and done! |
Defaults to `html`, but `plaintext` and `wikitext` are acceptable; `raw`, `none`, and the legacy format `bc` will be converted to `html`. Currently limited to the first error found, which was the case with the old syntax and is assumed by our uses of `errorCode`/`errorText`. Of note, this also defaults all queries to the wiki's `content` language, see discussion in wikimedia-gadgets#1179. https://www.mediawiki.org/wiki/API:Errors_and_warnings
Amorymeltzer
force-pushed
the
morebits-errorformat
branch
from
1c74c0d
to
2079237
Compare
Inserting and rendering HTML was always possible in `Morebits.status`, since `codify` would simply append an Element if present, but while providing an HTMLElement would work as expected a text string of HTML would be treated as just that: a text string. In theory, assigning each node's `innerHTML` would work, but (as structured) we'd have to do it separately, since `Morebits.status`' `text` (first parameter, before colon) and `stat` (second parameter, after colon) have their `document-fragment` HTML built/added separately, in `.generate` and `.render`, respectively. Moreover, it would make for poor console warning/error messages, since we had `text` and `textRaw` but just `stat` (in fact, we've been using `status` instead of `this.stat` since 2013 (26c3add)). Instead, this modifies `codify` to `$.parseHTML` any strings passed it and append the subsequent Element(s). Should make rendering HTML in status messages simpler and more straightforward. This could, of course, have all sorts of side effects, although I think the likelihood is rather small, given that people don't generally have a desire to show raw HTML text in an output. Of note, however, is that, since we're using `$.parseHTML`, we're of course parsing *HTML* and not *wikitext*. Parsing a wikitext link into an HTML link isn't too tricky, something like works: ```javascript var link = document.createElement('a'); link.setAttribute('href', mw.util.getUrl(page)); link.appendChild(document.createTextNode(title)); ``` Of course, that's assuming we have the wikilink we want, and not just a blob of wikitext. We could use regex to pull things out, something like `/\[\[([^\]\|]+)(?:\|([^\|\]]+))?\]\]/`, and parse individually, but the more "proper" way is probably using `Morebits.unbinder` or something; something perhaps for `Morebits.wikitext.page` to learn. One more note: because morebits.css has ```css form.quickform * { font-family: sans-serif; } ``` any status elements that would be expected to affect `font-family` won't work properly. In particular, things like `<pre>`, `<kbd>`, and `<code>` won't display with `font-family: monospace`, as may be desired/expected, until/unless morebits.css is changed. Required adding `Element` to the repl testing.
Defaults to `html`, but `plaintext` and `wikitext` are acceptable; `raw`, `none`, and the legacy format `bc` will be converted to `html`. Currently limited to the first error found, which was the case with the old syntax and is assumed by our uses of `errorCode`/`errorText`. Of note, this also defaults all queries to the wiki's `content` language, see discussion in wikimedia-gadgets#1179. https://www.mediawiki.org/wiki/API:Errors_and_warnings
Amorymeltzer
force-pushed
the
morebits-errorformat
branch
from
2079237
to
445098a
Compare
In #1179, support for new error formats were added and used by default. However, the error handling code still assumes the legacy errorformat, which passes details of the first `error`, while in the newer ones we have an array `errors`.
In #1179, support for new error formats were added and used by default. However, the error handling code still assumes the legacy errorformat, which passes details of the first `error`, while in the newer ones we have an array `errors`.
2nd commit uses/enforces the newer API error messages in
Morebits.wiki.api, defaulting tohtml, but allowingplaintextandwikitext;raw,none, and the legacybcwill be converted tohtml. Provideserrorlang: mw.config.get('wgUserLanguage'). Errors are limited to the first found, which was the case with the old syntax and is assumed by our uses oferrorCode/errorText, but maybe something to refactor at some point (not a huge gain IMO).The 1st commit enables the html showing up nicely, by using
$.parseHTMLinMorebits.status.codify(). There's a whole long commit message, but the tl;dr is: it will now automatically parse html, not wikitext; and there's now astatRawfor error logging.