[mlz] transcription is not displayed for the third name in a group of three

I have recently discovered that one of my multi-lingual bibliographical entries is not processed correctly any longer. The entry contains names of three editors (Chinese + transcription in zh-alalc97). Whenever I try to insert a reference in LibreOffice or create a Bibliography from within Firefox, the transcription of the name of the third editor is not displayed. Here is an example:

Huang Huaixin 黄懷信, Zhang Maorong 張懋鎔, and 田旭東, eds. Yi Zhou shu huijiao jizhu 逸周書彙校集注. Shanghai: Shanghai guji, 2007.

It is always the last entry that is not displayed properly. If I change the sequence and move Tian Xudong to the middle position, the result will be as follows:

Huang Huaixin 黄懷信, Tian Xudong 田旭東, and 張懋鎔, eds. Yi Zhou shu huijiao jizhu 逸周書彙校集注. Shanghai: Shanghai guji, 2007.

Therefore, I suspect that the problem is not in my entry, but either in MLZ settings or in MLZ itself. However, I vaguely remember that everything used to work correctly before one of the recent upgrades (I am now using the most recent version).

I am a new user of MLZ, and I realise that the answer may be very obvious, but I do need some guidance. Thank you!
  • It shouldn't be doing that to you. I can't reproduce it in a processor test fixture, but that doesn't mean there isn't a problem. It's hard to image how it could happen, but maybe MLZ itself is truncating the data in some way.

    For testing in the MLZ client itself, could you export the item data as Bibliontology RDF, paste the exported code to http://gist.github.com, save it as a "Public Gist", and post the URL back here?
  • (Testing with a hand-crafted entry in MLZ, I was again unable to reproduce it, so I'll definitely need an export of your data.)
  • Thanks for your reply, Frank!

    Here is the link: https://gist.github.com/anonymous/7675365
  • It's still not failing for me. Which style are you using? (If it's a custom style, please post it in the same way as the RDF.)
  • edited November 27, 2013
    (It does look like MLZ CMS Full Note, though. If that's the case, it's not failing here. What is your current MLZ version?)

    [Edit: ah, sorry. Most recent version. Hmm. Do confirm the style, just in case.]
  • Yes, it is MLZ CMS Full Note. I have tried other styles (non-MLZ CMS Full Note, Harvard-Oxford Brookes). Same result.
  • Let's try the settings next. Can you post screenshots of your language preferences, in the document and in MLZ itself? At least then we can be sure we're sending the same data to the processor.
  • edited November 27, 2013
    Here is the MLZ preferences screenshot: http://postimg.org/image/d857u70gp/
    And here are the settings in Libre Office (this is the first time I have actually clicked on the settings tab): http://postimg.org/image/a8q74v33t/
  • Hmm. Still works fine with those settings, in the CSL:edit pane and in the word processor. Next the environment ... What are your platform (Windows, Mac OSX) and Firefox version? While we're at it, we might as well check the exact MLZ version as well.

    (I'm off to school now, there will be a hiatus for the next six hours or so.)
  • Also: check whether this happens in a fresh document.
  • Firefox 25.0.1 on Ubuntu Linux.
    MLZ 4.0.14m429
  • edited November 27, 2013
    yes, it is still the same in a new document. and even if I export bibliography directly from MLZ to clipboard -- the problem still persists.

    and thank you again for all your prompt replies, Frank!
  • This is the same as my own environment, which is a bit puzzling.

    What happens if you reimport the item you linked above? Does the reimported item behave in the same way, or does it render all three variants?
  • edited November 28, 2013
    (I've found one anomaly, at least. With the "Move Up" menu item, when the preceding creator in the list is of a different type, the move clones the headline entry onto the previous item, instead of performing a proper move. But it's not the cause of the bug you are seeing, unfortunately: the messed-up data behaves exactly as expected in citations.)
  • We can also check to see what the item is showing to the processor. Export the item as CSL JSON and post the data to a Public Gist. Here is what I get on my system: https://gist.github.com/fbennett/7698624
  • Eureka. No need for further information, I've reproduced the bug.

    It happens when the creators are set in single-field mode. Strictly speaking that is not correct in MLZ, since these are personal names -- but it shouldn't affect multilingual rendering. It might be Monday before I have a fix, but we're now on track to make this right.

    No need to make changes to your data: this is a clear processor bug.
  • Sorry, I should have indeed mentioned my habit of entering Chinese names as single-fields, which is an easy workaround to avoid their incorrect rendering (such as putting the personal name before the family name, abbreviating the personal name etc.). When I first discovered Zotero I even thought that the single-field mode is specifically designed for Chinese names. :)
  • Anyway, thank you a lot for your work, and I am glad you have finally identified the problem!
  • It should be fixed now, in MLZ release 4.0.14m430. Thanks for reporting this one. Let us know how it goes.
  • Dear Frank, after more than a year, I seem to have problems with exactly the same entry. :)

    This is a volume with three editors, and I am trying to add Chinese names and Russian transcription variants for each editor. First, as I try to set base language to Chinese, the role always switches from Editor back to Author. Second, as I add variants to the second and third entries, they are mixed chaotically, and I never arrive at having name+variant pairs for all three names.

    Here is the problematic entry: https://gist.github.com/anonymous/25c4f2eddd581fd0f80e

    And here is my current language settings windows screenshot: http://s14.postimg.org/509gp3wwt/Screenshot_from_2015_02_23_16_28_38.jpg?noCache=1424708870

    I also had the same problem as I was trying to re-create the entry from scratch, i.e. it does not seem to be an entry-specific problem.

    Having said that, I find that the current version of MLZ is much better in everyday use than a year ago. Thanks for your work!
  • Oh, that's not good. I can reproduce this immediately. I'll take a look, should have a fix out soon.
  • Updating the client should fix it now. If you spot any other problems, just give a shout.
  • Unfortunately, it still behaves strangely, and I am still experiencing problems with both old and new entries.

    1. If I set "field language" after I have already changed the role from "Author" to "Editor", the value switches back to "Author". And then the "field language" is occasionally reset, too.

    2. I could not add zh-Curl or pinyin variants for a Chinese Editor in an old entry, so I tried the same in a test entry. Here is what I ended up having: http://s28.postimg.org/3xvxgbf09/Screenshot_from_2015_02_24_13_57_49.jpg?noCache=1424786247

    3. In an old entry, I am not able to do anything with the field language. Whatever I choose, the value remains blank. Needless to say, there is no way I can add pinyin and Cyrillic variants to it: http://s27.postimg.org/qe7b6wqb3/field_language.jpg?noCache=1424786789

    Hope this helps and please tell me if you need more details.
  • edited February 24, 2015
    A fix is now up for (1), in version 4.0.26m506.

    I'm not sure about (2) and (3) - the screenshots posted are coming out very tiny, and I can't quite make out the detail. If you're posting them at full size, possibly another service (maybe http://imgur.com/ ?) will let them through at a larger scale.
  • Oh, sorry for the screenshots (I copied the wrong links), this should work better:

    http://postimg.org/image/ndd1c27wd/

    http://postimg.org/image/n5e5eofm9/
  • I can reproduce the crash, and there are other bugs. It's not handling entries that have variants on other creator fields correctly. More soon ...
  • Try with the latest (4.0.26m507). I haven't tried to reproduce your menuing issues yet; let me know if those bugs persist in this release.
  • Thanks, I've installed the update and can't see any problems now!
  • edited February 25, 2015
    That's very good to hear!

    The murmuring sound you might hear in the distance is a collective word of thanks from MLZ users.
Sign In or Register to comment.