[Neobrahmigp] Oriya LGR v2.12 - 06mar19

Wed Mar 6 12:09:06 UTC 2019

Hello Pitinan, 

Please take the proposals to IP as final from NBGP side.

As already discussions have happened, this are minor final changes, just give 24 hours after submitting to NBGP list and if you don't hear anything take all the proposals to IP.

You don't need to wait for OK for every LGR proposal.

Hope it will help to speed up.

Thanks.

Ajay 

On March 6, 2019 9:05:18 PM GMT+09:00, Pitinan Kooarmornpatana <pitinan.koo at icann.org> wrote:
>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.
>
>
>
>
>
> 
>
> 

-- 
Sent from my Android device with XGenPlus.<img src="https://data.in:443/XGenPlusMessageID:1489538322193679069a--RCPT-.jpg" width='1px' height='1px'>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/neobrahmigp/attachments/20190306/87fdf1b1/attachment.html>