-
-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split title documentation (for 1.1) #110
base: master
Are you sure you want to change the base?
Split title documentation (for 1.1) #110
Conversation
I was thinking we might want to add a new section for input data, and this could primarily go there, along with the rich text stuff, and dates?
|
Yes, this. We also probably need a whole new section in the spec to describe how title processing works, similar to the section on names and dates being split out. |
I should better convert this to draft... |
@bdarcus If we want to simplify these rules, we could the delimiter sets down to We could even eliminate extended if we want. That could eliminate the Ignore the
Split subtitles on
|
Couldn't we just add
A semicolon in a title that doesn't serve as a delimiter should be rare enough anyway, right? |
Probably. |
Chicago style splits and punctuation are now also endorsed by MLA:
|
Let's change the relevant pattern to |
By the way, why do we have |
It was in Frank's list, I think because a lot of library catalog data explicitly use |
Hmmm, we, at least, use Concering |
An edge case regarding Chicago style splits. Even if you normalize colons to periods in other cases, here you will not want |
Here are the three examples from the current Chicago manual, with the first being preferred nowadays:
The first we don't bother with. That would be need to be entered as The third is handed by the normal colon rules. The second is the only one that needs to be handled. This regex pattern should work for that |
Just noting here: Chicago and MLA describe those examples (the parts after the "or") as "alternative" or "double" titles.
In an object representation they'd have separate properties.
|
I think that’s more a semantic description. In most data they are going to be entered as a flat title (e.g., especially the Dr. Strangelove title). |
But shouldn't we make sure the colon does not gets replaced here? |
I don't think the latter point is relevant, but I'll save that for another thread. On the first point, it's exactly how it's described in the style guides. From here:
|
Yes, I think that's more a semantic description of the type of subtitle, rather than a description of how to expect these to appear in item data. Here is the full description from the Chicago manual:
|
We could. In that case, listing these separately would be best: |
I don't disagree that it's semantic; I just wanted to make clear it wasn't my interpretation of the rule descriptions.
|
This adds documentation for the title-splitting feature to be added in 1.1. I'm not sure it's in the right place. (I actually am quite sure that it isn't, but I don't really know where to put it. Should, e.g. the attributes be added to the sections on style behavior? Only there? Or as well?)
One thing that still needs to be discussed: In the proposal I've had this paragraph regarding: As some locales prefer en to em dashes citeprocs should check against both if the "full" options are selected on
normalize-title-delimiters
and/ortitle-split
. Should I add that somewhere, or should I just add "–" (an en dash) to the relevant options in the schema and in the documentation.