Upgrade StorageAbbreviate author "Philip" into "Ph."
How would you do to have the first name of an author named "Philip Something" abbreviated into "Ph. Something" (rather than "P. Something"). How to tell Zotero to consider Ph as a single-letter when using abbreviated author styles?
I am coming from the BibTeX world where this could be done with a dummy command like author = {\singleletter{Ph}ilippe Something} where \singleletter does nothing else than outputting its argument but let BibTeX thinks that the whole \singleletter{Ph} is the 1st letter of the word. In this way, both the full name and the abbreviated name can be correctly generated by the style.
This may seem a bit futile in the case of Philip but:
- I know a Philip whose personal preference is to have "Ph." and I think this should be respected.
- Case like Philip St. John Russell pose a different problem since you certainly don't want St. abbreviated as S. But maybe entering a multiple letter initial like St. in a first name field tells Zotero to keep it that way (haven't tried). But for the Philip guy, sometimes I want the full name.
Any idea? Is that a feature request?
I am coming from the BibTeX world where this could be done with a dummy command like author = {\singleletter{Ph}ilippe Something} where \singleletter does nothing else than outputting its argument but let BibTeX thinks that the whole \singleletter{Ph} is the 1st letter of the word. In this way, both the full name and the abbreviated name can be correctly generated by the style.
This may seem a bit futile in the case of Philip but:
- I know a Philip whose personal preference is to have "Ph." and I think this should be respected.
- Case like Philip St. John Russell pose a different problem since you certainly don't want St. abbreviated as S. But maybe entering a multiple letter initial like St. in a first name field tells Zotero to keep it that way (haven't tried). But for the Philip guy, sometimes I want the full name.
Any idea? Is that a feature request?
Frank Bennett
A more troublesome (and practical) issue is proper nouns in titles.
[ it should be stored separately it seems to me. ]
And what do you mean by the above? [And how do you quote things from the forum with a nice dashed box??]
The last comment on proper nouns in titles is indeed a similar issue (protecting capital), like "Stimulated Raman scattering".
I must add that it is not just capitals that need to be protected. Units in titles should be somehow protected as well. "A 720 nm laser" should NOT be title-cased in "A 720 Nm laser". Here "nm" stands for "nanometer" whereas "Nm" would be "Newton times meter", which is a torque (I am a physicist, sorry). I haven't seen any discussion on this yet. Some case would be ok. I guess both "km" and "Km" are accepted.
I would support something simple and common to handle all those cases. Like putting things in between curly braces, e.g. (idea from BibTeX of course, but you might have other things in mind). Then we could have
{Ph}ilip Something
Stimulated {Raman} scattering
A 720 {nm} laser
You may say it looks ugly but then what else could we have? Mouse-Select a part, right-click, context menu "Protect case" or whatever seems a little bit cumbersome for me. I would prefer some mark-up. And the mark-up could actually only show up when you click on the field to edit it, but be otherwise invisible.
Finally, I have seen some case where a paper is authored by D. Knuth (and written as is in abbreviated form on the paper), but then you know that the guy is actually Donald Knuth, so BibTeX recommends encoding "D[onald] Knuth" so the system knows that the author was abbreviated on the paper. Some styles insist that you should write the authors as on the paper, sometimes abbreviated, sometimes in full, in the same reference list, depending on what was on the paper. But then some other style might need to be sure that D. Knuth and Donald Knuth are the same person.
Anything like that in the thought basket? Note that I am not much concerned about that case. It's just related to the Ph. problem so I thought I would put it here for completeness.
<BlockQUOTE>quoted text</BlockQUOTE>
... This is just a UI question. I'm concerned with the cleanness of the data behind it. There are many ways to deal with the user input, and perhaps a distinction between the wiki-like markup and the contextual-menu approach, where both yield more-or-less equivalent results internally, is the right approach.
... To me this stuff is just silly. An author is an author, and how their name should be output is a product of the output style. As a practical matter, contributors should be treated as full data and UI objects, not as strings. This allows them to be referenced, and for additional data (addresses, affiliations, etc.) to be attached to them.
This isn't BibTeX, and that's a good thing.
To be honest, I think Zotero is a fantastic product. It has really changed my life as far as collecting refs in journals is concerned. I certainly don't want to impose all the BibTeX idiosyncrasies on Zotero and I totally understand the will of the development team to keep it as general as possible and to not focus on any particular system, whether LaTeX or others.
However, despite all the oldness and limitations of BibTeX, it nevertheless constitutes a system that through many years (2 decades?) has been able to handle all sort of complicated and tricky cases with relative simplicity and pretty much without evolution, and yes, even silly requirements of publishers. There is certainly some good ideas in there that could be borrowed and adapted for Zotero somehow. You may think of the D[onald] example as silly, but if a journal comes with such requirement, you will have to find a way to do it. Manual editing the final ref list is always a possibility, but you want to keep that to a minimum.
You will never think of all what the users could have or will have in mind, and how they will try to use Zotero for unplanned purposes. So the system should stay open-minded.
In my experience, there's more flexibility on these issues than people assume, and that as a general rule, it's never wrong to put in more information than is strictly required. Not if it causes other problems elsewhere. This is a perfect example. Treating contributors as dumb strings has other costs.
BTW, I'm not a Zotero developer exactly; am the author of the citation style language it uses for formatting configuration.
I'm also a publishing scholar, and a former BibTeX user who found it inadequate ;-)
For the other sub-field formatting issues, I hope that an accommodation can be reached about in-field wiki markup for use in Zotero. Unless there is a more robust and visually appealing solution on the stocks that I haven't heard about, it seems the only way to address some very common user concerns in the short to mid term.
I'm concerned with a solution that works not just for low-level output, but for data storage and import/export, search, display (particularly on the web), etc. It seems logical that (X)HTML is an important part of that picture, since it has more low-level formatting structures, but also has higher level semantics (the class attribute, and more recently the ability to embed RDF triples via RDFa).
But that doesn't mean a wiki markup shouldn't be one way to achieve this sort of micro-formatting.