Registry Contact Details

• Contact Name: [Please fill in Contact Name]
• Email address: [Please fill in Email address]
• Phone Number: [Please fill in optional Phone Number]

Label Generation Rules for the Myanmar Script

Overview

This document specifies a set of Label Generation Rules (LGR) for the Myanmar script for the second level domain or domains identified above. This LGR contains the full set of cross-script variants required for use with the following scripts: Georgian, Latin, Oriya and Malayalam. The starting point for the development of this LGR can be found in the related Root Zone LGR [RZ-LGR-Mymr]. The format of this file follows [RFC 7940]. This LGR is adapted from the “Reference LGR for the Second Level for the Myanmar Script” [Ref-LGR-und-Mymr], for details, see Change History below.

For details and additional background on the Myanmar script, see “Proposal for a Myanmar Script Root Zone Label Generation Rule-Set (LGR)”; [Proposal-Myanmar].

Repertoire

The repertoire consists of 98 Myanmar script unique code points and 65 sequences. The code point U+1063  ၣ  Myanmar Tone Mark Sgaw Karen Hathi is not listed separately, but is available as part of a defined sequence, bringing the total to 99 distinct code points.

The repertoire is a subset of [Unicode 11.0.0]. For details, see Section 5, “Repertoire” in [Proposal-Myanmar]. (The proposal cited has been adopted for the Myanmar script portion of the Root Zone LGR.)

The repertoire includes code points used by languages written in Myanmar script that fall within levels 1 to 4 on the [EGIDS] scale, as well as EGIDS 5 languages which have more than 500,000 users are included in the analysis. They are Burmese, Shan, Rakhine, S’gaw Karen, Mon, Pa’O Karen. (See also [Ethnologue].) A non-exhaustive list of languages using each code point can be found in the comments. For more details, see Section 5 “Repertoire” in [Proposal-Myanmar].

Note: In this document, to avoid confusion, the term ‘Myanmar’ is used for the Myanmar script and the term ‘Burmese’ is used for the Myanmar language.

For the second level, the repertoire has been augmented with the Myanmar digits, U+1040 ၀ to U+1049 ၉, the ASCII digits, U+0030 0 to U+0039 9, and U+002D - HYPHEN-MINUS, for a total of 184 repertoire elements.

Note that some languages, such as Burmese, commonly use the Myanmar digits while others, such as Shan, use the ASCII digits. Therefore, both sets of digits included, albeit with mutual exclusion. However, see the discussion under Digit Variants below as to why this necessitates some restrictions on U+1040 ၀ MYANMAR DIGIT ZERO.

Any code points outside the Myanmar Script repertoire that are targets for out-of-repertoire variants would be included here only if the variant is listed in this file. In this case they are identified as a reflexive (identity) variant of type “out-of-repertoire-var”. Whether or not they are listed, they do not form part of the repertoire.

Repertoire Listing: Each code point or range is tagged with the script or scripts with which the code point is used, one or more tag values denoting character category, and one or more references documenting sufficient justification for inclusion in the repertoire, see “References” below. For code points that are part of the repertoire, comments identify the languages using the code point along with their [EGIDS] level.

Variants

Unlike other LGRs for this script, which only incude the variant definitions needed when used as standalone in their zone, this LGR contains the full set of variants needed for zones shared by more than one script. Where appropriate, cross-script variants have been defined to mutually exclude labels from different scripts that could otherwise be substituted by the users. To meet the requirement for variant transitivity, additional in-script variants may be defined as needed. Once a label has been delegated for one script, any of its variant labels consisting entirely of cross-script variants would be blocked. Any label containing at least one code point that is not a cross-script variant would be considered distinct. Because of that, even large numbers of defined cross-script variants generally do not lead to a high percentage of labels experiencing a collision across scripts.

The definition of variants included in this LGR contributes to the definition of variants in the Common LGR. Even though this LGR contains the full set of variants affecting this script, use of the Common LGR is required for actual mitigation of issues caused by using multiple languages or scripts in the same zone. For details, see Section 3, "Use of Multiple Reference LGRs in the Same Zone" in [Level-2-Overview].

In-script variants: this LGR defines in-script variants because they have identical appearance, constitute language-based variants, or are otherwise analogues of the same code point or sequence (semantic variants). For details, Section 6, “Variants”, in [Proposal-Myanmar].

There are two pairs of in-script variants where a naive implementation would interact with cross-script variants in undesirable ways. They, and the required mitigations are discussed in more detail below.

Variant Dispositions: The disposition for some variants is “blocked” : only a single version of the label should be delegated at one time, while all other variants are excluded. The disposition for the remaining in-script variants is “allocatable”, allowing more than one variant to be delegated to the same entity. See Section 6.1 in [Proposal-Myanmar].

Variants that have the same meaning, pronunciation and property should not appear both in the same string. Based on the language, only one variant should be chosen and written consistently. The LGR contains rules and other constraints on variants that prohibit mixed-language labels and arbitrary mixture of variants. See Section 7 in [Proposal-Myanmar].

Some additional code point combinations could create visual variants; however the WLE rules disallow these combinations. They are therefore not normatively defined as variants, but listed in Appendix A of [Proposal-Myanmar].

Cross-script variants:; Some Myanmar characters look the same as characters in Malayalam, Oriya, and Georgian scripts. See Section 6.2 in [Proposal-Myanmar]. The letters U+101D ဝ and U+1004 င look like their counterparts in one or more of the Latin, Greek, Cyrillic and Armenian scripts among others. Not all these variants are listed here explicitly.

