tl;dr: I suggest we add
role elements to CSL
name variables. Alternatively, a generic
label element for
name could fill both functions and be less disruptive to existing styles and processor behavior.
There are a couple of name formatting requirements for APA style that either (1) aren’t currently supported by CSL, or (2) currently work using off-spec (I think) behavior in citation processors.
- Alternative names (e.g., usernames, alternative script names, inferred names): Usernames for online materials should be provided in square brackets:
APA Style [@APA_Style]. (n.d.). Tweets [Twitter profile]. Twitter. Retrieved November 1, 2019, from https://twitter.com/APA_Style
The same formatting is also used for things like names in the original script if the name is translated or transliterated or inferred authors for historical materials.
- Role labels: In some places, APA wants more descriptive role labels than I think we would necessarily want to provide terms for (e.g., “Host” for podcasts, “Guest” for broadcasts, “Creator and Director” for some TV broadcasts).
Currently, with citeproc-js (and pandoc-citeproc I believe), alternate names and roles like this can be approximated by adding them in brackets/parentheses following the creator given or family name (depending on the style). The processor applies style’s family name formatting to the first word in the brackets and the given name formatting to subsquent words. This works for adding a role like “Host” and can be made to work with multi-word roles/names using joiner characters. However, it doesn’t really work for corporate/single-field authors, and it interferes with correct formatting of names like
Park || HyeSoo (Hailey), which should be rendered as
Park, H. (H.) but currently renders with citeproc-js as
Park, H. (Hailey).
I suggest that we expand the fields that can be supplied in CSL-JSON names to include
role elements. A simpler solution would be to allow a
label element to be provided that would override the automatic
label rendered for the creator. This option would be less disruptive to existing styles and the only drawback would be requiring users to enter the punctuation manually (perhaps with parentheses being used as a default unless other brackets are provided).
Clients should provide a UI field for name labels. We could also devise a syntax for parsing labels two-field names similarly to how particles and suffixes are handled (e.g., separate given name parts and the label with a semicolon).
Processor behavior for name text entered in brackets/parentheses should follow the formatting rules for the rest of the name (e.g., abbreviated if entered in the given name field).