Closed Jason-Abbott closed 1 year ago
This seems to be pertinent documentation:
The “locator” variable is always rendered with an en-dash replacing any hyphens. For the “page” variable, this replacement is only performed if the
page-range-format
attribute is set oncs:style
In this case, the page-range-format
attribute is set so it seems, contrary to the test, that all dashes should be en-dashes.
I'm pretty sure the rationale here is that not all hyphens indicate ranges -- they can also, e.g., be part of an article number, in which case flipping them is clearly wrong. So the test assumes that if you have just numbers or you have numbers with the same prefix, that's a range, otherwise it's not. The relevant commit changing the test (which did use to be all en-dashes) also suggests that rationale.
Okay, that makes sense. I’ll close this issue. Perhaps confusing is that some of the unchanged dashes are called “ranges” in the test. I guess that’s just how they began, prior to the commit you linked.
P.S. I’ll be sure to check commit history on tests before opening issues from now on. 👍
I think we'd also take PR's with comments on tests you find confusing. Ideally it shouldn't need a 7 year-old memory of a discussion on the Zotero forums to figure out the rationale for a test ;)
Yes, see #51
The expected output for page_Expand sometimes retains the original page range delimiter character (retaining a dash) and sometimes it replaces it with the locale standard (converting dash to en-dash).
So always keeping the existing delimiter doesn’t work and always replacing it doesn’t work. I can’t discern the expected logic.
It seems like the range character should always be updated to the standard when re-formatting a range. What am I missing?