Digit Variants: All Myanmar digits are treated as semantic variants of the corresponding common (ASCII) digits. By transitivity, they are also semantic variants of any native digits in scripts that also include the common digits. Such variant relations are deemed to exist implicitly by transitivity but are not listed explicitly in each reference LGR. Instead, if needed, they are applied by using the Common LGR in label processing.

U+1040 ၀ MYANMAR DIGIT ZERO is an in-script homoglyph of U+101D ဝ MYANMAR LETTER WA and thus must be a blocked variant of it. At the same time, Myanmar letter WA is a homoglyph of Latin letter ‘o’ and in zones that support ASCII letters, it is a cross-script variant to WA. The policy stated above treats digits as semantic variants of each other across sets, making Myanmar digit ZERO an in-repertoire variant of ASCII digit ZERO ‘0’ as well. In zones that support Latin letter ‘o’ transitivity would then lead to an additional variant definition between ASCII digit ‘0’ and Latin letter ‘o’.

However, variants inside the ASCII set are strictly excluded because LDH labels have never had variants. The easiest work-around is to not allow Myanmar digit ZERO to be part of labels for which a homograph variant with an ASCII label is possible and to only define variants between U+101D ဝ and U+1040 ၀ for allowed labels. This restriction affects only a small fraction of labels. While this work-around is not strictly necessary in zones that do not support Latin letter ‘o’, it is required for consistency with the Common LGR.

Additional Variants: When integrated to be used with another script LGR in the same zone, this LGR may inherit additional blocked cross-script variants by integration; they may not be listed here unless they reflect resulting in-script variants. Always use an applicable merged, or Common LGR created by integration for determining cross-script collisions of labels. For consistency with other reference LGRs, cross-script variants to ASCII code points are listed explicitly as well.

The specification of variants in this LGR follows the guidelines in [RFC 8228].

Character Classes

The syllable principle is at the heart of the Myanmar script writing system. The general order of elements in a syllable is Consonant > (Medials) > Vowels > (Consonant) > Tone. Overall, the Myanmar script is composed of:

• Consonants (c). The following sub-categories of c are also defined:
  • c1, U+103F ဿ REAT SA (theoretical combination of two Myanmar Letter Sa)
  • c2, a set of consonants to be combined with S16
  • c3, a set of consonants to be combined with S17
• Independent Vowels (iv)
• Dependent Vowels (dv). Some of the dv also categorized to following sub-categories:
  • Long Vowel (lv): U+102B  ါ , U+102C  ာ , U+102E  ီ , U+1030  ူ , U+1031  ေ , U+1032  ဲ , and U+1036  ံ  Anusvara
  • Short Vowel (sv): U+102D  ိ , U+102F  ု 
  • Anusvara (a): U+1036  ံ 
  • Shan Vowel (sh_vowel)
  • Long Tone (t_short)
  • Short Vowel (t_long)
• Killer or Asat (k)
• Virama (virama)
• Medials (m)
  • Mon medials (M_mon)
  • Shan medial (M_shan)
• Tone mark and Signs:
  • Shan Tone (sh_tone)
  • Pao Tone (pao_tone)
  • Sgaw Tone (skaw_tone)
• Other Various Signs (ov)

Consonants: Consonants usually stay at the head of each syllable. A consonant can be stand-alone or be followed by Medials, Dependent Vowels, other Signs or Tone Mark. A Consonant cannot be between Viramas to prevent the invalid case of c+v+c+v+c. See Section 3.3.1, “The Consonants” in [Proposal-Myanmar].

Independent Vowels: Only Burmese, Mon and Pa’O languages use Independent Vowels. An Independent Vowel can be at any position in a label. See Section 3.3.2, “The Independent Vowels” in [Proposal-Myanmar].

Dependent Vowels: Dependent vowel signs add vowel property to consonants. These signs appear in top/below/left/right positions of a center consonant or consonant+medial. The dotted-circle indicates where the centre character would be. Dependent vowel signs cannot be repeated and Dependent vowels cannot be adjacent to each other unless within sequences defined in Table 8-A. Dependent vowels also cannot be followed by Asat (U+1038) unless within sequences defined in Table 8-A. See Section 3.3.3, “The Diacritic - Dependent Vowels” of [Proposal-Myanmar].

Medials: Medials are used to enhance the sound of Consonants. They are also noted as Dependent Consonants as they need a leading Consonant to attach to. All five languages in this proposal use Medials. See Section 3.3.4, “Diacritic - Medials” of [Proposal-Myanmar].

Virama: U+1039  ္  MYANMAR SIGN VIRAMA is used in Burmese and Mon. Virama has two properties, as killer (devoweliser) and joiner of syllable chaining. This virama brings the consonant after it to be rendered below the consonant before. Pattern of syllable chaining : Consonant + Virama + Consonant. However. a repetition of Consonant + Virama + Consonant is not allowed to prevent rendering issues. See Section 3.3.5, “Diacritic - Tone Marks and Other Signs” in [Proposal-Myanmar].

Killer or Asat: U+103A  ်  MYANMAR SIGN ASAT is used in Burmese and Mon. This sign is used to remove the consonant sound of a letter and take only the vowel property to create more vowel sounds out of consonants. Except for defined sequences, Asat cannot follow other Diacritics. See Section 3.3.5, “Diacritic - Tone Marks and Other Signs” in [Proposal-Myanmar].

Long Tone (t_long): U+1038  း  MYANMAR SIGN VISARGA appears at the end of the syllable. It creates a vowel sound with the higher tone. It follows a Consonant, Medial, Long vowel or the sequence U+102D U+102F  ို . See Section 3.3.5.1, “Burmese Tone Marks and Other Signs” in [Proposal-Myanmar].

