Upgrade Storagefbennett
About
- Username
- fbennett
- Joined
- Roles
- Member
Comments
-
Speaking from the MLZ corner, it would be good to save the term "multilingual" for (currently CSL-m) styles that render in multiple locales.
-
There are good reasons for keeping the processor's list of parsed strings as compact as possible, so the processor behaviour should remain as it stands. While it would be possible for the RTF/ODF Scan plugin to normalise strings embedded in the loc…
-
It's in the processor sources: https://bitbucket.org/fbennett/citeproc-js/src/6991e152732e83dde218c06df3a3236caf6471c4/tests/fixtures/local/multilingual_LocalisedNameDelimiters.txt?at=default Can be moved to the CSL test repo after the spec ame…
-
"A minute or so" is probably an overstatement. I was thinking of this old thread, which was mainly about a UI issue long since addressed: https://forums.zotero.org/discussion/6929/crash-when-loading-really-large-author-list/
-
This bug fixed now in the patch plugin: all 336 authors in the test item will now show. You might want to consider applying some level of et-al cutoff in the style though, since there are now no constraints whatever when et-al-min is absent. (The At…
-
(I've amended the test slightly, to remove an intervening space from "L'Familyname" -- the link above now points and the revised version. The "L'" particle then fails to parse, so I've added it to the list of suspects in the comment.)
-
In the test, recognized particles receive separate markup (boldface for non-dropping particles, italics for dropping particles). "La" is recognized, so it has separate markup. "Pietro" is not recognized, so it is in the same boldface span as the fam…
-
That would be great. For reference, I've prepared a test that covers the particles in Charles' list, plus the 't case: name_ParticlesDemoteNonDroppingNever. The result segment of the test shows what the processor actually produces in the current re…
-
There is a scattering of tests related to particle handling, but nothing yet that checks a list of candidates. It's been rather ad hoc. Thanks for catching that regexp bug. It looks like I was using group matching, and then changed it to a characte…
-
Here's the code: non-dropping particle dropping particle Read it and weep. :-)
-
(Oh wait, sorry -- clarity again. The link above is to the list of particles provided by Charles Parnot. At present, citeproc-js uses regular expressions to identify particles.)
-
Sure thing. It's here.
-
I wasn't completely clear, sorry. The question about dropping vs non-dropping was just a point of curiousity. It's not hard-coded in the processor, and both cases will now be handled for particles that contain apostrophes. In the sort question, the…
-
Hmz. I'm getting this sort order in a test with demote-non-dropping-particle="never": Frinkle, B Horvath, P A B in ’t Horvath, P A A ’t In ’t Horvath, P A D Klabdaggit, M ’t Horvath, P A C Vooz, B This follows the CSL 1.0.1 specification. We may ha…
-
I have a fix for this, which I'll release tomorrow. The CSL archives have a list of name particles contributed by Charles Parnot of Papers. It is not a complete list, but does show "in 't" as a dropping particle. Out of curiousity, is 't a dropping…
-
I'll confess that this possibility had never occurred to me. I'll see what can be done.
-
Looks good, the site has been updated as well.
-
@adamsmith: What's coming out wrong?
-
Dan: Thanks for this. It's a much, much cleaner fix than the one I proposed in the tracker.
-
@paultoop: No worries, it's a small quirk in the ODF scan workflow. On the initial ODF conversion, the codes are set as "in-text" references, so things go a little weird with a footnote style. Switching to another style and back brings things right.…
-
@paultroop: On the backreferencing issue, if switching to another style and back does not resolve the problem, please start a separate thread for it so we can focus on just that.
-
I went ahead and implemented what I think is intuitive matching behaviour (in MLZ 4.0.14m425). A single-element language code ("zh") will now match all of its sub-locales, and when in first position on the @locale attribute to cs:layout, it will map…
-
We probably do want to be able to specify "zh" as applying to all "zh" language tags at some point. Some of the European languages have bazillion local variants, only a few of which might affect the locale used for terms. In that case, specifying al…
-
Yeah, locale management is tricky. A base locale is resolved in most cases to a specific regional locale, so "zh" is equivalent to "zh-CH". With the old settings, an item set explicitly to "zh-TW" would (or should) render in the default locale (i.e…
-
None of the suggestions floated so far should cause citations to be lost from the document. Switching back to a normal style should wake them up again.
-
Found the bug. It was an obscure one: an internal rendering operation (for one of the "and" term forms) was being blocked inside macros that render a date. The bug has been fixed in the processor patch plugin. The plugin works only in Zotero for Fi…
-
Sorry for missing your earlier report. You've hit a processor bug which I'll fix as soon as possible. I won't need a report ID or debug ID, but please start a fresh thread for this one, and indicate which style is involved.
-
It's probably not a major concern, but the Zotero metadata for these items will be hard to migrate to other systems (whether MLZ or a future Zotero version with legal support).
-
You could probably avoid the empty cite warning by rendering only a zero-width space.
-
(Well, that was quick. While doing some revisions on our house journal style, I ran across a bad failure when feeding a Japanese item to mlz-twlaw.csl. This proved that the explicit behaviour described above is the right one, so I've amended citepro…