[Neobrahmigp] Oriya LGR v2.11 - 20190220

Mon Mar 4 03:21:38 UTC 2019

Dear Kuldeep and NBGP members,

IP has suggested some minor edits to consider before final submission of the proposal, listed in their message below.  

As next steps, once these edits are incorporated, the proposal will be published at the proposals’ webpage <https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en>  as the final version after public comment, and then IP will undertake its evaluation.

Regards,
Sarmad

  _____  

TO: NeoBrahmi Generation Panel
FROM: Integration Panel

We have reviewed the updated Oriya proposal dated 20 Feb 2019 and found several issues that require a quick fix, plus a few additional suggestions for improved text. In one case identical text in DOCx and XML relies on terminology not defined in either document - this requires new text to be written by the GP that gives the necessary explanation in terms the (non-native/non-expert) reader can follow.

The required fixes apply to both the document and the XML.

There is an additional MUST FIX item each for DOCx and XML as a result of clerical error in preparing the LGR. 

Additional edits are recommended to the attention of the GP.

- Integration Panel

DOCX:

(1) MUST FIX: on p. 20 the Unicode name for 0B2F was unaccountably changed from YA to JA and now incorrectly duplicates the name for 0B1C. (Oriya has both a JA and a YA.) 

This change should be backed out and the correct character name  YA used for 0B2F.

(2) both the proposal and the XML mention the word "varga" without explaining it. This is most likely due to some copying and pasting of text from other proposals. However, non-specialist readers will not be able to understand the description of Anusvara in Oriya if it relies on terms not introduced in the proposal document. Here are the two uses in Section 3.11:

"that particular varga"  --- which one?

"non-varga consonant"  --- what is that?

This should definitely be fixed, even if it requires a bit of new/rewritten text. The IP recommendation is to either rewrite the description without relying on the term "varga",  or find a way to gloss the term in passing; alternatively, provide a fuller discussion (more appropriate for the DOCx than the XML).

XML

In the Section "Character Classes"

(1) the subsection for Halant could be edited as follows:

    <p>Halant: A Halant, also known as Virama, is used after a consonant to "strip" 
    it of its inherent vowel. The Halant form of a consonant is the form produced by adding the Halant, 
    encoded as U+0B4D ( ୍ ) ORIYA SIGN VIRAMA
    to the nominal shape. A Halant follows all but the last consonant in every Oriya 
    syllable. More details in Section 3.7, "The Implicit Vowel Killer Halant" of the [Proposal].</p>

The subsection header should be the name of the character class, not the title of the section in the proposal; other suggested edits are for consistency.

(2) This also applies to the subsection for Visarga:

    <p>Visarga: U+0B03 ORIYA SIGN VISARGA is frequently used in Sanskrit and represents a sound 
    very close to /h/. More details in Section 3.9, "Visarga & Avagraha" of the [Proposal].</p>

The "Avagraha" is not part of the repertoire in this XML and therefore this subsection should be named only after the Visarga (even if the proposal subsection does discuss both).

(3) Nasalization: Candrabindu: section in <description>.

First, "Nasalization" is not a character class, therefore, it ought to be made a subheader.

Change <p>Nasalization: Candrabindu ... 

to 

    <h3>Nasalization:</h3>
    <p>Candrabindu....

(4) in the Anusvara: section, there is the use of "varga" which is not explained in the XML  (and which presents a real problem for the integrated Root Zone LGR as users are normally not expected to read the [Proposal] first.)

This must be reformulated (see comment for DOCx above). The same (or similar) language should be used in both DOCx and XML, if possible, but keeping in mind the different focus: readers of the XML care more about how a character class is used in identifiers than how it features in writing text. 

This is a MUST FIX.

(5) in the WLE rules section, perhaps add the number of each WLE rule as follows:

     <li>1. N: must be preceded only by C1</li>
     <li>1. B: must be preceded by V, C, N or M</li>
     <li>3. X: must be preceded by V, C, N or M</li>
     <li>4. D: must be preceded by V, C, N or M</li>
     <li>5. H: must be preceded by C or N</li>
     <li>6. M: must be preceded by C or N</li>

(6) MUST FIX:

    In the XML, the type attribute of the <var> elements for 101D and 1031 should be "out-of-repertoire-var" and not "out-of-repertoire".

TXT

 No changes, so not tested.

  _____  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190304/9da6ae8b/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190304/9da6ae8b/ATT00001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5026 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190304/9da6ae8b/smime.p7s>