Short Tone (t_short): MYANMAR SIGN DOT BELOW (U+1037) appears at the end of the syllable. It creates a vowel sound with the higher tone. It follows a Consonant, Medial, Long vowel or the sequence U+102D U+102F  ို . See Section 3.3.5.1, “Burmese Tone Marks and Other Signs” in [Proposal-Myanmar].

Other classes defined for use in WLE and context rules

• Shan Tone (sh_tone), Shan Vowel (sh_vowel)
• C_103B, a set of consonants that can be followed by medial YA U+103B  ျ 
• C_103C, a set of consonants that can be followed by medial RA U+103C  ြ 
• C_103E, a set of consonants that can be followed by medial HA U+103E  ှ 
• C_n103D, a set of consonants that cannot be followed by medial WA U+103D  ွ 
• C_mon, a set of Mon consonants that can be followed by Mon Medial U+105E U+105F  ၞၟ  or U+1060  ၠ 
• C_shan, a set of Mon consonants that can be followed by Shan medial WA U+1082  ႂ 
• CMM1, a set of consonants that can be followed by medial sequence U+103B U+103D  ျွ 
• CMM3, a set of consonants that can be followed by medial sequence U+103C U+103D  ြွ 
• CMM5, a set of consonants that can be followed by medial sequence U+103D U+103E  ွှ 
• cp1002cp1015cp101D, a set of consonants that cannot be followed by vowel AA U+102C  ာ 

Additional classes defined for extensions for the second level:

• common-digits, the set of ASCII digits
• myanmar-digits, the set of Myanmar digits
• has-ASCII-homoglyph, the set of code points with ASCII homoglyph variants: U+1004 င, U+101D ဝ, U+1040 ၀

Whole Label Evaluation (WLE) and Context Rules

Default Whole Label Evaluation Rules and Actions

The LGR includes the rules and actions to implement the following restrictions, some of which are mandated by the IDNA protocol. They are marked with ⍟ and included here by default.

• Hyphen Restrictions — restrictions on the allowable placement of hyphens (no leading/ending hyphen and no hyphen in positions 3 and 4). These restrictions are described in Section 4.2.3.1 of RFC 5891 [150]. They are implemented here as context rule on U+002D (-) HYPHEN-MINUS.
• Leading Combining Marks — restrictions on the allowable placement of combining marks (no leading combining mark). This rule is described in Section 4.2.3.2 of RFC 5891 [150].
• Digit-mixing — no mixing between different digit sets (European and Myanmar digits) is allowed; implemented here as a WLE rule with associated action.

Default Actions

This LGR includes the complete set default actions for LGRs as well as the action needed to invalidate labels with misplaced combining marks. They are marked with ⍟. For a description see [RFC 7940] and [150]. An additional action is triggered by mixed digit labels.

Myanmar-specific Rules

There are constraints on the context for many of the character classes in Myanmar. These constraints enforce the syllable structure to the degree needed for stability of rendering (which affects both security and usability) without enforcing other linguistic constraints or spellings. These constraints are implemented via a set of context and whole label rules formulated for LGR specification, as described in Section 7, “Whole Label Evaluation (WLE) Rules” in [Proposal-Myanmar].

The following shorthand names for sequences are used in the description or definition of these rules:

• S11 — Myanmar letter NGA followed by Asat and Virama
• S12, S14, S15 — long-vowel sequences
• S16, S17 — Asat sequences
• ST4 — a Pa’O Karen tone sequence
• ST1, ST2, ST3 — Skaw Karen tone sequences
• S_Mon4 — Mon Kinzi
• S_Mon5 - S_Mon16; Mon dependent vowel sequences

The rules are:

1. dv: must follow c or m;
   Note dv includes lv, sv, and ov, as well as the starting code point in sequences S12, S13, S14, S15, S18, S19, S20, S_Mon3, S_Mon5, S_Mon6, S_Mon7, S_Mon8, S_Mon9, S_Mon10, S_Mon11, S_Mon12, S_Mon16, S_Sh1, S_Sh2, S_Sh3, S_Sh4, S_Sh5, S_Pao/.
2. Anusvara: must follow c or m
3. Rules for Medials combining with Consonants:
   • Rules for Single Medials
     • U+103B  ျ  must follow consonant C_103B
     • U+103C  ြ  must follow consonant C_103C
     • U+103E  ှ  must follow consonant C_103E
     • U+103D  ွ  must follow any consonant except C_n103D
     • M_mon must follow C_mon
     • M_shan must follow C_shan
   • Rules for Combined Medials
     • MM1 must follow CMM1
     • MM3 must follow CMM3
     • MM5 must follow CMM5
     • S_Mon13 must follow C_103E
     • S_Mon14 must follow C_103E
     • S_Mon15 must follow C_103E
4. U+103F ဿ MYANMAR GREAT SAA must follow c or m or dv or U+1023 ဣ or U+1025 ဥ
5. (c + k) or (c2 + S16) or (c3 + S17) must follow c or n or dv or ov
6. S11 must follow c or m or dv and another c must follow S11
7. virama: must be between two c (c+v+c). But c cannot be between v to prevent v+c+v+c
8. t_long and t_short: must follow c or m or lv or S12
9. sh_tone must follow sh_vowel or (c + k) or s_sh2 or s_sh5
10. pao_tone must follow dv or m or k, except U+1037  ့  or U+1308 ገ
11. ST4 must follow U+1031  ေ , U+1032  ဲ , S12, S14, or S15
12. ST1, ST2, ST3 or Sgaw_Tone must follow c or m or dv
13. S_Mon4 must follow c or m or dv and another c must follow S_Mon4
14. U+102C  ာ  cannot follow any of the three consonants U+1002 ဂ, U+1015 ပ, U+101D ဝ

