[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RK restrictions [was adj-i/adj-ix issues]



Perhaps rather than not combining the いい/よい forms because the
restrs are too complicated we could look at alternative ways to
manage those complications?

For example, allowing a viewer to display the reading restrictions
as a 2-D grid of kanji X readings with a checkbox in each cell to
show if that particular combination is allowed or not.

I made a quick demo page to illustrate:
   http://edrdg.org/~smg/cgi-bin/restr.py?e=1990557&svc=jmtest

(Any entry can be viewed with this page by finding an entry by normal
means (search page etc, but make sure it is in the jmtest database,
i.e. the url contains "&svc=jmtest"), and then manually editing the
url in your browser's address bar to change "entr.py" to "restr.py".)

This is not intended to be pretty, please exercise your imaginations.
:-)  Obviously a lot of options for improvement exist like only
showing the grid if a threshold of complexity exists, or allowing
the user to hide/show the grid or other sections.  Or perhaps
a grid display is not the right answer...

Here are some other entries with relatively complex restrictions:
   http://edrdg.org/~smg/cgi-bin/restr.py?svc=jmtest&sid=&q=1577800.1
   http://edrdg.org/~smg/cgi-bin/restr.py?svc=jmtest&sid=&q=1719430.1
   http://edrdg.org/~smg/cgi-bin/restr.py?svc=jmtest&sid=&q=1444570.1
   http://edrdg.org/~smg/cgi-bin/restr.py?svc=jmtest&sid=&q=2172380.1

The demo page only displays an entry; it doesn't help for editing
an entry or adding a new one.  Two possible ideas:
o On the edit page, put a button under the "Readings" input text
   box.  When clicked a popup would open with a grid display similar
   to the demo page.  When closed (or an update button clicked, or
   something) the reading and the currently selected restrictions
   would be written into the Readings text box on the Edit page.
o Dump the JEL (JMdict Entry Language) text input method altogether
   and use a javascript driven form.  The motivation for JEL circa
   2005 was to avoid javascript but I don't think that is a
   consideration any more in today's internet.  Of course this
   is nearly a full reimplementation of the editing frontend
   pages so it is a non-trivial undertaking...
o Or something else?

There is also the question if the stagr, stagk restrictions need
better or special treatment.  And the biggie: does any of this
help in addressing the adj-i/adj-ix problem?  (This is your cue,
dear readers... :-)

-- Stuart

On 06/09/2018 04:02 PM, s mcgraw smcg6347@outlook.com [edict-jmdict] wrote:
 > I think at least one of the reasons for the adj-i/adj-ix split originally was
 > the complex set of restr restrictions that resulted when they were combined:
 > https://groups.yahoo.com/neo/groups/edict-jmdict/conversations/messages/5721
 >
 > The example given there for the combined adj-i/adj-ix form of 格好いい was:
 > Kanji: 格好いい ; 格好良い ; かっこ良い ; 格好よい ; かっこう良い ; かっこ好い
 > Readings: かっこいい ( 格好いい , 格好良い , かっこ良い , かっこ好い ) ; かっこよい ( 格好良い , かっこ良い , 格好よい , かっこ好い ) ; かっこういい ( 格好いい , 格好良い , 格好よい , かっこう良い ) ; かっこうよい ( 格好良い , 格好よい , かっこう良い ) ; カッコいい ( nokanji ) ; カッコイイ ( nokanji )
 >
 > I don't think a <ir-infl> tag would help this aspect of the problem.