MW dev version based on meta/iast conversion

[funderburkjim]

I've done most of what I had in mind with the meta/iast conversion of MW.

Since there are numerous differences in the displays based on this conversion, and since MW is probably
the most heavily used Cologne digitization, I thought it best to have a review period before replacing
the current MW at Cologne with the revision.

The way I've chosen to do this is to make a clone of MW on a virtual machine at DigitalOcean.
This has all the Basic, List, and Advanced search displays, based on the new form of the digitization.

Here's the top-level link: Dev MW displays.

I hope others will do some close comparisons of this with the current displays at Cologne, at the
usual url: Cologne MW displays.

I'll point out some of the differences that seem important to me in the next few days, as well as
get caught up with some of the comments made recently regarding MW (such as #219 , #218).

There are also a few markup changes that need to be added to documentation in #216.

My thinking is that after a couple of weeks of review -- and revisions if needed -- this version will
replace the current versions at Cologne.

[funderburkjim]

simple search on dev system

This is implemented on dev system as list-0.2s_DO.html (DO= DigitalOcean].

Partly this was to make sure the changes in the MW conversion would work in this application, and to iron out bugs before porting to Cologne server.

Also, maybe this will encourage someone to do some close viewing of the displays and provide some feedback.

[funderburkjim]

Display Differences

This begins some comments comparing displays based on the revised MW, as seen in the dev version (links above) and the current Cologne displays, based on the pre-revised MW.

1. ls references in tooltips

By contrast, the current Cologne displays use a pop-up window.

Note also that in the revised Basic display, the <ls> text shows in the CharterIndoCapital font; this
was because of an attempt to use previous code (here from PW) as much as possible.
Here is the comparable basic display at Cologne:

[funderburkjim]

Display comparisons, continued

2. Styling difference: one column vs. two columns

The Cologne display puts the scan page link and Cologne record id in the first column of each
record, and the entry text in a second column. By contrast, the revised display uses only one column.

• for the first record, in the first row, the record id and scan link.
• for subsequent records, the page link is not repeated, and the record id is put after the record text,
  and in an abbreviated form.

3. Styling difference - abbreviations

• Common abbreviations (like 'cf.') are show in the same font, with a dotted underline
  • contrast this to the use of a difference color and font size in current Cologne display
• 'lex' abbreviations are shown in bold.
  • contrast this to the italic text in C.

NOTE: The scanned image above for the dev version makes it look like the normal text is
slightly larger, and maybe a heavier weight. However, this is just an artifact of the way I made
the image. In order to get the tool tip Rg-veda to show up, I had to take a screen shot, open
the resulting image and then take a snip -- however, before taking the snip, I magnified the
screen shot, since it seemed small; that magnification is why all the text looks heavier, but really
isn't.

[gasyoun]

By contrast, the current Cologne displays use a pop-up window.

Visually it's good, but the issue that it can't be copied remains.

text shows in the CharterIndoCapital font; this
was because of an attempt to use previous code (here from PW) as much as possible.

Well done. But actually MW is the only one using Charter and Clarendon fonts (Macdonell as well, I guess). The rest, including PW is Old Standard.

for the first record, in the first row, the record id

Should it be there at all? It attracts too much visual attention. I would hide it. The only time when I use it is to submit an error. And even in that case there is no need for a visual ID, because a JS can handle that from the metadata. I'm for moving all those [ID=897] to the metapart and removing from display.

I would vote for a display option, when all the meanings are in one paragraph as in original book, and not each on a new line. What do you say?

[funderburkjim]

4. links to Whitney, Westergaard

In the 'simple' display at Cologne, these links are absent. But they are present in the DO version.

Cologne version:

[funderburkjim]

5. Punctuation

There are several minor changes in punctuation. These were motivated by a desire to have the
digitized version more similar to the printed version, where it seemed possible to do this retroactively.
Some of these can be seen in the above 'viS' example.

• semicolons between successive <ls> tags.
  • This change is now part of the digitization, and thus amenable to further editing improvement.
    While these semicolons appear in the Cologne display, they do not appear in the Cologne
    digitization; the Cologne display program inserts the ';' at time of display.
• commas preceding <ls> tags. In most cases, the printed text uses a comma to separate the end
  of a text fragment from the literary source reference pertaining to the text. Such commas have
  been inserted into the revised digitization, and thus appear in the displays. These commas are
  absent in the Cologne digitization and displays.
• Spaces and punctuation: In C. digitization, there are often gratuitous spaces after '(' and before ').
  Similarly, there are often extra spaces before punctuation (comma, semicolon, period).
  Such spaces have removed in the revised DO digitization.
  • Some of these changes were made while composing this comment.

are there other systematic changes to be made

There may be other 'little' changes that can be programmatically made to bring the digitization
closer to the printed text. If you have any such little pet peeves with MW, now is a good time to
mention them.

[funderburkjim]

6. Non-italic Sanskrit words and Devanagari

In general, the only Devanagari script that appears in the printed text occurs within the headwords of Monier-Williams 'first line' of headwords:

Compare this to the displays with Devanagari output chosen:

Cologne	DIgital Ocean

Note that Devanagari script appears in both for words विष्णु , विष् , त्रि-विक्रम, बलि, and वामन.
These words were coded in the original monier.all using HK transliteration, and were identified with
a particular markup involving curly braces. Note that all these appear in italicized MW-IAST in the
printed text; the headword विष्णु also appears in Devanagari in print.

Second notice that many additional words in the Cologne version appear in Devanagari, such as ब्रह्मा, शिव , त्रि-मूर्ति, and several more down through उपेन्द्र . In the DO version these words appear in IAST form, such as Brahmā, Śiva , Tri-mūrti , through Upêndra. The DO version is in consonance with the print version for these words.

In the original monier.all, these words were coded in the AS (letter-number) coding, but were otherwise indistinguishable from any English text: for example later…names…Indra7nuja…and…Upe7ndra.
Somewhere along the line, I decided it would be good to identify these AS-encoded Sanskrit words as
indeed being Sanskrit words and having a coding which (a) retained the original AS coding and (b) added the comparable SLP1 coding:

 <as0>Indra7nuja</as0><as1><s>indrAnuja</s></as1> and 
<as0>Upe7ndra</as0><as1><s>upendra</s></as1>

The Cologne displays then chose to use the <as1> part of this dual coding to render the words
according to the user's choice of rendering Sanskrit words (the 'output' choice, such as Devanagari).

The revised coding looks like:

<s1 slp1="indrAnuja">Indrânuja</s1> and <s1 slp1="upendra">Upêndra</s1>

Here the AS coding, after conversion to IAST, is place as the text content of a new tag, <s1> and
the slp1 coding is places as an attribute of the tag. This placement of information provides a better
implementation of XML markup principles; e.g., the tags (stuff like '` ) is additive to the original
text; if you remove the markup, you get a good representation of the original text.

The current DO displays choose to ignore the slp1 attribute, when converting the XML to HTML.
A display could be written to use the slp1 attribute and ignore the IAST text, thereby resulting in
a display like the current Cologne display. But at least for now, I kind of like the DO form better.

@gasyoun and @SergeA : what do you think of this choice. Is the DO display better or worse than the Cologne display in this detail, or is the difference immaterial to you?

@drdhaval2785 : as a representative spokesman for those growing up with Devanagari, what do you think of this change in the DO form of display?

[gasyoun]

Such spaces have removed in the revised DO digitization

Good news.

In the DO version these words appear in IAST form, such as Brahmā, Śiva , Tri-mūrti , through Upêndra. The DO version is in consonance with the print version for these words.

Finally.

or is the difference immaterial to you?

Guess so.

[gasyoun]

Is there a reason to have Cologne record ID shown after each page? After all it's only for you, Jim, I guess. And even know, with the smart error submission (not yet widely implemented) even you do not need it. I see many scholars do copy-pasting and those IDs is only a waste of space and distract. Maybe it's time to hide them in web display? @funderburkjim what's your take on it?

[funderburkjim]

These numbers are useful in communicating details such as corrections or questions.

This is especially useful for MW, where many large entries in MW have been separated into smaller, bite-sized chunks in the digitization; and these chunks are identified by the 'Cologne ID'. Suppose you want to submit a correction; suppose the word 'short' in headword 'sara' should be spelled 'shirt'. If you tell me the record number as part of the correction submission, then I can go directly to that record and see what needs to be changed. Otherwise I have to search through perhaps a lot of text just to find what needs to be changed. So your communication to me is more precise, and therefore more likely to be correctly interpreted by me.

For other dictionaries, such as PWG or SKD, where there are very long entries, specifying the record number is not so useful, since a record might refer to a 10,000 character chunk of text, and I'll have to do a search within that chunk anyway.

Otherwise, that L=xxx just gets in the way. But as long as corrections are important, I think we should retain it, at least for MW. (Incidentally, this 'L=' changed today to be 'ID=' in simple-search display, consistent with basic display)

Incidentally, you'll notice that in the Basic displays, that ID=xxx has been styled to be less prominent to the eye. This was part of a suggestion by Caujolle, and was done recently.

Maybe similar styling change to 'ID=xxx' should be applied to the simple-search display.
What do you think?

You'll also note a minor change in the standard correction-form: The '*' beside 'Which ID?' now says this field is Optional, rather than Required. The id has always been actually optional (i.e., a submission will not be rejected just because it is missing the ID).

[gasyoun]

What do you think?

I think that for those 10-15 people, who will ever submit anything, the ID might be of any use, but the smart error submission should make it part of the history anyway. For the rest it's just distracting. Yes, grey is better than black, but still it takes so much space and attention.

[funderburkjim]

the smart error submission should make it part of the history anyway

Do you think the the ID can be scraped 'in the background', based on the selection made by the user in the smart error submission?

[gasyoun]

Do you think the the ID can be scraped 'in the background', based on the selection made by the user in the smart error submission?

Exactly. There is no need other than for error submission and even that no longer needs to be shown for all of us.