How to deal with out of order references in MLA for more than one work by the same author?

At least for MLA in Zotero, multiple works by the same author often end up out of order. The articles in front of the title don't seem to be ignored as they should be when the program determines the order of the references in Works Cited. What I end up having to do is unlink citations before the final version of a document and then manually change the order. And I have to do this with each version I might share/submit. Is there some method/trick that will get around the problem of having to fix the order manually? One can edit the content of references. Can one somehow change order?
  • I'm afraid not. Zotero indeed does not have the ability to ignore articles on sort and you can't move items around in the bibliography without breaking auto-updating. I'm not sure the latter can be made to work reasonably (where would an item be placed that Zotero would originally have sorted between the two?), I hope that we can eventually do something about the former, but not sure when. There are some threads on this, but essentially the biggest issue is how to handle dropping articles in a way that's even somewhat usable across languages. Doing it just in English is easier, but also somewhat problematic. Beyond that, my understanding is that while most style do, not all styles want articles dropped for sorting, so it'd need to be configurable, which means introducing new syntax in citation styles.
  • Ok, thanks. This is one of the biggest obstacles to having a simple Zotero workflow, so I do hope there is a solution in the future. I agree that for any new feature to work across languages and formatting systems, the syntax of citation styles would need to be extended. One way to do this might be to have another title-related field which would contain what one wants the title to be alphabetized by. One would enter "Trouble with Articles" for "The Trouble with Articles." If the field remains blank, the default would be to use the title field. To save work, one could fill in the alternate title only when it is necessary, i.e., to fix out-of-order entries in the reference list.
  • edited August 3, 2018
    Manual sort-by entries for several fields would be nice:
    --Names (sometimes I like to add the original language name, e.g., Russian Cyrillic spelling in brackets after the author; plus issues with particles like 'van der')
    --Dates (for complex/non-standard dates, we could specify which year to sort it with)
    --Titles (to ignore certain words, etc.)
    --Elsewhere others have asked for, e.g., primary vs. secondary sources as, I guess, sort-groups.
    Essentially the 'real' title (etc.) would just be what is displayed, nothing more.

    The downside, of course, is cluttering the interface and having to deal with all of this manually (in Zotero) rather than having it all work out smoothly behind the scenes for us. Yet the current option is just doing it manually for the bibliography in the end (so more work probably). Major changes to the UI so probably no time soon, but good idea @jerryplotnick.

    These could be done via the 'extra' field with custom variables and customized styles, if you wanted to try that. Depends on whether this comes up often enough for you it's worth the effort ahead of time to set that up.
  • I'm pretty confident we wouldn't do this in CSL, sorry. On of CSL's strength is its relative simplicity and the ability to automate across implementations. This runs directly counter to that idea. We need something more systematic.
    Honestly, if people want the ability to do everything 100% even if that requires significant manual fiddling, I'd look at BibLaTeX. It's not what we strive for with CSL.
  • edited August 3, 2018
    OK, this was actually a good test project for me to try to figure out how to modify these styles.

    I have a working version of this, no promises it'll be perfect, but it seems to work for what you've described.

    1. Create a new style based on the standard MLA style, changing the name/ID/etc., so it's distinct from the main one in Zotero, doesn't get updated, etc.

    2. In any entry where you have an alternative title you'd like to use for sorting, add in the "extra" field:
    titlesort:alternative title
    Keep the title like normal in the title field. (This will also work consistently with other styles, or as it has been for the standard MLA style.)

    3. In your new MLA style file:
    Add the following macro, just under the last existing macro:
    <macro name="titlesort">
    <choose>
    <if variable="titlesort">
    <text variable="titlesort"/>
    </if>
    <else>
    <text variable="title"/>
    </if>
    </choose>
    </macro>

    Then find this section:
    <sort>
    <key macro="author"/>
    <key variable="title"/>
    </sort>

    And replace the sort by variable title with macro titlesort:
    <key macro="titlesort"/>

    That should do it, so you can customize what sorts where. You'll have to manually write out the alternative title every time, and this will only work in the custom style. But it'll do what you want, I think.

    Note: I've been told elsewhere that using custom named variables may not be a good idea, but that the variable "annote" in the extra field should work consistently. So you might want to use "annote" instead of "titlesort" in all of the code above. Up to you. The downside to annote, obviously, is that you can have only one custom variable then.
    About that, and where some of these ideas came from, see: https://forums.zotero.org/discussion/67963/other-contributors

    Corrections/comments welcome. I was just curious to see if I could do it.
  • This sounds like a good workaround, djross3. Thanks very much. I agree, that it should work. I've done a very small amount of customization of styles a few month ago and am in fact using a variation on MLA now. In fact, that is a problem for implementing your solution, since I already use the Extra field to place a short version of the publisher where it is needed—University of Toronto Press becomes, as per MLA's style sheet, U of Toronto P. I guess I could just replace what is now in the publisher field with the shorter version, since I don't need both for the purposes of preparing the Works Cited in MLA. But I would lose the flexibility of being able to use those references in other systems. I will have to think some more about all this.

    It would be nice to have more than one type of extra field, even better with customizable names.
  • edited August 3, 2018
    See the last paragraph of my answer above.

    You can in fact have multiple variables within extra, just put one on each line and name them distinctly.

    The only catch is that they might not keep working with updates to Zotero. Use at your own risk unless it's a known field.

    Another workaround is to use known fields that aren't used in the particular type of item. So find a variable you're not using when there's a publisher, like journal abbreviation, and that could then fit your purposes, for example "container-title-short" might be available.

    To figure out what variable names might be available, see:
    https://aurimasv.github.io/z2csl/typeMap.xml
    You'll use the CSL (not Zotero) names.
  • Many styles use the short container-title. Short titles are called using variable=“title” form=“short”.
  • edited August 3, 2018
    Do you mean that it would be in conflict with something else?
    This is distinct from "short title" in reference to the title of the actual entry. "container-title-short" refers to, e.g., the journal abbreviation, not the article's title in short form. I don't see it in use for book chapters, or books.
    I did say something that didn't make sense (mixing up which fields we were talking about semantically), so I just edited my post above to make sense. That field should still be available though. There's no other obvious 'short-publisher' though.

    Note that a (short) publisher would (probably) only be needed on non-journal entries.
  • container-title-short would be rendered any time a style use
    <text variable="container-title" form="short"/>
    which is not uncommon.
    See the description of the variable:
    http://docs.citationstyles.org/en/stable/specification.html#appendix-iv-variables
  • (You really don’t need the warnings about variables in Extra. The zotero devs have indicated that CSL variables in Extra will be migrated when proper fields are added, and the method for storing extra CSL variables there is well-established and not going anywhere. There is no “risk”.)

    Many styles use short container titles (e.g., journal abbreviations), so that is not a good choice for storing variables that are not short container titles—it is highly likely to yield unexpected results.

    CSL has no concept of a “short publisher”. Only names and titles have short forms.

    My recommendation for short publisher names like this for the time being is just to fix these as the final editing step in finishing a document (e.g., Find and replace “University of” with “U. of”). There is a plugin to handle complex abbreviation rules for cases like this (Abbreviations Filter), but it does not currently work in Zotero 5.0. It does however work in the community-developed version of Zotero for multilingual and legal work— Juris-M. If automating this type of abbreviation is very important to you, you can check out Juris-M.
  • I think this might be quite useful for me, but I'm starting to get mixed up about who's talking to whom or what I should do.

    Am I understanding right that there are two ways of setting up variable names in a macro: (1) using an existing name that corresponds to an existing variable one isn't likely to be using, (2) inventing a name that Zotero doesn't use (and then hoping it doesn't get used in the future in a way that messes things up)?

    I would use the tables in https://aurimasv.github.io/z2csl/typeMap.xml in either case.

    I would need to make sure the appropriate prefixes followed by colon space appears in the Extra field for the two cases (short title and title to sort by).

    If this is close to being correct, I'm not sure what the recommendations are for variable/macro names, if any.
  • @jerryplotnick sorry for the confusion. I'm just figuring out how to do all of this myself, and the others are correcting me. So if my ideas are useful, please go ahead and use them. But defer to the technical details and corrections the others are giving because they know a lot more than I do.

    The code I provided above works. We're just discussing what variable names make the most sense (and best practice in general), especially if you have multiple custom variables you want to use.

    Yes, exactly, you can either use an existing name (if it isn't going to conflict with something else) or make one up. There are trade-offs, see below.

    Yes, what you wrote sounds correct to me.

    --

    @adamsmith oh, OK! I didn't realize it was automatically used in that way. So that's not the right one to use.

    In that case, I don't see an obvious default variable to use, so I'd suggest just making one up, or using annote (but that's only one, and Jerry needs two).

    --
    @bwiernik :
    (You really don’t need the warnings about variables in Extra. The zotero devs have indicated that CSL variables in Extra will be migrated when proper fields are added, and the method for storing extra CSL variables there is well-established and not going anywhere. There is no “risk”.)
    This is important and helpful to me. Are you saying that ANY custom variable names are safe to use? Can I make up any random one I choose? In that case, I'd much rather use "titlesort" in this example than "annote".

    In another discussion ( https://forums.zotero.org/discussion/comment/313724/#Comment_313724 ) @adamsmith wrote:
    I'm honestly surprised this [a custom variable name in extra] works and there's no guarantee it'll keep working if you use a custom variable, though it's also not super likely it'll break. annote will definitely keep working, though.
    @bwiernik, do you agree or disagree with @adamsmith there? Is that reliable or not? If it is reliable, then I'd much rather use custom names that would never possibly conflict with what is default in CSL. (Of course other times you might want to use names to predict future standards, but that's a different case than the current discussion I think. Easy to fix later anyway if needed.)

    And yes, Jerry, I would second bwiernik's recommendation to manually filter publisher abbreviations after the fact, if you only choose to fix one at this time. The sorting issue is a legitimate problem you don't want to have to do manually because it really does entail a lot of work that could be automated. But publishers could be polished later if needed. (Again, I don't see why you must choose only one if you want to use two variables, but if it's one or the other, I'd say sorting should have priority.)

    --

    I hope I've clarified things, and I'm sorry to have made them confusing in the first place. I'm a novice as well, just trying to be helpful, but in the process being confusing too.
  • edited August 4, 2018
    1. Don’t make up non-CSL variables. This isn’t a supported practice and won’t work reliably (I didn’t even think this was possible—if it is, it is a very recent change to the processor and not an intentional one.)

    2. You can use any CSL variable. Refer to https://aurimasv.github.io/z2csl/typeMap.xml to see how Zotero fields are mapped to CSL types
  • edited August 4, 2018
    So what do you recommend when you want more than one variable (annote is good for one) that don't conflict with any existing CSL variables? Let's say we'd want it on all item types.

    1) Might not work*
    2) Might conflict

    ...any option 3?

    [*Yes, it works just fine now with whatever I want to call it. It's possible there are some limitations but I haven't found them.]
  • Call number, keyword are basically never used. But you are getting way outside of what CSL is designed for.
  • edited August 4, 2018
    1. Why use something that is semantically for a different purpose for something that is obviously different? Isn't that just as wrong or more wrong than custom variables?

    2. CSL is designed to make bibliographies. It should gracefully allow customization when it lacks required features, like the actual requirements of MLA style discussed here.

    Custom variables are a perfect compromise between standard functionality and power for users who need something else.

    I'm now hesitant to actually do that, because it seems like we're being given only square pegs, yet need to fill round holes, and we're not "supposed to" put those square pegs in the round holes, even though they fit. Not sure what to do.

    (Your advice and caution is appreciated, my complaints are not directed at you or others personally at all!)
  • As I have mentioned before, the square-peggishness of CSL is on purpose and part of its success story. Without standardization, I don't think you can write a tool that works for >30 different applications and offers >1000 different styles for those. There's a trade-off between that breadth on the one hand and flexibilty as well as the ability to get every little detail right on the other. We're constantly thinking through ways in which we can get _more_ things right, but won't do so while sacrificing our other goals.

    You're looking at CSL as the user of one style in one language using one reference manager. As a maintainer of the project, I have to take a broader perspective.
  • I completely agree with all of that!! Really, I do.

    But that's what customization is for. I'm not suggesting my custom variables should be shared with others (unless they want to copy my personal modifications).

    The whole point is that a single tool out of the box isn't going to work perfectly for everyone, so why not allow custom variables in case some of us need to control something that isn't accounted for?

    Zotero, CSL, etc., are great, but there are some things they can't do. They can't even sort titles for MLA properly. And it absolutely makes sense for that. But then you'd rather custom variables be blocked?

    Once I started poking around in the code, the most exciting thing I found was that customization via "extra" was possible (including custom variables). This means that the responsibility for having a perfect citation manager for me can now be in my hands, while the main software and developers can continue not worrying about small issues that I or others have.

    I'd hope that in a sense this would be a relief for the developers, rather than a burden.

    To me, this opens up so many possibilities, it's great. Just as one hypothetical, imagine someone wanting to generate a list of films who happens to want to add their reviews (1-5 stars) at the end of each. Just add stars: 3 to the extra field, and add one line in a custom style. Easy, and powerful. I think it's great!

    Again, sorry for going on about this. But I love this option, and feel it would be a real disappointment for it to go away. Standard Zotero works great, but for anything else I need, now it's easy too.
  • They're not blocked (obviously -- they work), but parsing anything that's followed by a colon in CSL note (i.e. Extra in Zotero) as a custom variable is rather fragile and may have a host of unintended consequences, which is why we're saying it may just stop to work in the future, e.g. if we have to address any such consequences or if it has negative performance implications. Also, you're now using non-validating CSL styles and I'm reluctant to promise those are going to keep working in the future or convert properly if we update CSL in a non-forward compatible way.

    I believe Zotero is thinking about custom fields which would presumably allow for some ability for custom mapping to citation styles, but there are a lot of things that can go wrong with that sort of thing and require careful design (how does syncing work, how to handle collaboration between people with different customizations, how to allow export of customized variables, etc.), so I don't expect that to go quickly.
  • edited August 4, 2018
    It seems the risk is outweighed by the reward here, with awareness that a future release might require redoing custom tags.

    Yes, an official version of this would be great, but if this works, then I'm really in no hurry for that. I genuinely see this as a way to find a balance between standard but limited Zotero and individual needs.

    Personally I'm going to try to stick to just using one tag, which can be standard "annote", so hopefully it won't ever break. But if I need another tag for something special, I'll probably use a custom one.

    Thanks!

    (And, no, it's not currently blocked, of course. But as far as I can tell the only way to allow extra to have real CSL variables but not others would be to have a whitelist of allowed fields and explicitly block the others. I hope that doesn't happen. I mean, someone would have to decided to stop me and others from doing this, if it fails to work, unless the system is changed substantially, like removing "extra", etc.)
  • I say this a very naïve—or at least still relatively inexperienced—user of Zotero, but I have to say that I am quite sympathetic to what djross is saying. There needs to be some way of giving users the best of both worlds: standard features and the ability to customize without breaking things. And these user-defined variables seem to be able to solve genuine problems for individual users. That said, adamsmith is no doubt 100% right about the need to think through customization in light of all of Zotero—rather than baking in something that might work 90% of the time. We can ask no less of those responsible for the program. Anything permanent should—leaving aside bugs—be in theory 100% robust. Right now, I'm leaning toward what appears from the discussion to be the small risk of future difficulties and defining two variables that make semantic sense. The only thing holding me back right now is having to sift through all of my non-empty Extra fields and redoing them. I don't think there are too, too many. I recognize that at some future date, though, I might have to repeat this exercise—if and when Zotero changes how it handles variables. No great solutions right now, it seems.
  • I have a question indirectly related to these issues.

    If do implement these two variables, then I will end up with a file on which I could continue to work later on with all of my Zotero citations intact.

    What are best practices for sharing Zotero files with non-Zotero-users? Is it a good idea always to unlink first? Or is it reasonably safe to pass on a Word document with Zotero citations intact?

    The advantage of leaving Zotero citations intact is that one can keep a Track Changes conversation going over multiple edits without losing the capacity to add and remove citations with Zotero.
  • edited August 5, 2018
    Yes, I think we're on the same page regarding customization vs. standardization, and I also agree it's important to make sure none of that ends up causing problems for standard features. Hopefully this can all work out together.

    As for going through your library you should be able to do an advanced search > More > extra, and then match it for contains %. That should bring up all of the entries with extra fields (including for me a number where the automatic import of metadata added something random in there, which you might want to clean up). Even if you end up only using one value, it would be good to preface it with "annote" (again, that's a safe variable to use), so that: (1) it's not just the whole 'extra' field you're using (in case, as above, an automatic import brings in some other extra info there) or you want to add a non-standard field for a different (standard or not) variable; and (2) you can easily/conveniently search for "annote" after that which I imagine is a unique word not found in other entries!

    As for your question question about sharing files, I've done that quite a bit and I usually remove all fields in a separate copy that I send to them (keep your original!), simply so it looks clean to the reviewer/reader. In that case, it means I need to manually carry over any edits (after track changes), but that's a good thing so I can confirm any suggestions as correct, but the process is a bit slow I admit. On the other hand, if you're collaborating with someone, as long as they don't touch the Zotero fields themselves, sending the original document should be OK. But I've always worried a little about the possibility for corruption especially if, for example, the versions of Word differ or something-- I'd assume it's more on Word's end than Zotero's. Anyway, mostly it seems to work. As for the details of sharing a file and collaborating via Zotero (related also to your question), I just found out about that myself in the three posts here: https://forums.zotero.org/discussion/comment/314013/#Comment_314013
  • It’s generally safe to send documents with Zotero citations to co-authors, etc. and let them work with it. The one thing I would recommend is to tell them to not edit citations at all, but instead to make any such edits in comments and you can make them yourself later.

    I recommend that when you actually submit the paper to a journal, you unlink citations to avoid publisher processing systems potentially making the Zotero formatting codes visible (while rare, there are a few examples of Zotero and Endnote codes appearing in published papers).
  • Thanks very much, djross3, bwiernik, and adamsmith for all the clarification and advice. I’ll hope for a well-thought-out and robust implementation of more user customization in the hopefully not-too-distant future. If I may add just a couple of thoughts . . .

    1. This customization would benefit more than just the handful of users who are willing to get involved in the nuts and bolts of CSL. It should in principle lessen the need for customization, because the people who create the CSL styles would have the tools to address the glitches that have arisen from Zotero’s current limitations.

    2. Some if not most of the current limitations of standard styles could be dealt with simply by adding the necessary field. I understand the need to avoid an explosion of fields, but there should be easy ways to customize at the user levels which fields are visible and which aren't.
  • Especially for (2), this is why I'm so strongly advocating allowing custom fields. Then we can do whatever we want, and the developers don't need to be spread so thin dealing with everyone's individual needs.

    That doesn't replace the need for expanded functionality like for example eventually supporting smart sorting of titles for MLA, but it can make the wait much smoother.

    For (1), you're right about people not wanting to get into the code. However, the custom fields are one of the easiest changes to the styles (assuming what you want within the style isn't especially hard to code). For example, sorting by an alternative title field is just changing a single variable in the style. It's hands-on, but it's like sticking a toe in, not diving into the deep end.
    (It would also be possible to automate this in a relatively simple way: allow a "sort" version of [almost?] everything, and a "short" version of [almost?] everything, and then sort by default on the 'sort' version if filled.)

    As for having too many options in the UI, I think there area already too many in some cases, so to solve that I'd love to be able to hide some (unless already used, and otherwise available via a dropdown in case I want to use them). As I can example, I just spent about an hour going through and removing all of the entries (automatically populated from imports) for "Journal Abbr" because (1) I don't use them; (2) 95% were just identical copies of the full journal name; and (3) if I wanted to ever use this feature I'd need to go through and do it myself manually for consistency. However, I know that many other people do actively use those fields. So giving me the ability to hide them and others to use them would be great.

    Anyway, glad I was able to help. Just figuring this out myself, sorry for some of the confusion, especially about best practices for naming variables!
Sign In or Register to comment.