Sonny Software

Hi,

I am not sure how to best deal with Japanese and Chinese names in the author fields. When citing Japanese authors writing in Japanese it is usual to give the characters for their names and to list their names with surname and first name with no comma between them, but followed by Chinese characters.
E.g.: Tanaka Taro XXXX. 1987. ...
But when citing a work of the same author in English, for instance, I would usually cite him as:
Tanaka, Taro. 1990.
My problem is that I need to be able to delete the comma when the format is Surname + First name = Characters, and add it when the format is Surname + comma + First name. Is this possible without setting up a special field or reference type?

Kindest regards,
Shayne

Hi Shayne,

If I understand you (and perhaps I don't), formats for the Roman + Asian name (with no comma) would output the authors as full name, with only a space for punctuation after surname. When you want the comma, you would have the format specify a comma after surname. You could either user different formats for this, or different Types in the same format (which is what I think you want). Bookends can't output the names in two different ways depending on whether there are non-Roman characters in it. I think you'll need to use Types to distinguish them. But again, perhaps I'm not understanding exactly what you are after (it's late on a Saturday night).

Perhaps someone has another idea?

Jon
Sonny Software

Hi Jon,

Thanks for your quick response. You seem to have fully understood what I am trying to do, and as far as I can see, the only way to do this would be to set up, as you suggest, different Types. (Clearly I do not want to start making different formats, otherwise I will end up with a large number of formats to cover what is essentially one format). My main concern here is that I see that I am fast going to run out of user-definable types (as Rolf mentioned in another topic post). In order to do this correctly, I would need to have one type (Asian name) used in the following fields: Journal, Book, Edited Volume, Chapter, etc. I have gone ahead and done this, but I have now used up 5 of the user-definable Types, and all to work around a contingency that requires a variation of name display format. Would it be possible to have unlimited user-definable types and fields? Is there any reason for the limit? I suppose that it is merely a question of where to put them in the reference window, but perhaps they could be hidden (hidden is better than not there).

The other feature I think would be useful is the ability to add set text to any field (similar to what you offer for punctuation option with names, but more along the lines of Sente's prepend and append). Sometimes in the editor field, for instance, I want to simply use ed., but sometimes I would prefer to use revised or revised and emended, or supplemented by, or with an introduction by ... I guess I am somewhat stuck on the ability to slightly modify output depending on various contingencies without having to resort to using the my ever decreasing number of user-definable fields and types.

Kindest regards,
Shayne

Hi Shayne,

We have 27 Types now (10 user definable). That should be enough, I think, for most cases (I'm sure that there are some you never use and could be changed to suit your needs, perhaps Map, Audiovisual Material, Patent, and a few others). If that's not enough, please contact me directly and we can try to figure something out.

Bookends handles what is output on a contingency basis by the use of spaces and the quote marks ($ and `). Basically, the presence or absence of data in a field determines what Bookends outputs. It works pretty well (although there can be some tricky situations in which it doesn't do what you want).

As I think we've discussed in the past, the section in the User Guide on "when fields are empty" tells you how to have one format give different results depending on whether a piece of data is there or not. If it still isn't clear, please email me with examples of what you're trying to accomplish and I'll see if a simple, single, format Type can do it.

Could you just input the names differently when working with Japanese authors in Japanese. I need to do the same thing and I enter "Tanaka Taro XXXX," when the work is in Japanese and "Tanaka, Taro" when the work is in English. You could also have a separate field for characters and when empty it wouldn't show up.
-Alex

Alex wrote:Could you just input the names differently when working with Japanese authors in Japanese. I need to do the same thing and I enter "Tanaka Taro XXXX," when the work is in Japanese and "Tanaka, Taro" when the work is in English. You could also have a separate field for characters and when empty it wouldn't show up.
-Alex

Alex,
Thanks for your suggestion. The problem, as I see it, with entering "Tanaka Taro XXXX," when the work is in Japanese and "Tanaka, Taro" when the work is in English, is that depending on what format you use, the XXXX is misunderstood by Bookends to be the surname, and therefore you get outputs such as: ""XXXX, Tanaka Taro". Naturally, this can be changed by editing the format (changing the name option to John Doe instead of Doe, John), but this then means that the the English title comes out with Taro Tanaka, which is not what one would want. The work around I came up with was to create a new type (J, Book, etc.) where all books in Japanese have the author's name appear in the correct format. But this means that I have to create 5 new formats for what is in fact only a difference in how the name should be displayed. This works, but seems like a real waste of a limited number of user-definable types. I could, of course, create a separate format, but as I may want to output the bibliography in one format (with mixed works, Japanese and English) this is not acceptable. Your suggestion, to use a separate field, also makes good sense, but again I am faced with my old problem of not wanting to use up the user-defined fields as I see that I am quickly running out of them.

Kindest regards,
Shayne

Shayne wrote:The problem, as I see it, with entering "Tanaka Taro XXXX," when the work is in Japanese and "Tanaka, Taro" when the work is in English, is that depending on what format you use, the XXXX is misunderstood by Bookends to be the surname, and therefore you get outputs such as: ""XXXX, Tanaka Taro".

Actually, that will not happen. If a name concludes with a comma, Bookends treats it as an entity (meaning, it won't look for a surname and first name). This is useful, for example, when citing a report by an insitution, or perhaps in your case, citing a non-Roman name.

Please refer to the User Guide for more details about formatting of names.

Jon
Sonny Software

Jon wrote:Actually, that will not happen. If a name concludes with a comma, Bookends treats it as an entity (meaning, it won't look for a surname and first name). This is useful, for example, when citing a report by an insitution, or perhaps in your case, citing a non-Roman name.

Thanks Jon. You have done it again. Bookends continues to amaze me, just as my own ignorance continues to frustrate ...
I tried adding a comma, and it works perfectly, but now I wonder how I can output two such entities (in my case non-Roman names) under author. I am a little unclear of how to get, for instance, Tanaka Taro XXXX, and Yamada Jiro XXXX.
Do I put a space after the comma in the author field after the first name? When I do this I get Tanaka Taro XXXXYamada Jiro XXXX. with no punctuation in between.

Kindest regards,
Once again in awe,
Shayne

Hi Shayne,

Ah, looks like a bug to me. I only tested this with institutional names, and of course there is only one per report. I'll fix it for 8.0.4.

Jon
Sonny Software

Jon wrote:Ah, looks like a bug to me. I only tested this with institutional names, and of course there is only one per report. I'll fix it for 8.0.4.

Thanks Jon. The ability to add more than one institutional name would be great; although I would mainly use it as a work around, occasionally one does come across collaborative works where two institutional names night be necessary.

Keep up the good work.
Shayne

Shayne,

I fixed the problem with two or more "corporate names" running together when formatted. If you need this prior to the release of 8.0.4, please contact me directly.

Jon
Sonny Software

Thanks Jon.

This post is somewhat related, so I thought it might as well go here. In the same way as inserting a comma after the author's name treats that name as an entity, is there a way of fine-tuning the Title Case. I find that I usually use Title Case capitalization with roman (English) titles, but "as entered" with Japanese titles. Obviously I don't want to create a separate type just for this, so some kind of override would be very useful. A comma, perhaps, inserted after the title to tell Bookends to override the Title Case and use "as entered". Does this make any sense?

Kindest regards,
Shayne

Shayne, have you tried this with titles? If I remember correctly, the case setting only works with Roman text (because it is meaningless for Japanese). Does it change Japanese text when you use it?

Jon
Sonny Software

Hi Jon,

You are quite correct, it does not change the Japanese text at all, but what I want to control is the transliterated/romanized Japanese title. The same thing would apply for, I suppose, French or German titles as well, but when making bibliographies with Japanese or Chinese titles, I always give a romanized title (so non-readers of J or C) can cite the paper, and the title in the original (J or C) orthography (this helps those that can read it track down publications). An entry, therefore, may look like this (I have used X for Japanese characters).

Tanaka Taro XXXX. 2002. Jiun sonja no kenkyu XXXXXXX. Kyoto: ABC Publishers.

The title, of course, is Jiun sonja no kenkyu XXXXXXX, and this is how I would like to output it, not Jiun Sonja No Kenkyu XXXXXXX. This is why I would like to be able to maintain the ability to use Title Case, but also to be able to override it if necessary (half of my references).

Kindest regards,
Shayne

Hi Shayne and all,

I'm facing a similar quandary. Some journals or editors do not allow CJK alternate forms of author and title to appear in text. There are vastly different conventions across journals for Romanized or translated forms of titles. In my experience, several "fields" are employed.

Author1ConventionalSpelling
Author1CJK
Author1StandardRomanizedForm

TitleRomanized
TitleCJK
TitleTranslation

The three author forms also apply to multiple authors, editors, translators, etc.

I have looked through the various citation forms to see if any of the User fields are really free for use, and I have concluded that there simply aren't enough. (Jon has told me that Bookends' UI philosophy is to keep all reference information on a single page - so there really is no more space.) Furthermore, even if there were enough, (say for 3 versions of an author's name) there would be the problem of getting Bookends to correctly correspond Author1's info and Author2's info.

Here's what I'm proposing:

What if the author field could contain all of the alternates, separated by special characters? The citation format could specify which if any to include. For example, after the default text, text following a bar could contain CJK or more generically alternate glyph forms. Using your earlier example:

Authors: Shige Nagata | XXXX,
Iijima Wataru | YYYY,
Title: Eisei seisaku | ZZZZ

Then, citation formats could specify how to display:

a, t. > Shige Nagata and Iijima Wataru, Eisei seisaku.
A, T. > Shige Nagata XXXX and Iijima Wataru YYYY, Eisei seisaku ZZZZ.
A, t. > Shige Nagata XXXX and Iijina Wataru YYYY, Eisei seisaku.

Jon has carefully kept those field references lower case (a, t, etc.) - this would be a perfect opportunity to employ the upper case. This solves the correspondence problem and doesn't break the interface.

This still doesn't conquer the problem of incorporating the 3rd piece of information: the translated title or standard romanized author's name. Either another special character could be used (the ideal solution, in my opinion), or I suppose there might be enough user-defined fields to cover the remaining needs.

I'd be interested to hear what you all think of this.

Best,
Joe