Localized "and"

mlwang

Hi,

I know I can localize the text of the term "and", but is there a way to set a localized "symbol" for "and" (i.e., not "&")? If not, may I set different ("short/long") versions of the term?

I'm asking because common Chinese citation practice (here in Taiwan at least) prefers to use a special punctuation mark (a "light comma" with no direct English equivalent) instead of the "&" symbol to separate two authors. Currently I use <term name="and"> for "light comma", but that takes away the ability to have a true Chinese term for "and".

I've experimented with <term form="symbol" name="and">, <term form="short" name="and"> and <term form="long" name="and"> to no effect. Am I doing anything wrong?

adamsmith

and just to be clear, you couldn't just put this into the delimiter field? I.e. there is a different comma for more than two authors?

To answer your question: no, you can't localize the ampersand and it doesn't have a short or long form, although you can, obviously, localize the text "and" to anything you want, including a symbol.

mlwang

I'm not sure how the delimiter field has anything to do with this. When there are two authors, Zotero/MLZ always uses "and" to separate the two names (irrespective of the delimiter setting), right? The only thing I get to choose is to use the "symbol" version or the "text" version. Since I can't change the "symbol" (thanks for making that clear to me), the only way to use the Chinese "light comma" in this situation is to set it up as the localized "text" for "and".

This works for most cases, but when we have something that needs both "versions" of "and", we have a problem. Consider the following example, taken from the MLZ's CSL-m spec page (http://citationstylist.org/docs/citeproc-js-csl.html#affiliated-authors):

Clarke, Ministry of Fear and Smith & Brown, Large Corporation

Ideally, I would like to have the "light comma" in place for the ampersand, with a Chinese equivalent of "and" in place for the word "and". Currently the "light comma" is used in both places, and it's not pretty. (Imagine using ampersand in place of "and" for the example above.) Guess I have to live with it for now though.

fbennett

This is an interesting issue. The obvious solution will be to allow localisation of the ampersand. I've used up my programming time for the week, but I should be able to set it up in MLZ next weekend.

adamsmith

When there are two authors, Zotero/MLZ always uses "and" to separate the two names (irrespective of the delimiter setting), right?

No. When you don't have any "and" attribute in cs:name the delimiter is printed between two authors. Very common in the English styles in the sciences, e.g. Vancouver. I'm not sure that's relevant here.

edit:
in other words (though not having tested this), I'd expect
<names variable="author">
<name delimiter="; " initialize-with=". "/>
<institution and="text" delimiter=", ">
</names>
to return
Clarke, Ministry of Fear and Smith; Brown, Large Corporation.

(where I've chosen the semicolon to stand in for you special light comma).

mlwang

fbennett:

Many Thanks. You have been amazingly responsive already. I wish I could code like you.

adamsmith:

Thanks for the suggestion. It doesn't work here, unfortunately. I'm using MLZ (newest version), not Zotero, if that makes a difference.

adamsmith

it doesn't work how, though? You definitely shouldn't be getting an and with my suggetion.

mlwang

Sorry, my mistake. I forgot to change the localized "and" from the "light comma" to a real Chinese word.

On 2nd try, indeed your method successfully replaced the ampersand with the delimiter. The problem remains, however, for I do need the regular comma. Using the same English example as the above, we get the following with your method:

S. Clark; Ministry of Fear and R. Smith; T. Brown; Large Corporation

See? The semicolon would take not only the ampersand between Smith and Brown, but also the comma between Clark and Ministry as well as that between Brown and Large. That's not acceptable, I'm afraid. Thanks for showing me how to avoid "and" altogether though. Appreciated.

fbennett

mlwang: Can you post a copy of a Chinese citation as you would expect it to appear? I can use that as test data to explore how to set things up to work with mixed English and Chinese cites.

mlwang

Of course. For affiliated authors (Bluebook R.15.1(c)) purpose, I would prefer something like:

葉俊榮，台大法律系與林子儀、簡資修，中研院法律所

* color code:
blue: personal names
green: institutional names
red: Chinese equivalent for the word "and"
orange: the "light comma" I keep talking about
black: Chinese comma.

** A Chinese comma is a "comma" taking the space of one Chinese character. (Chinese fonts are non-proportional in nature.) It can be substituted with ", " (regular comma followed by a space). The same applies to other Chinese punctuation marks with direct English equivalents, including the round brackets used below.

Screenshot for those without Chinese fonts installed:
https://docs.google.com/file/d/0B3F1SeOjlQYqQWF1WDh5aEEtT1E


For interviews (Bluebook R.17.2.5), it should be:

葉俊榮（台大法律系教授）與林子儀、簡資修（中研院法律所所長）訪談紀錄

* color code: brown - a Chinese expression meaning "interview record".

Again, screenshot at:
https://docs.google.com/file/d/0B3F1SeOjlQYqNm1DRTNCZmxzNTA

I'm putting the interviewees' title inside a pair of brackets because

1) we don't have a proper way to start the cite as "Interview with",