These rules are implemented as required or prohibited contexts for the respective repertoire elements.

No-Mix Rules

According to Table 10 of [Proposal-Myanmar], there are code points which cannot occur both in the same label. The following WLE rules enforce these constraints:

• no-mix-mm-i-and-mm-ka-v-ka
• no-mix-mm-ha-asat-and-mm-pa-aa-asat
• no-mix-sk-sha-and-mm-ra-mha
• no-mix-mm-kha-and-shan-kha
• no-mix-mm-and-mon — the use of any mon-specific code point requires that all other code points that have a mon-specific equivalent must use that one over the standard Myanmar code point in that label.

These rules are implemented as WLE rules which trigger a corresponding action.

Context rule for Digit ZERO

As described under Digit Variants above, a small restriction on U+1040 ၀ MYANMAR DIGIT ZERO is required to side-step unwanted interactions among in-script and cross-script variants. The effect is to require at least one digit other than U+1040 ၀ and/or at least one letter that is not U+101D ဝ or U+1004 င. The number of possible labels thus restricted is very limited, a small price to pay for being able to support the much larger set of critical variants among homoglyph labels. The rule is the same as described below in Context Rules for Variants.

Context rules for Variants

The following prohibited context applies to certain variants:

• followed-by-c-end — a variant relation does not exist between U+1004 င and U+105A ၚ if followed by a consonant or end of label

In addition to preventing a variant in contexts where the two code point do not look the same, this means that unlike U+1004 င, U+105A ၚ can never inherit a cross-script variant to Latin U+0063 c, because it only takes on that appearance when followed by some other Myanmar-unique code point.

• label-has-ASCII-homoglyph — a variant relation only exists between U+101D ဝ and U+1040 ၀ if a label contains only the code points from the class “has-ASCII-homoglyph”

This context rule also applies to U+1040 ၀ MYANMAR DIGIT 0. The combined effect is to support the in-script variant between U+101D ဝ and U+1040 ၀ in all contexts where ASCII variants can be ignored.

Actions

Default Actions

This LGR includes the default actions for LGRs as well as the action needed to invalidate labels with misplaced combining marks. They are marked with ⍟. For a description see [RFC 7940].

Myanmar-specific actions

The no-mix rules trigger Myanmar-specific actions that invalidate any original and variant labels not satisfying the constraints. See Section 7, “Whole Label Evaluation (WLE) Rules” in [Proposal-Myanmar].

In addition, to limit the number of allocatable variant labels, further constraints on variants are included. These allow allocatable variant labels to either contain members of Grapheme-set-1 (left column in Table 10) or Grapheme-set-2 (right column in Table 10) but not a mixture of members from both sets. The code points on the left column are either the simpler forms (shorter sequence) or the lower Unicode code point values. The mixture of code points from different sets, however, is possible in the original, applied-for label. See Section 6.1 “In-script Variants” in [Proposal-Myanmar].

Each code point or sequence in grapheme-set 1 has been given the reflexive variant type “r-set1” and each code point or sequence in grapheme-set 2 has been given the reflexive variant of type “r-set2”. (By convention, the prefix “r-” marks a type used in a reflexive variant mapping, that is, it represents an instance of the original code point at that location in a variant label, see Section 5.3.4 in [RFC 7940].)

A variant mapping from a member of grapheme-set 1 to a member of grapheme-set 2 is of type “set1-to- set2”, while the variant type for mapping from grapheme-set 2 to grapheme-set 1 is of type “set2-to-set1”.

Script-specific actions evaluate these variant types to ensure the following constraints:

• blocked — a variant label containing a blocked variant will receive a disposition of “blocked”.
• r-set1 r-set2 — a label containing one or more of these reflexive variant types and no others represents an original label and receives a disposition of “allocatable”.
• r-set1 set2-to-set1 — a label containing one or more of these variant types and no others receives a disposition of “allocatable”.
• r-set2 set1-to-set2 — a label containing one or more of these variant types and no others receives a disposition of “allocatable”.
• set1-to-set2 set2-to-set1 — a label containing a mix of these variant types receives a disposition of “blocked”.

See Section 6.1 “In-script Variants” and Section 7, “Whole Label Evaluation (WLE) Rules” in [Proposal-Myanmar].

Methodology and Contributors

The LGR in this document has been adapted from the corresponding Reference LGR for the Second Level. The Second Level Reference LGR for the Myanmar Script was developed by Michel Suignard and Asmus Freytag, based on the Root Zone LGR for the Myanmar script and information contained or referenced therein; see [RZ-LGR-Mymr]. Suitable extensions for the second level have been applied according to the [Guidelines] and with community input. The original proposal for a Root Zone LGR for the Myanmar script, that this LGR is based on, was developed by the Myanmar Generation Panel. For more information on methodology and contributors to the underlying Root Zone LGR, see Sections 4 and 8 in [Proposal-Myanmar], as well as [RZ-LGR-Overview].

Changes from Version Dated 24 January 2024

Adopted from the Second Level Reference LGR for the Myanmar Script [Ref-LGR-und-Mymr] without normative changes.

References

[EGIDS]

Lewis and Simons, “EGIDS: Expanded Graded Intergenerational Disruption Scale,” documented in [SIL-Ethnologue] and summarized here:
https://en.wikipedia.org/wiki/Expanded_Graded_Intergenerational_Disruption_Scale_(EGIDS)

