Improve the compatibility of setExtra

[jiaojiaodubai]

This is a change submitted to advance zotero/translators#PR3417, and has not been tested locally, but it should be working well.

• Support calling Zotero.Translate.Base.Item.setExtra in itemDone handler
• Allow setting multiple CSL name variables (e.g. original-author) with the same field name via setExtra

[jiaojiaodubai]

According to Zotero's documentation, it seems that the field names in extra prefer to use title capitalization (although this is not explicitly stated), but I personally prefer to maintain original kebab-case described in CSL document, so I added support for two naming styles in the code.

[jiaojiaodubai]

@AbeJellinek @dstillman Hello, please take some time to review this PR. 😢🙋‍♂️
I have a lot of work blocked here. Abe asked me to stop using my Extra class in translator (It's heavy, honestly), but current framework does not provide such methods to allow me to get value from extra or set multiple values with the same field name, like original-author.

By the way, why I stick to using fields like original-*? Because some Chinese citation styles require that both the Chinese and English information of item shhould be displayed in the corresponding bibliography entry, Zotero neither has item fields that are exclusively used for multilingual information like Endnote, nor provide something like "multilingual copy of target item". We can only play tricks on extra to meet these practical needs. 🤷‍♂️

[dstillman]

Just to clarify, how necessary would this be with proper fields? Because we're in the process of adding those for Zotero 7.1:

https://forums.zotero.org/discussion/121656/coming-soon-new-item-fields/p1

And once those are added, we obviously don't want to still be adding rows in Extra.

[jiaojiaodubai]

Because we're in the process of adding those for Zotero 7.1

I have been following the discussion.

And once those are added, we obviously don't want to still be adding rows in Extra.

Yes, it is beneficial to add some common fields. It is not easy for most users to accurately enter CSL fields in extra without UI prompts.

Just to clarify, how necessary would this be with proper fields?

Strictly speaking, it is unnecessary to add fields like original-author.

According to CSL document, fields like original-* are not designed to record translated multilingual fields. original-author may be used in situations like this, where someone wrote a book but did not publish it, and another person took over to improve and publish it. Abuse of original-* by Chinese community is just an expedient measure — otherwise, they have to manually compose bibliography. I don't know whether anyone needs these fields in other cases, but in my case, it is unnecessary to add them to the item fields.

If there is any advantage in adding original-author to item fields, it is that duplicate field names will no longer appear in extra, and access may be very convenient.

[jiaojiaodubai]

Broadly speaking, to fully address the challenge of outputting bilingual bibliography, aside from number fields and date fields, other text fields written in specific languages require a designated place to store their multilingual values. The standard fields in CSL are insufficient, and it is not necessary to add multilingual versions for all text fields.

A good idea is to create duplicate item, modify the multilingual fields, specify language field, and then link them as "multilingual" relationships (similar to related items). Finally, in CSL, use xml:lang or locale attribute to specify witch bilingual item's value should be output (by default, output the value on the item witch locale field has not been set or has been set as the same value as default-locale style option.). However, this requires modifications to both the data structure and the CSL engine. Making such significant changes for rare requirements may not be acceptable. 🤷‍♂️