[Neobrahmigp] Oriya LGR v2.12 - 06mar19

Pitinan Kooarmornpatana pitinan.koo at icann.org
Wed Mar 6 12:05:18 UTC 2019


Dear NBGP members, 

 

Please find attached the Oriya LGR v2.12 dated 6 March 2019. This version has been updated in consultation with Kuldeep and he agreed to publish this package at the proposals’ webpage [icann.org].

 

We will inform the NBPG once the files are published. 

 

Regards,

Pitinan

 

 

From: Pitinan Kooarmornpatana <pitinan.koo at icann.org>
Date: Tuesday, March 5, 2019 at 22:12
To: Kuldeep Patnaik <kuldeep.patnaik3 at gmail.com>
Cc: Sarmad Hussain <sarmad.hussain at icann.org>, Ajay Data <ajay at data.in>, Udaya Narayana Singh <unsciil51 at gmail.com>, Mahesh D Kulkarni <mdk at cdac.in>
Subject: Oriya LGR v2.12 - 06mar19

 

Dear Kuldeep,

 

Please find the Oriya LGR Package version 2.12 dated 6 March 2019 as attached. 

The IP feedback has been incorporated in consultation with you, please see edit log below.

 

Kindly review and finalize. Then share the final package to the NBGP list, asking us to publish the package at the proposals’ webpage as the final version after public comment.

 

Regards,

Pitinan

 

From: Neobrahmigp <neobrahmigp-bounces at icann.org> on behalf of Sarmad Hussain <sarmad.hussain at icann.org>
Date: Monday, March 4, 2019 at 10:22
To: "kuldeep.patnaik3 at gmail.com" <kuldeep.patnaik3 at gmail.com>, "Neobrahmigp at icann.org" <Neobrahmigp at icann.org>
Subject: [Neobrahmigp] Oriya LGR v2.11 - 20190220

 

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 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.

 Done.

(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).

 Updated the paragraph to be: 

Anusvara replaces a conjunct group of a Nasal Consonant+Halant+Consonant belonging to that particular varga (plosive), representing a homorganic nasal. Before a non-varga (non-plosive) consonant the Anusvara represents a nasal sound. For example: ଏବଂ/ēbaṁ /(U+0B0F, U+0B2C, U+0B02) (means: and), ସଂଖ୍ୟା/ saṁkhyā / (U+0B38, U+0B02, U+0B16, U+0B4D, U+0B5F, U+0B3E) (means: number), etc.

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.

 Done.

(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).

Done.





(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....

Done.

  

(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>

Done. ( 1 – 6 ) 

 

(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".

 Done.

TXT

 No changes, so not tested.





 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190306/568fb06f/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: oriya-test-labels-06mar19-en.txt
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190306/568fb06f/oriya-test-labels-06mar19-en-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proposal-oriya-lgr-06mar19-en.pdf
Type: application/pdf
Size: 1712107 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190306/568fb06f/proposal-oriya-lgr-06mar19-en-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proposal-oriya-lgr-06mar19-en.xml
Type: application/xml
Size: 17777 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190306/568fb06f/proposal-oriya-lgr-06mar19-en-0001.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4610 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190306/568fb06f/smime-0001.p7s>


More information about the Neobrahmigp mailing list