I think Frank should have enough information at this point to debug this. I don't have a Mac, but hopefully someone with a Mac (Dan?) can reproduce the problem you are seeing.
I think the relevant changes were introduced in 4.0.9. There are a bunch of bug fixes in 4.0.9 as well, but I didn't see anything critical, so you should be ok.
I'm sorry about the consternation everyone has suffered over this. If we were in the same timezone, I would have chimed in earlier.
The failure is almost certainly caused by code intended for RTL support. I have a full schedule in my day job today, but this weekend I'll take a closer look at the thread. Certainly something needs fixing in the processor.
I'm stalled on RTL support. There seem to be differences in the handling of incoming text in Word and in LibreOffice that I just don't understand. It needs the hand of an RTL expert who knows both platforms well. There is hope -- there has been some correspondence on the zotero-dev list recently that I haven't had time to follow up. We'll see. For the present, I should be able to squash this particular bug this weekend. Stay tuned ...
Thanks fbennett - and thanks to everyone who has been working on this with me!
I just want to clarify that nothing I am writing is actually RTL - I am transliterating everything into the roman alphabet. So when I tell zotero that something is in "Arabic," I don't want it to think that the script will be RTL - I just want it to know what capitalization formatting to follow, since the Chicago Manual of Style has different rules depending on what language the work is in.
I am sure there are people out there would like to use zotero with Arabic script but it is not a problem I am dealing with at the moment (and honestly, since Word itself can't deal with RTL script having zotero do it is probably pretty far down the list).
That said, I will leave it to you and try updating zotero again next week.
Ah -- in that case there is a quick solution, and there may be no bug to fix.
The "ar" language tag really does mean "Arabic in arabic script". For romanised Arabic, specify the script with something like "ar-Latn", or the transliteration method with something like "ar-alalc97".
(These suggestions are based on the tagging scheme defined in RFC 5646, and the IANA Language Subtag Registry. Not exactly light reading, but it's the best thing going for describing languages; MLZ is built around it.)
Properly speaking, the Language field should indicate the language of the original source. In this case, that does appear to be "Arabic", in arabic script, and that would seem to call for setting "ar" in the Language field.
The problem is that in standard Zotero, there is no way to set the language on individual fields, or to register variant metadata for translations and transliterations: you only have one code to work with.
Since actual Arabic records do require special handling in the processor, the suggestion to use "ar-Latn" or somesuch in the Language field is a necessary compromise for romanised records in standard Zotero.
Since actual Arabic records do require special handling in the processor
What special handling is needed for arabic vs. latin fields?
Edit: what I mean is that from what I understand about this, ltr rtl markup should be done by the reference manager, not CSL processor. Am I missing some use cases?
I'll look at it tomorrow, but if I remember correctly the aim was to set the direction on the cite as a whole, where the surrounding context is LTR. There may be a use for it, but for the interim it can be made optional, off by default.
Upgrade Storage
I think Frank should have enough information at this point to debug this. I don't have a Mac, but hopefully someone with a Mac (Dan?) can reproduce the problem you are seeing.
I think the relevant changes were introduced in 4.0.9. There are a bunch of bug fixes in 4.0.9 as well, but I didn't see anything critical, so you should be ok.
The failure is almost certainly caused by code intended for RTL support. I have a full schedule in my day job today, but this weekend I'll take a closer look at the thread. Certainly something needs fixing in the processor.
I'm stalled on RTL support. There seem to be differences in the handling of incoming text in Word and in LibreOffice that I just don't understand. It needs the hand of an RTL expert who knows both platforms well. There is hope -- there has been some correspondence on the zotero-dev list recently that I haven't had time to follow up. We'll see. For the present, I should be able to squash this particular bug this weekend. Stay tuned ...
I just want to clarify that nothing I am writing is actually RTL - I am transliterating everything into the roman alphabet. So when I tell zotero that something is in "Arabic," I don't want it to think that the script will be RTL - I just want it to know what capitalization formatting to follow, since the Chicago Manual of Style has different rules depending on what language the work is in.
I am sure there are people out there would like to use zotero with Arabic script but it is not a problem I am dealing with at the moment (and honestly, since Word itself can't deal with RTL script having zotero do it is probably pretty far down the list).
That said, I will leave it to you and try updating zotero again next week.
Thanks again.
The "ar" language tag really does mean "Arabic in arabic script". For romanised Arabic, specify the script with something like "ar-Latn", or the transliteration method with something like "ar-alalc97".
(These suggestions are based on the tagging scheme defined in RFC 5646, and the IANA Language Subtag Registry. Not exactly light reading, but it's the best thing going for describing languages; MLZ is built around it.)
The problem is that in standard Zotero, there is no way to set the language on individual fields, or to register variant metadata for translations and transliterations: you only have one code to work with.
Since actual Arabic records do require special handling in the processor, the suggestion to use "ar-Latn" or somesuch in the Language field is a necessary compromise for romanised records in standard Zotero.
Edit: what I mean is that from what I understand about this, ltr rtl markup should be done by the reference manager, not CSL processor. Am I missing some use cases?