'literal' fields such as 'location' do not honor <pre>.

[Dabsen]

Bib(La)TeX supports multiple locations and publishers by treating locations and publishers as arrays, that is as lists of items separated by "and". (This is useful because many big publishers are now based in several cities and some books list two publishers or more; moreover different languages and different styles handle these situations differently). Zotero, however, does not support this (see for instance this discussion). This post is about trying to use BetterBibTeX to go around this limitation.

Now, the goal would be, given for instance the two locations Malden, MA and Berlin, to get location = {Malden, MA and Berlin} or better location = {{Malden, MA} and {Berlin}} as BibLaTeX output.

The reason this is not straightforward is because Zotero and BetterBibTeX enclose the publisher and location fields in double braces upon export. So if the place field of a Zotero entry is "Malden, MA and Berlin", it gets translated as location = {{Malden, MA and Berlin}} and therefore BibLaTeX treats this as a single location and not two. This is probably reasonable, particularly for the publisher field, because some publishers have "and" in their names (also, perhaps some styles would mess with the capitalisation of "MA" or acronyms like "MIT Press" without the double braces).

My first idea was to enclose the Zotero field values in <pre>…</pre> but BetterBibLaTeX still encloses whatever is inside these tags in double braces upon export. I am not sure whether this is the intended behaviour or a bug (in which case I can file a separate bug report).

So I resorted to the following postscript to get the desired output, choosing "; " as separator between different places and publishers, like this:

if (Translator.BetterBibTeX || Translator.BetterBibLaTeX) {
  this.add({ name: 'location', replace: true, bibtex: '{{' + this.item.place.replace(/; /g,'} and {') + '}}' });
  this.add({ name: 'publisher', replace: true, bibtex: '{{' + this.item.publisher.replace(/; /g,'} and {') + '}}' });
}

Is there no cleaner way to do it?

[retorquere]

As long as Zotero only has one publisher field, getting the output you desire is always going to be hackish. That said, the <pre>...</pre> way should just work. Can you right-click that reference and submit a debug ID?

[Dabsen]

Thanks for the quick reply. The ID is 8EJINZXC. With the field <pre>Basel and Boston and Berlin</pre> I get the output location = {{Basel and Boston and Berlin}}. Adding more braces does not change anything: the exterior {{ }} stay in the output anyway. The publisher field behaves in the same way. NB: Of course I removed my postscript before producing this debug ID.

[retorquere]

Hmm. The location field is a literal field -- the way that's been encoded so far is by adding double braces around the whole field. That's not a simple behaviour change -- it will require rethinking how literal fields are handled in BBT. This will have to wait until I have the Z5 port done, sorry.

[njbart]

FWIW, just a reminder that in biblatex location is (not a literal field but) a literal list.

From the biblatex manual, ver. 3.7, section 2.2, “Entry Fields”:

Literal lists are parsed and split up into the individual items at the and delimiter but not dissected further.

[retorquere]

Ah yes, that's correct (natch). But in this specific case, since there is only one entry (as Zotero only has one place field), the outcome would be the same.

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 4716 ("new tags format").

[retorquere]

OK, so 4716 adds an exception to markup processing such that fields that are wholly enclosed in <pre> tags are not to get further braces. Previous markup processing treated <pre> as ways to do partial escapes and assumed the <pre> chunks would be embedded in text that would still require bracing.

"place": "<pre>Basel and Boston and Berlin</pre>",

from Zotero is now translated to

location = {Basel and Boston and Berlin},

This affects all fields, not just literal fields -- if you wrap the whole field in <pre>, BBT assumes you know what you're doing. I am sure edge cases can be found, but I'll deal with them as they are found -- all other test cases are currently unaffected, so I'd propose just merging this. BBT5 has been released BTW. Everything but ScholMD has been brought over. The ScholMD stuff needed rethinking anyhow, and I'm not sure it has much traction in editor support right now.

[Dabsen]

Great. Thanks. This behaviour sounds reasonable. Will try it as soon as I have a few hours to migrate to the new version (I was waiting for BBT to be ready).

Le 13/11/2017 à 11:08, Emiliano Heyns a écrit :

OK, so 4716 adds an exception to markup processing such that fields that are wholly enclosed in <pre> tags are not to get further braces. Previous markup processing treated <pre> as ways to do partial escapes and assumed the <pre> chunks would be embedded in text that would still require bracing.

"place": "<pre>Basel and Boston and Berlin</pre>",

from Zotero is now translated to

location = {Basel and Boston and Berlin},

This affects all fields, not just literal fields -- if you wrap the whole field in <pre>, BBT assumes you know what you're doing. I am sure edge cases can ben found, but I'll deal with them as they are found -- all other test cases are currently unaffected, so I'd propose just merging this. BBT5 has been released BTW. Everything but ScholMD has been brought over. The ScholMD stuff needed rethinking anyhow, and I'm not sure it has much traction in editor support right now.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/retorquere/zotero-better-bibtex/issues/689#issuecomment-343871749

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 4748 ("Merge branch 'master' into 689").

[blip-bloop]

:robot: this is your friendly neighborhood build bot announcing test build 4814 ("Merge branch 'master' into 689").

[retorquere]

I appreciate that you must be very busy, but with fixes piling up in potentially divergent code paths, the merges become harder and harder for me.

[Dabsen]

Sorry about that. It had to wait for the week-end (I was scared to do the migration to the new Zotero/the new BBT without some time ahead to make sure everything was backed up and to solve any issues which might arise). I can confirm that the export works as expected with the test build. Thank you very much again for your help on this.

Le 18/11/2017 à 13:16, Emiliano Heyns a écrit :

I appreciate that you must be very busy, but with fixes piling up in potentially divergent code paths, the merges become harder and harder for me.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/retorquere/zotero-better-bibtex/issues/689#issuecomment-345438552

[retorquere]

Alright, thanks for the confirmation, will be in the next release in a day or so.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.