fbennett
About
- Username
- fbennett
- Joined
- Roles
- Member
Comments
-
List imports needs help - I think that's just not working at the moment, but it will get attention soon. I'm thinking about disabling the list-setup-on-install that kicks up the progress meter. It's distracting, and it shifts enough data to be slow…
-
Hi, Jason, sounds like you're having some issues. Thanks for flagging the installer shortcut issue. In my test installs, on Windows, I don't think it was creating a link at all (or I didn't notice). I'll look into it. It sounds like everything is …
-
The formatting of the footnote number is controlled by the word processor. Its formatting can't be controlled through CSL. You should be able to achieve the result your after through the styles settings in Word.
-
Dan: I'll leave the branch in GitHub, feel free to pick bits from it as and when. I won't be touching it further.
-
If the plain-text version is implemented in citeproc-js, it will work after Zotero is updated to that versionThe double-quote syntax was implemented in citeproc-js over five years ago. It isn't something new. (Edit: It's also worth mentioning that …
-
I'm naturally disappointed that the proposal has fallen at the first hurdle, and I'm not in a very strong position to argue the case for it, since I'm obviously invested in the coding. But there are a couple of reasons why I do think it might be wor…
-
You might also consider how you want the sorting of names containing particles to work in the UI.
-
See this thread for further news on the issues discussed here.
-
I've filed pull requests for simplified parsing, and for UI support. Given the number of changes in the offing, we can assume that the team are pretty busy with other issues, but we'll see where we land on the priorities list (and meanwhile, thanks…
-
Thanks to everyone for the latest round of comments. Running the use cases posted by aurimas revealed bugs in the code, so double-thanks there. The screencast has been refreshed based on the latest iteration, and I've added a draft of documentation …
-
Like you say, that's probably an edge case, so I don't think it makes a huge difference, but I think not combining these for a match would be less confusing. While writing out a set of questions, I realized that I don't understand how you want the p…
-
I don't see how that changes anything, though I don't really understand what you meant by mandatory in "The lowercase elements 'ferch de' are mandatory..." above.By that I meant that those lowercase elements in the example are (in the current draft)…
-
(Yes, "von und zu" is in the list. We have very good coverage for Dutch, and pretty-good coverage of the other European domains.)
-
Well, in the current parser. The discussion above is not really taking into account any current implementations, it's trying to figure out what _should_ be the case.Yes, the implementation is just a draft. But if you want to reduce the number of opt…
-
The lowercase elements "ferch de" are mandatory, so the matches attempted with that input would be:van ferch de // then ... ferch deBoth match attempts would fail, so you would be left with the unspecified particle set "ferch de" only, and the optio…
-
Sure thing. Suppose we have the input "de Kamp, John Van", and our correct field content is "Van de Kamp, John". The parser finds "van de" as a matching particle that is always non-dropping, so we offer these options (using your display syntax):Kamp…
-
But that doesn't make sense with what we agreed upon earlier.It doesn't conflict. The point is only that if the user is given the option to lowercase a particle from the menu, they should also be given the option to capitalize it again, since either…
-
I think we agree on capitalization then, given my last remark "we can forgo capitalizing particles that were initially lower-cased", no?Yes, but only for the unrecognized variety. For recognized particles, capitalized options are needed to make the …
-
Is it too aggressive though? I don't think so.It depends on what information you want to derive from the match. The current code limits the number of options presented to the known characteristics of the matched particles. For example "van den" is p…
-
The parse shown in that sample is more aggressive than the current code, which would show only these options for Al-Pitkin, Lemuel Dos:Al-Pitkin, Lemuel (dos) Al-Pitkin, Lemuel dos Dos Al-Pitkin, Lemuel The parsing logic currently runs as follows: T…
-
Could use a single right-arrow, or something else? Open to suggestions!
-
That's the one. Glad to hear it's worked out for you.
-
Yes, it's as Rintze described above—set as if in a citation with form="short" on the left, and as if in a bibliography with form="long", demote-non-dropping-particle="display-and-sort", and name-as-sort-order="true". on the right.
-
I've fixed up the header logic, here's a refreshed screencast. An undecorated list would be more readable in alphabetical order, but I think there may be value in the headers. They ease the user into the terminology that we use for the different fo…
-
If the option is selected, the field content becomes:Al-Pitkin, Lemuel dosSo the headings describe what is happening with the surname—not sure if that's best, but that's what it's doing. It's actually reporting processor semantics, isn't it. I suppo…
-
Ambiguous particles have more options, yes. I've refreshed the screencast with a view that divides the particles by type, with headings.
-
Alphabetizing the list could have unexpected effects, but we can classify it, with headings. I'll try that this evening and refresh the screencast.
-
I noticed that "uit den" cannot be changed into dropping particles. I take it that this is because these are always non-dropping in your list.Yes, that's right; the idea is to restrict the options to those most likely to be meaningful. Is that a cor…
-
I've revised, adopting the comments from Rintze and Gracile, and refreshed the screencast (same URL as above).
-
@Rintze: Coming soon. (I think you meant `demote-non-dropping-particle="display-and-sort"` above.)
Upgrade Storage