this can't currently be done - will be in the future, though.

Actually, there appears to be a problem with this:

"2018a" and "2018b" become "2018A" and "2018B", when there are multiple publications from the same author in the same year.

It's somewhat bizarre that "capitalize-first" is targetting a non-initial character, but I guess it's the first letter. This seems like a bug.

Suggestions are welcome. For now, I guess the change above may not be a full solution, just trading one problem for another.

--

One alternative seems to be converting the in-text citation date to lowercase, and writing "Forthcoming" in the Zotero entry. (That assumes you would never need capital letters in the citation date-- maybe if you wanted "N.D." or something? But that seems unlikely, less than "2018a" at least.)

1. "Status" is awkward to use as extra.
2. Among even the default styles, only APA and Chicago support this. Inserting text works in all styles (as far as I know).

I am running into what add up to unfixable problems (really frustrating, because it's so close) so I think I'll give up, but this would be a simple solution, while the much more complicated version has been under discussion for about 10 years and yet to be implemented.

Another problem I noticed is that "forthcoming-a" and "forthcoming-b" won't work. I don't think that's solvable with "status" either. So however we approach this, there's really no way to do it right.

Back to flagging all of the forthcoming entries for manual corrections.

Your help is appreciated, even though I'm frustrated for technical reasons.

Interesting! That also seems to work for different non-date text entered in the date field. That means that somehow the parser actually does know what's being used as a date ("forthcoming"≠"in press"!), even though it can't sort based on it. How odd.

I'm still hesitant to poke around too much in the code because I don't understand how all of this is connected. Your comments are very helpful.

Huh. Interesting to look at, but doesn't answer why it's sorting the way it is (that data doesn't seem to end up in the Word field codes).

What I see for a date is like this:
"issued":{"literal":"forthcoming"}

So what seems to be happening is that Zotero is bypassing that entirely for sorting. And the actual display form (for example, if capitalized, or if "-a" is added) is not shown either. That's just the original value. Still not exactly sure where all of the information is.

(Actually, what I suspect is something like this: There was an older thread discussing 3-number dates like the year "800", which were not being sorted correctly versus "1200". In order to fix that, I'm assuming a date format was forced by Zotero, bypassing the literal string. This then would be one of the sort of unfortunate compatibility issues that comes up from a patch like that.)

Well I've gone about as far as I can with these things for now. Even if I switched over to the status method, I wouldn't be able to fully update the Linguistics stylesheet on my own I don't think. So I'll just plan to manually edit these. It's been interesting looking under the hood, so to speak.

it's getting capitalized when it gets renderes as part of the year, on which you're applying capitalization rules, but not if you're rendering it as a separate variable (which exists as an option specifically so you can add styling like italics etc. to the year suffix as needed)

you could try to set the formatting of the date conditionally on If is-numeric=“issued”,

no, I'm pretty sure that's always false, so won't work.

Thanks for the suggestions. I think this is close enough now, with manual touch-up required.

Honestly, the most appropriate way to do this with CSL is not store words in “issued” at all and to use “status” for such descriptors (e.g., see how APA does this).
If/when all styles do it that way, it would be workable. Until then I'd rather have the somewhat broken text in the date field so it at least half works in all styles. Having style-specific information in the entries seems like the wrong approach at the moment. But I completely understand why you're in favor of that approach-- it's a trade-off currently.

And yes, is-numeric doesn't seem to do anything about dates (vs. text, etc.). What would be needed is "is-date", or of course some way to actually test values.

I don't disagree. But that's not my motivation:

I'm avoiding "status" because it isn't supported in OTHER styles. If an editor asks me for a paper in some other style, I don't want my forthcoming dates to disappear-- I'd rather correct them manually.

I'm using a single style, patched (yes, somewhat awkwardly) to best handle this, and also to help me identify any other issues, either in that style or for others, so I can manually correct them.

Currently:
1. "status" works only in a handful of styles, for others it is completely ignored.
2. Non-numeric dates half work in all styles (with manual correction required).
3. Non-numeric dates work even better than that in the personal style I'm using.

Plus, "status" isn't a default field in Zotero and there is no indication that by writing it in "extra" that information will be carried over into new citations once the date system is replaced. So when that happens, either way, we'll need to change how we're approaching this. (The handful of styles (or maybe more by then) that do work with "status" will continue to work with the new system, though.)

Finally, I am generally opposed to the idea of using "style" rather than non-numeric dates because that information ("forthcoming", etc.) is a date, so that, for example, it should be exported as such, rather than moved into some additional "status" category that might not work when importing my Zotero library into other software if I ever decided to change, or if I wanted to export and send to someone else for a project.

Again, your reasoning makes sense, but it's a trade-off-- is the glass half full or half empty. I call it half full. Your warnings, however, have made me aware that I need to do this carefully, and probably at some point my library will have some compatibility issues to fix, so I'll watch out for that. It's appreciated.