[Ethnologue]

Ethnologue, Myanmar, (Accessed 6 October 2019)
https://www.ethnologue.com/country/MM

[Guidelines]

ICANN, “Guidelines for Developing Reference LGRs for the Second Level”, (Los Angeles, California: ICANN, 27 May 2020),
https://www.icann.org/en/system/files/files/lgr-guidelines-second-level-27may20-en.pdf

[Level-2-Overview]

Internet Corporation for Assigned Names and Numbers, (ICANN),“Reference Label Generation Rules (LGR) for the Second Level: Overview and Summary” (PDF), (Los Angeles, California: ICANN, 24 January 2024),
https://www.icann.org/en/system/files/files/level2-lgr-overview-summary-24jan24-en.pdf

[MSR-5]

Integration Panel, “Maximal Starting Repertoire — MSR-5 Overview and Rationale”, 24 June 2021,
https://www.icann.org/en/system/files/files/msr-5-overview-24jun21-en.pdf

[Proposal-Myanmar]

Myanmar Generation Panel, “Proposal for a Myanmar Script Root Zone Label Generation Rule-Set (LGR)”, 17 March 2022,
https://www.icann.org/en/system/files/files/Proposal-Myanmar-lgr-17mar22-en.pdf

[RZ-LGR-Mymr]

ICANN, Root Zone Label Generation Rules for the Myanmar Script (und-Mymr), 26 May 2022 (XML)
https://www.icann.org/sites/default/files/lgr/rz-lgr-5-myanmar-script-26may22-en.xml

[Ref-LGR-und-Mymr]

ICANN, Second Level Reference Label Generation Rules for the Myanmar Script (und-Mymr), 24 January 2024 (XML)
https://www.icann.org/sites/default/files/packages/lgr/lgr-second-level-myanmar-full-variant-script-24jan24-en.xml
non-normative HTML presentation:
https://www.icann.org/sites/default/files/packages/lgr/lgr-second-level-myanmar-full-variant-script-24jan24-en.html

[RFC 7940]

Davies, K. and A. Freytag, “Representing Label Generation Rulesets Using XML”, RFC 7940, August 2016,
https://www.rfc-editor.org/info/rfc7940

[RFC 8228]

A. Freytag, “Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels”, RFC 8228, August 2017,
https://www.rfc-editor.org/info/rfc8228

[RZ-LGR-Overview]

Integration Panel, “Root Zone Label Generation Rules (RZ LGR-5): Overview and Summary”, 26 May 2022 (PDF),
https://www.icann.org/sites/default/files/lgr/rz-lgr-5-overview-26may22-en.pdf

[SIL-Ethnologue]

David M. Eberhard, Gary F. Simons & Charles D. Fennig (eds.). 2021. Ethnologue: Languages of the World, Twenty fourth edition. Dallas, Texas: SIL International. Online version available as
https://www.ethnologue.com

[Unicode 11.0.0]

The Unicode Consortium. The Unicode Standard, Version 11.0.0, (Mountain View, CA: The Unicode Consortium, 2018. ISBN 978-1-936213-19-1)
https://www.unicode.org/versions/Unicode11.0.0/

For references consulted particularly in designing the repertoire for the Myanmar Script for the second level please see details in the Table of References below.

References [0] to [9] refer to the Unicode Standard versions in which the corresponding code points were initially encoded. Reference [101] and above correspond to sources given in [Proposal-Myanmar] justifying the inclusion of the corresponding code points. Entries in the table may have multiple source reference values. Reference [150] indicates the source for common rules.

Character Classes

Number of named classes	23
Implicit (except script)	10
Implict defined by script tag	6

The following table lists all named and implicit classes with their definition and a list of their members intersected with the current repertoire (for larger classes, this list is elided).

