https://bugs.kde.org/show_bug.cgi?id=431866
Bug ID: 431866
Summary: radselect: Radicals within each column are displayed
in random order
Product: kiten
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jker...@gmail.com
Reporter: fbri...@fbriere.net
Target Milestone: ---
While the radicals in radselect are grouped in columns based on their stroke
count, the list of radicals in any column is not sorted in any way, resulting
in them being shuffled in random order at every launch. With up to 40 radicals
in some columns, this make radselect nearly unusable.
Obviously, the solution is to sort those radicals, and I can think of three
possible orders:
1) The order in which they are listed within radkfile
The order of radicals within radkfile was not chosen at random, but is closely
similar (though not identical) to the order of Kangxi radicals, which is a de
facto standard for most dictionaries and has been drilled in the head of
Japanese schoolchildren. (XJDIC also uses this order when pressing "R" within
Radical Lookup Mode, though it displays them *horizontally* and without line
breaks, so they all fit within a single screen.)
PROS:
- Convenient for people already familiar with the standard radicals order
- Might be familiar to XJDIC users
CONS:
- Inconvenient for people *not* familiar with the standard order (aka most
Westerners)
- Requires much scrolling down for some very common radicals (e.g. ⺾)
2) Decreasing frequency order
In other words, the radical in each column which appears in the most kanji goes
on top, and the rarest one sinks to the bottom. Ties (common with rare
radicals) could be broken with method #1.
PROS:
- Intuitive for most users
- Most common radicals are always within reach
CONS:
- Order is somewhat arbitrary and unstable, as it can vary due to radkfile
updates (e.g. when ⺣ was added to all kanji containing 馬, making it suddenly
jump in frequency)
3) Unicode string order
While sorting radicals as Unicode strings doesn't seem like a good idea to me,
it is technically an option, so I figured I might as well mention it.
PROS:
- It's very easy to program :)
CONS:
- The result would only be meaningful to robots
The solution I'm opting for is to allow the user to choose between #1
(radkfile) and #2 (frequency), with the latter being the default, figuring that
most users would be more comfortable with it. I'm about to submit a merge
request doing that, but I thought it would nevertheless be a good idea to file
a bug report first, explaining the possible options with their pros and cons,
and giving an opportunity for others to voice their opinion.
--
You are receiving this mail because:
You are watching all bug changes.
