Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Reading: Common can be confusing (暇) #754
another case where raw JMDict wins by being more informative: entry for 暇
however AEdict entry seems to suggest both readings are common
as stated before for me it might make sense to display Matsushita/Kamermans frequency rating separately from JMDict frequency rating.. though in this particular case these sources of info agree it would make sense for me to toggle either one or the other on or maybe have both displayed via different means (stars vs words etc)
from the same entry for 暇 in JMDict is another story whatsover.. perhaps a 'nokanji' reading could become a separate spelling in its own right? on par with all of these: 暇 ; 閑 ； 遑? in fact it's not a reading but a different way to spell..
P.S. I do love jmdict raw :) Would love to have it on my mobile in some way. AEDict is lovely but in it's transformation to a different data model it does loose some info :-( Think it's really hard not to loose info really when converting from such a flexible format as JMDict which is often driven by convention (like nokanji..)
True. Aedict doesn't underline this reading, to state that this particular reading is not common. Yet, the underline may not be understood, and the Reading: below states that it indeed is Common, which tricks the user that all readings are common. Please, what would you suggest in this case? I'm thinking of changing of the color of the less-common readings to be more greyish, yet that also may not communicate the information clearly enough.
This is new. Quoting from JMDict: "This element, which will usually have a null value, indicates that the reb, while associated with the keb, cannot be regarded as a true reading of the kanji. It is typically used for words such as foreign place names, gairaigo which can be in kanji or katakana, etc.".
Currently Aedict ignores
Think of Aedict as a visualizer for JMDict data :-) It is indeed true that some information may be lost, but we can always add those bits.
Adding support for