Marcusjmdict
commented
1 year ago I don't have the time right now to properly explain my position but I just want to voice that I'm not at all a fan of this solution. Having "JK" as a gloss in the ＪＫ entry is not only awkward but I would even call it incorrect, because the implication is that "JK" is actually used in English that way. We have a lot of Japanese users too (through Weblio etc.) so I really don't think this works.
On Fri, May 12, 2023, 4:39 PM JMdictProject @.***> wrote:
In the JK/ジェー・ケー entry ( https://www.edrdg.org/jmwsgi/entr.py?svc=jmdict&sid=&q=2739180) the issue was raised that the entry could not be found by searching for "JK" in the English meaning fields. This is true, as JK is not an English initialism - there are several like that: 1LDK, LDK, hoge, etc, In my comment I said "Better that apps and sites that use the data take on the issue of searching for these sorts of strings."
In recent days I did a proof-of-concept extension to the WWWJDIC server to handle these sorts of cases. I got the extension working, but I haven't released it for a few reasons:
- I ran into problems with the indexing of the 全角 alphanumerics. When I devised the indexing system it uses (several decades ago) I made the alphabetics and kana match against equivalents (かな matches against カナ) but didn't do the same for the 全角 alphabetics (1ldk doesn't match 1LDK). I was able to tweak the indexing but implementing that change all over the planet is a bit scary.
- the operation of the extension is messy. If you search for "hoge" you could be searching for an actual English term as well as the Japanese initialism. It creates a fork in the search process for which is difficult to display the results without ending up with a mess.
- in fact, only a very few entries have this issue. The vast majority of entries with 全角 alphanumeric headwords also have the string in the Meanings fields (AIDS, BBC, etc.). I could only find a handful of entries, such as "1LDK" where this was not the case.
On reflection, I think maybe the best solution is to put faux "meanings" of "1LDK" etc, into the entries and avoid all the complexity of trying to have special software for extreme edge cases.
— Reply to this email directly, view it on GitHub https://github.com/JMdictProject/JMdictIssues/issues/95, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUCQII4OGARACYFGIC6EUG3XFXSL7ANCNFSM6AAAAAAX7ESQDM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
JMdictProject
In the JK/ジェー・ケー entry (https://www.edrdg.org/jmwsgi/entr.py?svc=jmdict&sid=&q=2739180) the issue was raised that the entry could not be found by searching for "JK" in the English meaning fields. This is true, as JK is not an English initialism - there are several like that: 1LDK, LDK, hoge, etc, In my comment I said "Better that apps and sites that use the data take on the issue of searching for these sorts of strings."
In recent days I did a proof-of-concept extension to the WWWJDIC server to handle these sorts of cases. I got the extension working, but I haven't released it for a few reasons:
On reflection, I think maybe the best solution is to put faux "meanings" of "1LDK" etc, into the entries and avoid all the complexity of trying to have special software for extreme edge cases.