Page MenuHomePhabricator

ProofreadPage ignores roman numeral ranges when overlaping with other ranges.
Closed, ResolvedPublic

Assigned To
Authored By
Soda
Sep 25 2020, 7:31 PM
Referenced Files
F34939311: image.png
Feb 1 2022, 11:53 AM
F34939309: image.png
Feb 1 2022, 11:53 AM
F32363791: 2020-09-26 (2).png
Sep 25 2020, 7:31 PM
F32363788: 2020-09-26 (4).png
Sep 25 2020, 7:31 PM

Description

For the particular syntax, <pagelist 1to10="-" 2to4="roman" /> the roman numeral range seems to be completely ignored and instead all the values from 1 to 10 are filled with "-"

PagelistOuput
<pagelist 1to10="-" 2to4="roman" />
2020-09-26 (4).png (439×1 px, 39 KB)
<pagelist 1to10="roman" 2to4="-" />
2020-09-26 (2).png (448×1 px, 40 KB)

This seems to happen with all inbuilt numbering systems.

Event Timeline

@Soda, I don't have proof, but I think how it works is that the later attributes of the pagelist tag take priority over previous ones if there's an overlap. However text labels like "-" don't have a "numeric nature" any more, so a number scheme like "roman" has no effect.

In fact, _any_ numbering scheme has this effect:

<pagelist
1to10=—
5=1
/>

Where page 5 will not appear as 1, it's still "—". On the other hand, text can still overwrite text:

<pagelist
1to10=—
5=foobar
/>

and now page 5 is labelled foobar.

DorianWinty added a subscriber: DorianWinty.

I'm seeking from where the bug could be

<pagelist 1to10="-" 2to4="roman" />

image.png (141×359 px, 4 KB)

for the element in red

image.png (124×360 px, 8 KB)

we can see that the type "roman" where well applied
but for the number it stay "-" but the space &nbsp; is well applying too due to the "roman" type

so it's a problem with the set of the text part

I have asked the advice on https://fr.wikisource.org/wiki/Wikisource:Scriptorium/F%C3%A9vrier_2022#%3Cpagelist_/%3E_bug_avis
If we should modify how that work now, but everyone asked to don't do anything.
They think the overwrite is commonly use and could break something.
For them they say the romans characters are less used than numeric so it's normal for them to have this behavior

Furthermore, they say the visual editor is commonly used such case should not append in the future.

So may I close this ticket ?

Dereckson added a subscriber: Dereckson.

Closing per previous comment.

With the visual edition mode, I'm not sure it's worthwhile to investigate to detect pagelist format potential issues, but if we want, we've two strategies:

  1. A tool looking the db
  2. Modify Proofreadpage to add a maintenance hidden category to Index: pages with pagelist overlapping numbers, and print a warning at parser level.