Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Page MenuHomePhabricator

Respect the proper enumeration of backlinks - use language agnostic as default
Closed, ResolvedPublicBUG REPORT

Description

Some locals/communities would prefer backlinks with numbers (1.1, 1.2), some prefer with lower alpha (1.a, 1.b), roman, greek and many others.

It seems like numbers (1.1, 1.2) is the right default for English and in general (as language agnostic).
The 2 reasons I would like to address it now:

  • There is a TODO in ext cite to remove the lower alpha from the extension and move it to enwiki CSS. Snippet from code:
/* Temporary: This is enwiki specific.
 * Need this for b/c till we add this to enwiki's Mediawiki:Common.css */
  • It badly affect other locals - for instance Hebrew Wikipedia loads and English style, although Hebrew is non latin language. Snippet from code why it happens:
// Get the content language code, and all the fallbacks. The first that
// has a ext.cite.style.<lang code>.css file present will be used.

I decided it is better to fix it from the root rather than hacking a specific Hebrew workaround.

Steps to replicate the issue (include links if applicable):

  • Open any page for editing in Visual Editor
  • Add a reference twice (so it will have 2 backlinks)

What happens?:

  • it shows 1.a and 2.b

What should have happened instead?:
Should show 1.1 and 1.2

Software version (skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

Event Timeline

eranroz changed the task status from Open to In Progress.Jan 7 2023, 11:00 AM
eranroz claimed this task.
eranroz triaged this task as Medium priority.
eranroz updated the task description. (Show Details)

@Izno, can you help with getting enwiki's Common.css updated with the styles being removed in the patch above ^? Thanks! I meant to get this done before we shut down for the holidays, but lost track of it.

matmarex subscribed.

(Patch was merged, the bot didn't catch it)

@Izno, can you help with getting enwiki's Common.css updated with the styles being removed in the patch above ^? Thanks! I meant to get this done before we shut down for the holidays, but lost track of it.

Have you verified that this CSS functions with all of our https://en.wikipedia.org/wiki/Special:PrefixIndex/MediaWiki:Cite_link , or at least does not regress current display for Parser.php? I am pretty sure these two things are unrelated, but I am not positive.

I also agree with @Nardog's criticism; the selector by attribute almost equivalent to a value is not a fast one.

@Izno, can you help with getting enwiki's Common.css updated with the styles being removed in the patch above ^? Thanks! I meant to get this done before we shut down for the holidays, but lost track of it.

Have you verified that this CSS functions with all of our https://en.wikipedia.org/wiki/Special:PrefixIndex/MediaWiki:Cite_link , or at least does not regress current display for Parser.php? I am pretty sure these two things are unrelated, but I am not positive.

So, there are two different things here. The change requested there is to preserve existing rendering behavior (by moving the CSS rule from Cite extension to the wiki's Common.css file).

What you are asking about is whether we have ensured that we have adequate / complete coverage via CSS rules to ensure that Parsoid's Cite HTML renders identical to how it renders with non-Parsoid HTML today. That is tacked in T156351: Add wiki-specific CSS styles for Parsoid Cite output so that it renders exactly like core Cite output. See the current efforts documented there and on this wiki page.

But, to address your question for enwiki itself, (1) TLDR 1 is that there are enough rules in Cite's en.cite.style.css to mimic those. If we decide those rules don't belong in Cite and should be moved to individual wiki's CSS, we can do that then (2) TLDR 2 is that https://gerrit.wikimedia.org/r/plugins/gitiles/integration/visualdiff/%2B/cc0d73a292ca509b98369a0deeff1edf064b5e90/lib/parsoid.custom_styles.yaml#17 covers additional CSS needed for enwiki itself. Based on Nardog's feedback, I will update my script to convert those (and any other) descendent selectors to child selectors. However, once we finish tweaking and settle on the CSS needed, we'll follow up with CSS change requests for different wikis. But, please feel free to leave your non-enwiki specific feedback either on the wiki page or on T156351. If you have feedback about CSS generated for enwiki, you can leave it at https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/849738/27/tools/cite_css/generated.parsoid.cite.css.output.txt and I can look at the script to see if that is something I can tweak to improve its output.

I also agree with @Nardog's criticism; the selector by attribute almost equivalent to a value is not a fast one.

I responded there. I agree with his suggestion.

So, there are two different things here. The change requested there is to preserve existing rendering behavior (by moving the CSS rule from Cite extension to the wiki's Common.css file).

What you are asking about is whether we have ensured that we have adequate / complete coverage via CSS rules to ensure that Parsoid's Cite HTML renders identical to how it renders with non-Parsoid HTML today. That is tacked in T156351: Add wiki-specific CSS styles for Parsoid Cite output so that it renders exactly like core Cite output. See the current efforts documented there and on this wiki page.

I've mostly just been watching the cite changes creep up and am a teensy bit worried something hasn't been caught. If this specific change isn't relevant to what those particular MediaWiki:Cite link pages do, we should be fine for now. FWIW I'm not convinced that those are being tracked by the en.wp specific CSS you've posted. You have something on that wiki page that notes those items, so I trust you'll catch them on some future run of your script.

I've mostly just been watching the cite changes creep up and am a teensy bit worried something hasn't been caught. If this specific change isn't relevant to what those particular MediaWiki:Cite link pages do, we should be fine for now. FWIW I'm not convinced that those are being tracked by the en.wp specific CSS you've posted. You have something on that wiki page that notes those items, so I trust you'll catch them on some future run of your script.

Those are handled by rules in the Cite extension. But, if as we are reviewing all this, if someone objects to them being there, then, I can update my script to know that those styles are no longer available by default and the script will then add those CSS rules to wikis that need them.

Nice, thanks. About to file a task that is pertinent to this work also that I caught as part of this task, T326484. :)