Incorrect capitalization (?) in Chicago with Multilingual

nathan.hopson
Using Multilingual. Citing Japanese, in transliteration. Chicago (same problem w/ Note and Full Note). No Language settings (Doc Prefs > Languages > Transliteration / Translation / Sorting) fix this apparent inconsistency.

Capitalized correctly (sentence capitalization):
Book → Kudō, Emishi no kodaishi.
Book chapter → Takahashi, “Tōhoku kodai no kaitaku.”
TV broadcast → TV Tokyo, “Anshin henkaku doko e (2).”

Incorrect (title capitalization):
Web page: NNN News, “Jimin / Abe Sōsai Ni ‘kitai’.”
Report: Suzuki et al., Shakai Hoshō Sedaibetsu Futan, 32.

Elsevier Harvard does not mis-capitalize.
MLA and MHRA do.

Haven't tried other source types or citation styles yet.

Looking forward to your wisdom.
  • adamsmith
    do you have the web pages labeled as Japanese? (i.e. do they have something in the "language" field? That's what disables title case for styles that require it in English.
  • nathan.hopson
    Yes. I have also tried several variations of ja-JP and en (en-US) with no effect at present.

    For example:

    Suzuki et al., Shakai Hoshō Sedaibetsu Futan
    Shorty title is entered as:
    Shakai hoshō sedaibetsu no jueki to futan
    I've tagged it as (en) and added (ja-JP) just in case. No change.
    I've also all possible combinations I can think of, including no tags, a single tag (both en and ja-JP), etc. Nothing changes.
  • adamsmith
    when you say "tag" that's just a misnomer, right? ja-JP would need to go into the language field of the item, that's where Zotero (and MLZ) look.
  • nathan.hopson
    edited January 16, 2013
    Thank you. I had the language field as ja-JP, not ja. Changing all the fields to ja seemed to help.
    The "tags," which were correct, are for the individual fields.

    I still had to completely erase one of the web pages and start from zero to make it work. I think the entry was somehow corrupted. This may have been the start of my confusion.
  • adamsmith
    sorry, I'm not clear if this is working correctly now or not?
  • fbennett
    One of the things I'd like to do in MLZ is to replace the free-text Language field with a controlled list pulldown, which should eliminate this potential source of confusion.
  • aurimas
    edited January 16, 2013
    One of the things I'd like to do in MLZ is to replace the free-text Language field with a controlled list pulldown, which should eliminate this potential source of confusion.
    What are your thoughts on how the translators are supposed to handle this? I think in most cases we can figure out locale string from the actual language name, but what do we do when we cannot map it to anything? Leave locale blank? Currently the user can fix it him-/herself.

    This is a bit hackish IMO, but here goes. I think we can have a dropdown selector as you suggest. In the case where we cannot map a language to a proper locale on import, we can show the language name in a box (probably non-editable) next to the dropdown list. When a user chooses a locale (and confirms), we delete the old language value and replace it with locale string.

    something like:

    Language: <dropdown> ingles

    The confirmation would be a popup dialog.
  • adamsmith
    sounds good to me.
    We should probably start thinking about a mapping function sooner rather than later - IIRC the Primo translator may have one that goes the wrong way, we could invert it and write it into utilities.js or so, adding a couple of languages.
    Seems like a good idea to start getting databases right sooner rather than later.
  • Gracile
    That would be great to replace the freeform.
    Migration is also an issue:
    http://forums.zotero.org/discussion/3252/please-documentexplain-the-use-of-the-language-field/#Item_5
  • aurimas
    I think Dan is pretty much suggesting the same thing here (i.e. what he suggest for migration). RFC 4646 specification is quite granular. I'm not sure how feasible it would be to implement it completely (other than language and regional codes) in the UI
  • fbennett
    I'm thinking there would be two elements to the Language field UI: a field that click-opens to a search box; and a button that opens a menu of known languages. The search box would provide a search-as-you-type listing of RFC 5646 primary languages. A language selected via the search box would be added to the menu accessible under the field (and to the configured language list in Preferences -> Language).

    When the field contains a string that doesn't match a language code known to the field menu, it can be given a yellow highlight (say) as a reminder that it is not yet meaningful for citation purposes.
Sign In or Register to comment.