AP v. AP90: headwords

[funderburkjim]

This is similar to #332. But in this case, we are looking at candidates for headword spelling changes for AP (1957) dictionary.

There are about 300 cases.

[funderburkjim]

Links to batches - SLP1

batch 200 , batch 201 , batch 202 , batch 203 , batch 204 ,
batch 205 , batch 206 , batch 207 , batch 208 , batch 209 ,
batch 210 ,

links to batches - Devanagari

batch 200 , batch 201 , batch 202 , batch 203 , batch 204 ,
batch 205 , batch 206 , batch 207 , batch 208 , batch 209 ,
batch 210 ,

link to test batch

The test batch may be used for experimenting. The results here will not be installed.

[funderburkjim]

Progress table

Batch	case1-case2	User	Date Begin	Date End	Installed
200	1-5	@funderburkjim	01/18/2017	01/18/2017
201	6-30	@SergeA	01/19/2017	01/19/2017
202	31-60	@funderburkjim	01/19/2017	01/19/2017
203	61-90	@funderburkjim	01/19/2017	01/19/2017
204	91-120	@funderburkjim	01/20/2017	01/20/2017
205	121-150	@SergeA	01/21/2017	01/21/2017
206	151-180	@SergeA	01/21/2017	01/21/2017
207	181-210	@funderburkjim	01/21/2017	01/21/2017
208	211-240	@funderburkjim	01/23/2017	01/23/2017
209	241-275	@funderburkjim	01/24/2017	01/24/2017
210	271-305	@funderburkjim	01/24/2017	01/24/2017

• Checkout a batch : When you work on a batch, edit this comment and put your GitHub user name, and the date you begin the batch.
• Finish a batch: When you finish all the cases in a batch, edit this comment and put the date you finished.

As batches are reviewed and installed, I will fill in the date of installation.

[funderburkjim]

UI comments

A few changes were made to the UI, implementing suggestions made for the UI of #332.

• When you open a batch, the first case is autoloaded.
  • If this is the first batch, you will likely see a POPUP BLOCKED message from browser. This means the scan page (which loads in a new tab), was not loaded. You'll need to click on the red line # xxx link for the scan.
• There is no 'Instructions' link. It was not up to date.
• There are several controls:
  • Autoload Scan: On by default. When on and a new case is loaded, then the scan for that new case automatically loads in a separate tab.
  • Next on Submit: On by default. When on, a click of 'Submit' button for a case authomatically loads the next case. When off, the case just submitted remains the current case
  • Case# This is a text field. It shows the current case. Also, if a user enters a different case (and presses 'Enter' key), then
    • 'Autoload Scan' is turned OFF. The reason is that, otherwise, the browser will shift focus to the scan tab, and this behavior is disconcerting. There seems to be no good way to control browser focus issues.
    • the case is loaded
  • Next Case Button >: This loads the next case. Autoload scan turned off
  • Prev Case Button >: This loads the previous case. Autoload scan turned off
• other dictionary links. We have a list dictionaries which have a headword with the same normalized spelling as the spelling of the other dictionary (e.g., the AP90 dictionary for these batches). Each of these links is presented as a button; and when the button is clicked, a 'list-0.2.php' display is prepared in another tab (and the browser switches focus to that tab).
  • For an 'slp1' display, the 'output' spelling of the list-0.2 display is SLP1
  • For a 'Devanagari' display, the output spelling of the list 0.2 display is Devanagari.
• Some lapses in Devanagari display present in the #332 UI have been corrected in this display.

[funderburkjim]

Batches ready!

[SergeA]

In batch 201 cases 1-4 are all for the headword अतिक्रमः misspelled as अतिकमः. Case 3 highlights the line

दिशत्यपायं हि सतामतिकमः Ki. 14. 9; कुलान्यकुलतां यान्ति ब्राह्मणातिकमेण

where we see two misspelled words. But in the field for correction is given only the headword अतिकमः. Actually in this article there are not four, but over a dozen of similarly misspelled words, and not all of them are highlighted in the cases. So I suppose it was not the task to correct all the words within the article, but only the headwords. Should I then correct the headword here only once and mark other cases as duplication adding a comment?

[gasyoun]

A few changes were made to the UI

Thanks!

no good way to control browser focus issues.

There is JS focus function like http://stackoverflow.com/questions/17500704/javascript-set-focus-to-html-form-element

not the task to correct all the words within the article, but only the headwords

Exactly.

[SergeA]

not the task to correct all the words within the article, but only the headwords

Exactly.

So how such cases are to be managed? In the batch 201 there are 36 cases instead of 25. There are 4 cases for विकमः>विक्रमः, 5 cases for अद्दष्ट>अदृष्ट and I suppose many more.

[SergeA]

@funderburkjim , all the improvements of the UI are very useful. Thank you!

[funderburkjim]

Regarding the vikama/vikrama cases, and others where there are many errors in the records. Any way you want to handle is fine - For example, do one with a comment, and mark others as no change, or change each separately, --- When I do corrections, I have a copy of ALL the lines for the headword, so I can find the other cases.

There's no easy way to handle multiple corrections in one case (or multiple corrections in same line) in a purely programmatic way. But with good comments, they'll all get corrected during installation.

Although we're focused on headwords, we might as well correct errors in the body when we notice them.

[funderburkjim]

Regarding JS focus - Your link pertains to setting focus, for example, on a text input box. Could be of use - I'll keep in mind.