Name	Definition	Count	Members or Ranges	Ref	Comment
c	Tag=c	55	{1000-1022 1027 103F 105A-105D 1061 1075-1081}		Any Myanmar consonant
dv	Tag=dv	17	{102B-1034 1036-1038 1062 1083-1084 1086}		Any Myanmar dependent vowel
m	Tag=m	8	{103B-103E 105E-1060 1082}		Any Myanmar medial
ov	Tag=ov	3	{1035 1062 1085}		Any Myanmar other vowel sign
c2	Tag=c2	7	{1004 1009-100A 100F 1014 1019-101A}		Consonants that may precede S16
c3	Tag=c3	10	{1004 1009-100A 100F 1014 1019 101D 1075 107A 107C}		Consonants that may precede S17
lv	Tag=lv	7	{102B-102C 102E 1030-1032 1036}		Long Vowel: tall AA, AA, II, UU, E, AI and Anusvara
sh_vowel	Tag=sh_vowel	8	{102D-1031 1083-1084 1086}		Shan vowel
k	Tag=k	1	{103A}		The Myanmar Asat (killer)
virama	Tag=virama	1	{1039}		The Myanmar Virama
C_103B	Tag=C_103B	30	{1000-1004 1006 100F-101A 101C-101D 101F 105C 1075-1079 107B-107D}		Consonants that can be followed by U+103B  ျ
C_103C	Tag=C_103C	30	{1000-1004 1006 100F-1019 101F 1022 105C 1075-1079 107B-107D 107F-1080}		Consonants that can be followed by U+103C  ြ
C_103E	Tag=C_103E	15	{1004-1005 1009-100A 100F 1014 1019-1020 105C}		Consonants that can be followed by U+103E  ှ
C_n103D	Tag=C_n103D	7	{1008 103B-103C 105A-105B 105D 107E}		Consonants that cannot be followed by U+103D  ွ
C_mon	Tag=C_mon	32	{1000-1003 1005-1007 1009-100A 100F-1021 105A-105D}		Mon Consonants
C_shan	Tag=C_shan	25	{1001 1004 1010-1011 1015 1019-101E 1022 1075-1081}		Shan Consonants
CMM1	Tag=CMM1	27	{1000-1002 1010-101A 101C 101F 1022 1075-1079 107B-107D 107F-1080}		Consonants that can be followed by medial sequence U+103B U+103D  ျွ
CMM3	Tag=CMM3	15	{1000-1002 1004 1010-1019 101F}		Consonants that can be followed by medial sequence U+103C U+103D  ြွ
CMM5	Tag=CMM5	9	{1004 1009-100A 100F 1014 1019-101C}		Consonants that can be followed by medial sequence U+103D U+103E  ွှ
beforePaoTone-set	combined = [[:dv:] ∪ [:m:] ∪ [:k:]]	26	{102B-1034 1036-1038 103A-103E 105E-1060 1062 1082-1084 1086}		Code points that can be followed by Pao tone (Union of dc, m and k)
common-digits	Tag=Common-digit	10	{0030-0039}		Digits from the ASCII range; ⍟
myanmar-digits	Tag=Myanmar-digit	10	{1040-1049}		Myanmar digits
has-ASCII-homoglyph	explicit	3	{1004 101D 1040}		All code points with homoglyph variants in the ASCII range
implicit	Tag=a	1	{1036}		The character tagged as a
implicit	Tag=c1	1	{103F}		The character tagged as c1
implicit	Tag=iv	8	{1023-102A}		Any character tagged as iv
implicit	Tag=M_mon	3	{105E-1060}		Any character tagged as M_mon
implicit	Tag=M_shan	1	{1082}		The character tagged as M_shan
implicit	Tag=pao_tone	2	{108F AA7B}		Any character tagged as pao_tone
implicit	Tag=sgaw_tone	1	{1064}		The character tagged as sgaw_tone
implicit	Tag=sh_tone	4	{1087-108A}		Any character tagged as sh_tone
implicit	Tag=t_long	1	{1038}		The character tagged as t_long
implicit	Tag=t_short	1	{1037}		The character tagged as t_short
implicit	Tag=sc:Geor	2	{10D7-10D8}		Any character tagged as Georgian
implicit	Tag=sc:Latn	3	{0063 006F 0073}		Any character tagged as Latin
implicit	Tag=sc:Mlym	3	{0D1F-0D20 0D31}		Any character tagged as Malayalam
implicit	Tag=sc:Mymr	108	{1000-1049 105A-1062 1064 1075-108A 108F AA7B}		Any character tagged as Myanmar
implicit	Tag=sc:Orya	2	{0B20 0B47}		Any character tagged as Oriya
implicit	Tag=sc:Zyyy	11	{002D 0030-0039}		Any character tagged as Common

Legend

Members or Ranges

Lists the members of the class as code points (xxx) or as ranges of code points (xxx-yyy). Any class too numerous to list in full is elided with "...".

Tag=ttt

A named or implicit class defined by all code points that share the given tag value (ttt).

Explicit

A named class defined by explicitly listing all its members.

Implicit

An anonymous class implicitly defined based on tag value and for which there is no named equivalent.

Combined

A named class defined by set operations on other classes using the following syntax:

[: :] - named or implicit character set

Reference to a named character set [:name:] or an implicit character set [:tag:]. A leading “^” before name or tag indicates the set complement.

∪, ∩, ∖, ∆ - set operators

Sets may be combined by set operators (∪ = union, ∩ = intersection, ∖ = difference, ∆ = symmetric difference).

Whole label evaluation and context rules

Number of rules	40
Used to trigger actions	7
Used as context rule (C)	26
Used as context rule (V)	3
Anchored context rules	26
Used only in another rule	6

The following table lists all named rules defined in the LGR and indicates whether they are used as trigger in an action or as context (when or not-when) for a code point or variant.

