Closed krackers closed 4 years ago
More likely, the intermediate refactoring.
I’ll do a git bisect
tomorrow & see if I can chase down what’s going on.
Nevermind, I just tried again on the latest commit and it doesn't occur. Not sure why this originally happened.
Reopening; it seems like I can reproduce this when I change the
if (src.text().trim() !== '1913 Webster' &&
src.text().trim() !== 'Webster 1913 Suppl.'
) {
to
if (!src.text().includes('1913')) {
(hence why I saw it in the first place as I was preparing PR #19 ). I still think this is a regression as it didn't occur with 28d2f8d700eeafdce570ea5d9c4864032b89bfce when I included the PJC entries.
Interesting! With #19 merged, we can see if this bug still occurs; if not, we can close it out & move on, noting that trying to include the volunteer GCIDE entries is problematic.
Seems like this isn’t an issue any more, so I’ll close this out.
Sometime between commit 28d2f8d700eeafdce570ea5d9c4864032b89bfce and commit 7e42c21228d85047c36c88ceccfc288166f280b0, conversion started to produce weird results. If you look at the resulting xml you'll see
and the index continues until
<d:index d:value="Czechs" d:title="Czechs"/>
. This doesn't seem correct since most of those should have their own entry, and indeed prior to 28d2f8d700eeafdce570ea5d9c4864032b89bfce things were split up properly. I don't know if this was introduced when you switched to including GCIDE as a submodule or if it was introduced in some intermediary refactoring.