RE: [edict-jmdict] Future System (Was: Moving forward .....)

[Jim Breen <Jim.Breen@**********************>]

[Stuart McGraw (RE: [edict-jmdict] Future System (Was: Moving forward .....)) writes:]
>> Jim Breen wrote:
>> > - an editor logs in, and has access to a list of outstanding (not yet
>> > passed by an editor) submissions of new entries and amendments. This list 
>> > may even have brief entry summaries. There will also be lists of
>> > recently-approved submissions, and recently rejected submissions (see
>> > below).
>> > 
>> > - she/he clicks on one of them. This effectively assigns that submission
>> > to her/him. (Another editor logging in will see the submission, but it
>> > will flagged as undergoing an edit, and can't be accessed yet by another
>> > editor.)
>> 
>> It would be nice if the editor could look at all the details of the
>> submission before deciding if he/she wants to take it.  Maybe 
>> something like an "I'll do it" button on the detail page and similar 
>> button on the list with check boxes beside each summary if the 
>> user doesn't want to look at the details?  Once assigned it should
>> be easy for an editor to look at/search all his assigned entries 
>> in a variety of ways.

I guess an "I'll do it" button is the same in the long run, and yes, it
will be a more informed decision.

>> >[...]
>> > One issue concerns multiple amendments to the same entry. It happens - a
>> > word will crop up in the news and I'll get a couple of amendments in the
>> > same day (and probably a new one too from someone who couldn't find the
>> > original.)
>> > 
>> > Do we:
>> > 
>> > (a) let them all happen, and the editor has to sort it out.
>> 
>> I was sort of assuming that would be best.

Certainly the easiest to implement.

>> > If (a) what will be the editor's "view" of the entry?
>> 
>> One way to think about it is that the editor is updating an *entry*, 
>> not simply handling a submission.  If I were doing that I would 
>> want to see all the suggestions made about how that entry should 
>> be changed so that I could choose the best, or more likely, merge 
>> the best ideas from all of them.  
>> 
>> It is easy to present an editor with all submissions related to an 
>> pre-existing entry because they'll all have the same seq number, but 
>> for new submissions I guess one would have to rely on the editor 
>> to pick them out of the list manually, or perhaps the system could 
>> provide some help by grouping submissions by kanji/reading 
>> (though that might not be 100% reliable.) 

Yes, it would be hard to do automatically. At present I always miss
a few, but one of the sanity checks I run when adding a batch of
new entries is a check for matching kanji/reading pairs. I always find
a few that have been accidently duplicated.

>> I wonder what happens if it is overlooked that two "new entry"
>> submissions are basically the same and two different editors
>> each take one and approve it?

It's not two hard to find duplicated kanji/reading pairs. At present we
have 7 such legitimate duplicate pairs, plus 9 kana-only entries
duplicated. Any extras are likely to be errors.

>> > Something I do a lot is reject a proposed entry, but as a result of the
>> > submission, change an existing entry. Often this is because the proposed
>> > entry is there already, but possibly written slightly differently. I can
>> > do this easily at present because I do my daily edits with four editor
>> > windows open (incoming submissions, "newsubs" file, current database,
>> > feedback HTML page.) It's common enough that we should try and make it
>> > easy for an editor. 
>> 
>> While doing development, I find it a necessity to have a means of searching 
>> for entries by various criteria and displaying them fully.  Like wwwjdict but with 
>> more versatile searching and data retrieved from the live database.  I am perl'izing
>> the search and search results pages now, but the display page is working and
>> will be available on Arakawa as soon as William Maton and I can work out 
>> some system configuration issues.  Perhaps something like that would be useful?

It would be good if someone putting in an entry could be told
immediately that the kanji/reading matched an existing entry. They could
go ahead with the submission.

>> Sufficient?

Probably, provided any such matches with existing entries were flagged
to the editor too.

Looking forward to  seeing what you have on arakawa.

Cheers

Jim

-- 
Jim Breen                                http://www.csse.monash.edu.au/~jwb/
Clayton School of Information Technology,               Tel: +61 3 9905 9554
Monash University, VIC 3800, Australia                  Fax: +61 3 9905 5146
(Monash Provider No. 00008C)                ジム・ブリーン@モナシュ大学