Name	Regular Expression	Used as Trigger	Anchor	Used as Context	Ref	Comment
leading-combining-mark	(start)[[\p{gc=Mn}] ∪ [\p{gc=Mc}]]	✔			[150]	RFC 5891 restrictions on placement of combining marks ⍟
hyphen-minus-disallowed	(((start))← ⚓︎)|(⚓︎ →((end)))|(((start)..\u002D)← ⚓︎)		✔	C	[150]	RFC 5891 restrictions on placement of U+002D - ⍟
label-has-ASCII-homoglyph	(start)[:has-ASCII-homoglyph:]+(end)			C, V		label contains only the three code points with ASCII homoglyphs
digit-mixing	([:common-digits:].*[:myanmar-digits:])|([:myanmar-digits:].*[:common-digits:])	✔				restrictions on mixing digits
no-mix-mm-i-and-mm-ka-v-ka	(\u1023.*\u1000\u1039\u1000)|(\u1000\u1039\u1000.*\u1023)	✔				WLE Rule No Mix Pair 1: do not mix MYANMAR I and MYANMAR KA VIRAMA KA in the same label
no-mix-mm-ha-asat-and-mm-pa-aa-asat	(\u101F\u103A.*\u1015\u102C\u103A)|(\u1015\u102C\u103A.*\u101F\u103A)	✔				WLE Rule No Mix Pair 2: do not mix MYANMAR HA ASAT and MYANMAR PA AA ASAT in the same label
no-mix-sk-sha-and-mm-ra-mha	(\u1061.*\u101B\u103E)|(\u101B\u103E.*\u1061)	✔				WLE Rule No Mix Pair 3: do not mix SKAW KAREN SHA and MYANMAR RA medial-HA in the same label
no-mix-mm-and-mon	([\u1004\u1008\u102E].*[\u1033\u105A-\u105B])|([\u1033\u105A-\u105B].*[\u1004\u1008\u102E])	✔				WLE Rule No Mix Mon and Myanmar Pairs 4, 6. 8: do not mix Mon specific code point with any Myanmar code point that has a Mon equivalent in the same label
no-mix-mm-kha-and-shan-kha	(\u1001.*\u1076)|(\u1076.*\u1001)	✔				WLE Rule No Mix Pair 7: do not mix MYANMAR KHA and SHAN KHA in the same label
S12	\u102D\u102F					long vowel sequence, For WLE Rule #8, #11
S14	\u1031\u102B					long vowel sequence, For WLE Rule #11
S15	\u1031\u102C					long vowel sequence, For WLE Rule #11
S_Sh2	\u1031\u1083\u103A					dependent vowel sequence for Shan Language. (See 3.3.3.2 of [Proposal-Myanmar])
S_Sh5	\u1082\u103A					dependent vowel sequence for Shan Language. (See 3.3.3.2 of [Proposal-Myanmar])
follows-c-m	([:c:]|[:m:])← ⚓︎		✔	C		Section 7, WLE 1, 2: Some sets must follow C or M. The sets are DV, LV, SV, S12-S15, S18-S20, S_MON3, S_Sh1-S_Sh5, s_Pao, OV, Anusvara
follows-c_103B	([:C_103B:])← ⚓︎		✔	C		Section 7, WLE 3:Rules of Medials combining with Consonants - U+103B  ျ  must follow consonant C_103B
follows-c_103C	([:C_103C:])← ⚓︎		✔	C		Section 7, WLE 3:Rules of Medials combining with Consonants - U+103C  ြ  must follow consonant C_103C
follows-c_103E	([:C_103E:])← ⚓︎		✔	C		Section 7, WLE 3:Rules of Medials combining with Consonants - U+103E  ှ  must follow consonant C_103E
follows-c-except-c_n103D	([[:c:] ∖ [:C_n103D:]])← ⚓︎		✔	C		Section 7, WLE 3:Rules of Medials combining with Consonants - U+103D  ွ  must follow any consonant except C_n103D
follows-c_mon	([:C_mon:])← ⚓︎		✔	C		Section 7, WLE 3:Rules of Medials combining with Consonants - M_mon must follow C_mon
follows-c_shan	([:C_shan:])← ⚓︎		✔	C		Section 7, WLE 3:Rules of Medials combining with Consonants - U+1082  ႂ  must follow C_shan
follows-cmm1	([:CMM1:])← ⚓︎		✔	C		Section 7, WLE 3:Rules of Medials combining with Consonants - MM1 must follow CMM1
follows-cmm3	([:CMM3:])← ⚓︎		✔	C		Section 7, WLE 3:Rules of Medials combining with Consonants - MM3 must follow CMM3
follows-cmm5	([:CMM5:])← ⚓︎		✔	C		Section 7, WLE 3:Rules of Medials combining with Consonants - MM5 must follow CMM5
follows-c-m-dv-1023-1025	([:c:]|[:m:]|[:dv:]|\u1023|\u1025)← ⚓︎		✔	C		Section 7, WLE 4: The Myanmar Great Saa must follow C or M or DV or U+1023 ဣ or U+1025 ဥ
follows-cc-mc-dvc-ovc	(([:c:][:c:])|([:m:][:c:])|([:dv:][:c:])|([:ov:][:c:]))← ⚓︎		✔	C		Section 7, WLE 5: C+K must follow C or M or DV or OV
follows-cc2-mc2-dvc2-ovc2	(([:c:][:c2:])|([:m:][:c2:])|([:dv:][:c2:])|([:ov:][:c2:]))← ⚓︎		✔	C		Section 7, WLE 5: C2+S16 must follow C or M or DV or OV
follows-cc3-mc3-dvc3-ovc3	(([:c:][:c3:])|([:m:][:c3:])|([:dv:][:c3:])|([:ov:][:c3:]))← ⚓︎		✔	C		Section 7, WLE 5: C3+S17 must follow C or M or DV or OV
follows-c-m-dv-and-followed-by-c	([:c:]|[:m:]|[:dv:])← ⚓︎ →([:c:])		✔	C		Section 7, WLE 6, 13: must follow C or M or DV and another C must follow
followed-by-c-end	⚓︎ →([:c:]|(end))		✔	V		Section 7.3: Variant is not defined if followed by C or end of label
between-c	([:c:])← ⚓︎ →([:c:])		✔	C		Section 7, WLE 7: Virama must be between two Cs (C+Virama+C)
between-virama	([:virama:])← ⚓︎ →([:virama:])		✔	C		Section7, WLE7: prohibited for C to prevent C+Virama+C_Virama
follows-or-precedes-virama	(([:virama:])← ⚓︎)|(⚓︎ →([:virama:]))		✔	C		Section7, WLE7: prohibited for some sequences to prevent override of WLE7
follows-c-m-lv-s12	([:c:]|[:m:]|[:lv:]|(:S12:))← ⚓︎		✔	C		Section 7, WLE 8: U+1037 (t_long) or U+1038 (t_short) must follow C or M or LV or S12
ck	[:c:][:k:]					c followed by k, for WLE #9
follows-beforeShanTone-set	([:sh_vowel:]|(:ck:)|(:S_Sh2:)|(:S_Sh5:))← ⚓︎		✔	C		Section 7, WLE 9: Sh_Tone must follow sh_Vowel or (C+K) or S_Sh2 or S_Sh5
follows-beforePaoTone-set-except-1037-1038	([[:beforePaoTone-set:] ∖ [\u1037-\u1038]])← ⚓︎		✔	C		Section 7, WLE 10: Pao_Tone must follow DV, M or K, except U+1037  ့  or U+1038  း
follows-beforeST4-set	(\u1031|\u1032|(:S12:)|(:S14:)|(:S15:))← ⚓︎		✔	C		Section 7, WLE 11: ST4 must follow U+1031  ေ , U+1032  ဲ , S12, S14, S15
follows-c-m-dv	([:c:]|[:m:]|[:dv:])← ⚓︎		✔	C		Section 7, WLE 12: ST1, ST2, ST3 or Sgaw_Tone must follow C or M or DV
follows-c-m-except-1002-1015-101D	([:m:]|[[:c:] ∖ [\u1002\u1015\u101D]])← ⚓︎		✔	C, V		WLE 14: U+102C  ာ  follows C or M except U+1002 ဂ, U+1015 ပ, U+101D ဝ

