| IKhitron | |
| Sep 27 2023, 7:25 PM |
| F37835309: image.png | |
| Sep 28 2023, 11:55 PM |
| F37835248: image.png | |
| Sep 28 2023, 11:55 PM |
| F37835241: image.png | |
| Sep 28 2023, 11:55 PM |
| F37835238: image.png | |
| Sep 28 2023, 11:55 PM |
| F37835136: Screenshot_1.png | |
| Sep 28 2023, 10:21 PM |
| F37835104: Screenshot_2.png | |
| Sep 28 2023, 10:21 PM |
| F37835098: WikiEditC.png | |
| Sep 28 2023, 10:21 PM |
Hi. I think it should be "Unbreak now!".
Does not happen using other language interface with uselang.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Release | dduvall | T345889 1.41.0-wmf.28 deployment blockers | ||
| Resolved | BUG REPORT | matmarex | T347522 Page difference title is not parsed any more. |
Thanks for reporting. This is caused by rMW111d9177af56: Use OutputPage::setPageTitleMsg() instead of ::setPageTitle().
The issue only affects wikis that override MediaWiki:Difference-title, for example here on he.wp: https://he.wikipedia.org/w/index.php?title=מדיה_ויקי:Difference-title&action=edit
We need to see how common it is, and why it was done, and then either restore the ability to use HTML in that message, or propose an alternative solution. I'll have a look.
he.wp is the only affected project: https://global-search.toolforge.org/?q=.*®ex=1&namespaces=8&title=Difference-title
(there's also something weird going on at nv.wp, but I think they have bigger problems…)
The <span> is local customisation in https://he.wikipedia.org/wiki/%D7%9E%D7%93%D7%99%D7%94_%D7%95%D7%99%D7%A7%D7%99:Difference-title?action=edit&uselang=en
Parsing of the message changed in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/947894 from text() to escaped() (both with call to Sanitizer::removeSomeTags)
It was done because the community wanted different version from that on translatewiki.
I searched like this: https://he.wikipedia.org/w/index.php?search=insource%3A"difference-title"&title=מיוחד:חיפוש&profile=all
It looks like the customization is only needed for this gadget: https://he.wikipedia.org/wiki/מדיה_ויקי:Gadget-browsertab.js#L-65
if ($('.difference-title').length)
As far as I can tell, it's only checking for the existence of this element to detect whether it's on a diff page.
This could be implemented like this instead:
if (mw.config.get('wgDiffOldId') && mw.config.get('wgDiffNewId'))
(documented here: https://www.mediawiki.org/wiki/Manual:Interface/JavaScript#Some_pages)
And then you wouldn't need to customize the localisation message.
@IKhitron How does this sound?
Waiting for results a couple of minutes. But it is not the only difference from the original. The is also an – instead of :. Do you want me to suggest to the community to change it back, if the gadget will work, to fix this bug? I can fix this now ahead, and start a discussion. But I must change it again, if the comminity will decide against the colon.
Oh, you can keep an override for 'Difference-title' that changes the text as you like – you just can't use HTML or wikitext markup in it any more. Sorry for not being clear about that.
Ah, very good. Well, ten minutes later, looks like it works. I'll tell here if I'll see problems with the gadget in the future. For now I suggest to remove the html code from the message, and if it will be fixed as expected, to close the task. What do you think?
Affected message keys from the patch
accmailtitle accountcreated actioncomplete actionfailed allarticles allinnamespace all-logs-page api-format-title api-help-title autoblocklist blockipsuccesssub blocklogpage cannotdelete-title changecontentmodel-success-title creating deletedcontributions-title dellogpage difference-title difference-title-multipage editing emailsent errorpagetitle importlogpage internalerror ipblocklist listfiles listfiles_subpage login-security log-name-abusefilterblockeddomainhit log-name-contentmodel log-name-create log-name-flow log-name-gblrename log-name-interwiki log-name-managetags log-name-massmessage log-name-messagebundle log-name-newsletter log-name-notifytranslators log-name-pagelang log-name-pagetranslation log-name-pagetriage-copyvio log-name-pagetriage-curation log-name-renameuser log-name-spamblacklist log-name-tag log-name-thanks log-name-timedmediahandler log-name-titleblacklist log-name-translationreview log-name-translatorsandbox log-name-urlshortener markedaspatrolled markedaspatrollederror mergelog movelogpage move-page pagemovedsub patrol-log-page prefixindex prefixindex-namespace protectlogpage protect-norestrictiontypes-title protect-title protect-title-notallowed recentchangeslinked-title rightslog rollbackfailed searchresults suppressionlog tags-activate-title tags-deactivate-title tags-delete-title tags-title unblockip undelete-error undeletepage undelete-search-title uploadlogpage version-credits-title version-license-title viewdeletedpage viewsource-title watchlistedit-clear-title watchlistedit-normal-title watchlistedit-raw-title whatlinkshere-title
Potentially affected overrides:
(too many titles to search in one go… I've never seen that error before)
Wait, @matmarex. People react to this and say there are more problems here, in Firefox only. I've asked to come here and to describe them.
I see very similar results on Wikidata (e.g. https://www.wikidata.org/w/index.php?title=Q855117&diff=1963767055), except that it’s not a MediaWiki message override that sets it, but something in Wikibase. It affects the <title> (browser tab title) in addition to the <h1>. It has the same root cause, doesn’t it?
@matmarex, checking in prior to all wiki deployment. Do you know what the impact would be at this point for group2 wikis? Should I hold the train until this is fully resolved?
@dduvall I think it is resolved, I reopened it while waiting for someone to expand on T347522#9204852. But since no one did, it's probably working correctly now. @IKhitron If you or anyone else is still seeing this problem, let us know and I'll look into it.
@Tacsipacsi Yes, looks like that's now filed as T347578: HTML tags in Entity diff title. (which only affects Wikidata)
I reviewed them all, and made the following edits to the affected ones:
I am not sure if it's the same problem, but since I was directed to here I will write it here:
As noted, I am using Firefox.
The font for Hebrew text has changed this Wednesday in the difference page and also in edit-source mode. The new font looks smaller and is harder to read, especially when working with nikud (Hebrew diacritics).
Here is a screenshot of the edit screen from before the changes (source):
Here is a screenshot of the same page right now:
Compare for example the 7th word (התהוו): with the previous font, it's pretty easy to tell that the first and third letters are ה, and the second letter is ת. With the new font, it's much harder to tell these letters apart.
I couldn't find an existing screenshot of an edit screen containing nikud, but here is how it looks right now:
Again, all of these screenshots were taken in Firefox. The font also slightly changed in Chrome, although the change is less noticeable, and while I do find the new font in Chrome slightly harder to read, it's much better than what we have in Firefox.
@MichaelT This is definitely not related to the problem with the page titles, but I promised I'll look into it, so… :) Let me start by saying I can't speak or read Hebrew.
Our test page is apparently https://he.wikipedia.org/w/index.php?title=יהדות&action=edit§ion=22
I get completely different fonts on different browsers myself:
| Firefox | Chrome |
|---|---|
 |  |
My Chrome looks very similar to your old (good) font. It is apparently using Times New Roman for the Hebrew text, and Consolas for the English text and special characters, which I found in the browser developer tools here:
My Firefox looks completely different, possibly even worse than yours. It is using Courier New for the Hebrew text, which I found in the browser developer tools here:
I'm not sure what font is being used for you (you could follow the steps above to find out), but it is also a fixed-width (monospace) font like Courier New. Note how all the characters (Hebrew, English and special) are arranged on a grid, with the same width used for each one.
MediaWiki edit fields are actually supposed to use a monospace font by default. It seems you never had a monospace font installed that could display Hebrew text, so your browser was using whatever it could find, which was Times New Roman. I am pretty sure that the fonts used by MediaWiki have not changed recently, so on Wednesday you must have gotten some browser or operating system update, that installed or changed your fonts, so that now you have a monospace font that can display Hebrew. It just turns out to be an ugly one…
You can pick a different font though! Try going to Preferences → Editing, and under "Edit area font style" ("הגופן בתיבת העריכה"), change it from "Monospaced font" to "Serif font" or "Sans-serif font". Note that this will affect English text as well, but I hope that on Hebrew Wikipedia that is acceptable.
If that doesn't result in something readable (for me, it somehow always results in Arial, which isn't even a serif font), you can override the font in your common.css, using something like this:
.mw-editfont-monospace, .mw-editfont-sans-serif, .mw-editfont-serif { font-family: "times new roman"; font-size: 14px; }
It may not be possible to get the exact mish-mash of two fonts that you had before, though (unless you figure out what system update changed it, and uninstall it somehow). In CSS we can only specify the preferred font, and what ends up actually displayed depends on what's available on your computer.
Based on your results, I tried installing the previous version of Firefox and the problem went away, so it is actually a problem on my end.
Turns out Firefox v119 uses "Rod" font, while Firefox v118 used "Consolas" and "Miriam Fixed" fonts, though I am not sure what changed - the browser's default font for "monospace" is "Miriam Fixed" in both versions. Either way, It's not a problem with MediaWiki.
Thanks for taking your time to explain!