2) with the Chinese expression of "interview record" following the name list, there can be no delimiter in between, lest the cite becomes a document with the title "interview record" authored by those interviewees; and

3) since there's no comma separating the name list and the Chinese words for "interview record", it would be odd to use a comma between interviewees and their title.

One last note: there is really no standard citation rules for Taiwanese legal community. Each law journal has its own rules, but usually very sparse, covering usual suspects only, and often poorly enforced. I've never seen a rule for interview, let alone one for complicated multi-affiliated authors like we're discussing here. I'm therefore making up my own rules, trying my best to make these rarely used cases blending in well with the normal ones.

fbennett

This is very helpful -- thanks!

Coincidentally, I'm currently working a Japanese style for our faculty journal 『法政論集』. The situation here is similar to Taiwan, with loose conventions and sparse guidance documents. The main reference seems to be this 2004 document, which covers only the main item types.

I'm working through some basic forms right now. I'll try to build a test later today, and work out what best to do with mixed-element name listings.

fbennett

I've implemented a localised symbolic form of "and" for names formatting in MLZ. You can get the "soft comma" in your style by adding this to the terms area of the locale section:
<term name="and" form="symbol">、</term>
Using and="symbol" on cs:name or cs:institution will call the localised form.

This is form MLZ only at the moment: localisation of the "symbol" form of "and" is disabled in Zotero proper.

mlwang

That's great! Thanks a lot!

The version info. on the download page should be updated though. It still says [Ver. 4.0m398, 14 Oct 2013].

fbennett

Missed that, thanks. Updated now.

Rintze

@fbennett, in my reading of the CSL 1.0.1 schema, it's already allowed to specify

<term name="and" form="symbol">、</term>

, right?

fbennett

Yep, defining the term is legal. The problem is that the processor has "&" hard-wired internally, and the shipped locales don't have that form of "and" defined. In MLZ, I've added the symbol form to all locales, and enabled use of the term. By default the term is disabled in favor of the hard-wired ampersand, though, to avoid breakage in a normal installation.

Rintze

Ah, okay. So treating it as a regular term would give problems, since it's absent from the locale files. We probably should add it there, then.

fbennett

That's it. If the term is made available in the locale files, the specification could make the connection between locale term and the and="symbol" attribute on cs:name explicit.

The issue to watch would be with styles that redefine the unadorned form of the term:
<locale>
<terms>
<term name="and">und</term>
</terms>
</locale>
This happens in 23 repository styles. On the specification, it should affect only the default long form, and leave the other forms untouched (i.e. "or specific form of a term"). If that's not strictly honored (if the bare term definition wipes the slate clean for the target term) it would disable the symbol form of the term, which would be a problem.

I just checked, and citeproc-js conforms to the specification, so adding the symbol form and relying on it would be fine here. It might be worth checking with other processor developers to be double-plus-sure. It seems unlikely to be a problem, since over-aggressive redefinition of locale terms would probably cause issues in other contexts as well, but just in case.

Rintze

@fbennett, I think it might be best to add the "symbol" form of the "and" term to the locale files at the next CSL release (1.0.2).

In the meantime, if you haven't already done so, could you create a unit test to verify that defining the "symbol" form of the "and" term in cs:locale of a style works?

fbennett

It's in the processor sources:

https://bitbucket.org/fbennett/citeproc-js/src/6991e152732e83dde218c06df3a3236caf6471c4/tests/fixtures/local/multilingual_LocalisedNameDelimiters.txt?at=default

Can be moved to the CSL test repo after the spec amendment goes through.

Rintze

I just noticed that the Chinese example above ("葉俊榮，台大法律系與林子儀、簡資修，中研院法律所") doesn't have any spaces in it. @fbennett, how do you deal with this?

I'm asking because it seems like the "and" term is wrapped in hard-coded spaces in English.

adamsmith

also relevant for Hebrew, where the "and" (the so called vav - ו ) has a space before it but not after it. So roughly speaking

Apple
תפוח
Orange
תפוז
Apple and Orange
תפוח ותפוז

fbennett

also relevant for Hebrew, where the "and" (the so called vav - ו ) has a space before it but not after it.

Do you mean that it's supposed to, or that it wrongly comes out that way?

adamsmith

it's supposed to.

fbennett

I can make that happen, then, but it will probably wait for someone to press for it -- I'm leery of touching RTL stuff, since it's not working well yet (apparently due to word processor glitches that vary across products).

For name spacing generally, it's suppressed according to the charset.

adamsmith

What would pressing entail? I'm currently writing a style for Israeli legal scholars and they've pointed this out to me, so I'd certainly be very interested in this and also able to test.

fbennett

See how this works. You'll need to add an explicit space to the term with &​#8200; or so. There is a test here,

adamsmith

awesome - will get to trying that letter tonight. Very happy about this.
Do I understand correctly that we should add the & #8200; for the Hebrew locale as well?

fbennett

I reckon so, if it's a general requirement.