Legend

Used as Trigger

This rule triggers one of the actions listed below.

Used as Context

This rule defines a required or prohibited context for a code point C or variant V.

Anchor

This rule has a placeholder for the code point for which it is evaluated.

Regular Expression

A regular expression equivalent to the rule, shown in a modified notation as noted:

⚓︎ - context anchor

Placeholder for the actual code point when a context is evaluated. The code point must occur at the position corresponding to the anchor. Rules containing an anchor cannot be used as triggers.

(...)← - look-behind

If present encloses required context preceding the anchor.

→(..) - look-ahead

If present encloses required context following the anchor.

(: :) - rule reference

Non-recursive reference to a named rule.

( ) - group

An anonymous nested rule is used to group match operators.

(... | ...) - choice

When there is more than one alternative in a rule, the choices are separated by the alternation operator (...|...).

start or end

(start) matches the start of the label; (end) matches the end of the label.

. - any code point

. matches any code point.

*, +, ?, {n,m} - count operators

* indicates 0 or more, + indicates one or more, and ? indicates up to one instance. {n,m} indicates at least n and at most m instances.

[ ] - explicit character set

For explicit character sets that are part of a rule, only those members are shown that are defined in this LGR.

[: :] - named or implicit character set

Reference to a named character set [:name:] or an implicit character set [:tag:]. A leading “^” before name or tag indicates the set complement.

[\p{ }] - property

Set of all characters matching a given value for a Unicode property [\p{prop=val}]. Note: uppercase “\P” defines the complement of a property set.

∪, ∩, ∖, ∆ - set operators

Sets may be combined by set operators (∪ = union, ∩ = intersection, ∖ = difference, ∆ = symmetric difference).

⍟ - default rule

Rules marked with ⍟ are included by default and may or may not be triggered by any possible label under this LGR.

Actions

The following table lists the actions that are used to assign dispositions to labels and variant labels based on the specified conditions. The order of actions defines their precedence: the first action triggered by a label is the one defining its disposition.

#	Condition	Rule / Variant Set		Disposition	Ref	Comment
1	if label matches	leading-combining-mark	→	invalid		labels with leading combining marks are invalid ⍟
2	if label matches	digit-mixing	→	invalid		a label violating the restriction on digit mixing is invalid
3	if at least one variant is in	{out-of-repertoire-var}	→	invalid		any variant label with a code point out of repertoire is invalid ⍟
4	if label matches	no-mix-mm-i-and-mm-ka-v-ka	→	invalid		do not mix MYANMAR I and MYANMAR KA VIRAMA KA in the same label
5	if label matches	no-mix-mm-ha-asat-and-mm-pa-aa-asat	→	invalid		do not mix MYANMAR HA ASAT and MYANMAR PA AA ASAT in the same label
6	if label matches	no-mix-sk-sha-and-mm-ra-mha	→	invalid		do not mix SKAW KAREN SHA and MYANMAR RA medial-HA in the same label
7	if label matches	no-mix-mm-kha-and-shan-kha	→	invalid		do not mix MYANMAR KHA and SHAN KHA in the same label
8	if label matches	no-mix-mm-and-mon	→	invalid		do not mix Mon specific code point with any Myanmar code point that has a Mon equivalent in the same label
9	if at least one variant is in	{blocked}	→	blocked		any variant label containing blocked variants is blocked ⍟
10	if each variant is in	{r-set1 r-set2}	→	valid		any original label is valid
11	if each variant is in	{r-set1 set2-to-set1}	→	allocatable		any label with all original and variant forms from grapheme-set 1 is allocatable
12	if each variant is in	{r-set2 set1-to-set2}	→	allocatable		any label with all original and variant forms from grapheme-set 2 is allocatable
13	if at least one variant is in	{set1-to-set2 set2-to-set1}	→	blocked		any variant label with a mix of variant forms is blocked
14	if each variant is in	{allocatable}	→	allocatable		variant labels with all variants allocatable are allocatable ⍟
15	if any label (catch-all)		→	valid		catch all (default action) ⍟

Legend

{...} - variant type set

In the “Rule/Variant Set” column, the notation {...} means a set of variant types.

⍟ - default action

Actions marked with ⍟ are included by default and may or may not be triggered by any possible label under this LGR.

Note: The following variant types are used in one or more actions, but are not defined in this LGR: allocatable. This is not necessarily an error.