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.

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.

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.

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.

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.

(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.

@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.

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.]

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!)

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.

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 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.

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).

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!