However, the focus issue I was focused on :) has to do with tabs. Namely, loading a helper tab (with the scan) has a tendency to want to change browser focus from the AP form tab to the scan tab. Sometimes it doesn't (like when we go to next case upon Submit), but this seems to be just an accident, although favoriable to our application. The reason I say it is an accident, is that when an apparently similar thing is done (such as clicking on one of the words in the case-pane), the browser changes focus to the scan tab. And there appears to be no way to stop it from doing so.

For example, Google search 'Javascript focus on new tab' and look at some of the stack overflow discussions, and you'll see that this issue is tangled up with browser security issues and pop-up window issues, and that therefore browser vendors have intentionally limited the ability to change tab focus via Javascript. --- At least that's the way it looks to me.

[gasyoun]

Although we're focused on headwords, we might as well correct errors in the body when we notice them.

Fully agree. It would be a waste of time to leave them just as they are. So comments + Jim = clean digital copy.

intentionally limited the ability to change tab focus via Javascript.

So there is not much left for us. It works fine now as it is.

[funderburkjim]

In batch 204, case 5. avasaraRam, Other dictionaries have avasAraRam, and mention the causal of avasf as justification of the long A.

However, other dictionaries also have a saraRa form (though not with prefix ava), and alphabetical ordering in AP would be broken by changing to long A.

Thus, I'm leaving this unchanged - even though by sense it is clearly related to the long A forms.

[funderburkjim]

The reason so many cases are where the typist of our digitization writes 'ka' insteady of the print 'kra' might be that the Devanagari uses two diffierent ligatures for 'kr'. The more prevalent one looks sort of like 'ka', but with part of the loop on the left missing. This fragment illustrates:

[SergeA]

Little comparison for uccaraṇa/uccāraṇa.

MW72 uccaraṇa, uccarita, uccāraṇa, uccārita => AP90 print error uccaraṇa, uccarita, uccaraṇa, uccarita => AP1957 corrected back to uccaraṇa, uccarita, uccāraṇa, uccārita

MW72 vs. AP90

[SergeA]

The reason so many cases are where the typist of our digitization writes 'ka' insteady of the print 'kra' might be that the Devanagari uses two diffierent ligatures for 'kr'.

Yeah, an illiterate typist is a big problem.

[drdhaval2785]

Illiterate typist can be a boon also. They copy verbatim. A scholar typist may auto correct.

[SergeA]

One funny detective story.

PWG gives a word urūla and its supposed meaning.

उरूल [p= 1-1002] : (von उरु) adj. das Weite liebend, ungebunden, ungehorsam उरूलपरिमेहः Pâr. Gṛhj. 3, 7.

MW72 translates it from PWG.

Urūla, as, ā, am, liking space; fond of expatiating; free, unrestrained, disobedient.

AP90 rearranges the meanings as if this word be variously used in different texts.

उरूल [L=9218] [p= 0341-b]
a. 1 Liking space. — 2 Fond of expatiating. — 3 Free, unrestrained, self-willed.

Apte1957 changes the spelling from urūla to urula.

.उरुल¦ a. .²1 Liking space. .²2 Fond of expatiating. .²3 Free, unrestrained, self-willed.

Why they did it in 1957? We can suppose they checked the spelling by the source and corrected the error. But nothing of the kind! In the Paraskara Grihyasutra I found this line as उतूलपरिमेहः. Which one was misspelled by Boehtlingk, copied by MW72 and AP90 and additionally corrupted in 1957!

In PWG and MW72 utūla is given as separate word, while in AP90 it is not given at all.

Later Boehtlingk revised the source and found the error, corrected the spelling, removed those old wrong meanings and added a new supposed meaning in PWK.

उतूल [L=17957] [p= 1219-1] m. — 1) Knecht Pâr.gṛhj.3,7,1.2. — 2) Pl. N.pr. eines Volkes Mbh.6,361. उलूत v.l.

MW99 happily updated the spellings and meanings from PWK (and also pointed another source, but without the exact reference).

(H1) उतूल [p= 175,2] [L=30697] m. a servant, PārGṛ. iii, 7, 1 and 2 HirGṛ. (H1B) उतूल [p= 175,2] [L=30698] m. pl. N. of a people MBh. VP. (H1B) उतूल [p= 175,2] [L=30699] m. (» also उलूत and कुलूट.)

[gasyoun]

उतूलपरिमेहः. Which one was misspelled by Boehtlingk, copied by MW72 and AP90 and additionally corrupted in 1957!

Lovely! Do document any more if you find them.

[funderburkjim]

Page 609 of Cologne Scan of AP (57) is partially truncated at the left edge.

If anyone has a better image of this page, we should replace.

[gasyoun]

http://www.sanskrit-lexicon.uni-koeln.de/scans/***Scan/2014/web/webtc/servepdf.php?page=0609 this one?

[funderburkjim]

Re page 609. Yep that's the one. I was looking at the 'linenum' version. Which looks ok now.
My comment must have been based on some error in my usage of local browser. So, no need for page replacement. Mea culpa.

[gasyoun]

Mea culpa

Great. What's on your list? What do you plan to deal with in the upcoming 2-3 months, now when Trump is the president?

[funderburkjim]

Batch 206, cases 5-9.

These show 'annam' in AP being paired with 'unnam' in AP90.

@SergeA raised the question why ?

The reason is that in digitization of AP, between unnAda and unnata there is 'annam' (to rise). Referring to Page 435 of AP, we see that 'annam' is a digitization error and should be 'unnam'

This appears as case 9, and needs to be corrected to unnam as a typo.

The other cases of annam (5-8) are false positives.

[funderburkjim]

The corrections for AP have been installed. Also the related corrections to AP90.

@SergeA Thanks for the help!

[gasyoun]

Hail to @SergeA and @funderburkjim !