Concerning with my_MM, some of you might already know that we have long discussion and arguments about encoding when I released first localized WordPress package. I’ve choose user preferred pseudo standard encoding over Unicode consortium standard because no OS or devices supported Myanmar script when I start localizing WordPress. But now all major OS support Myanmar Scripts and they use Unicode consortium standard encoding. Android Kitkat support complex rendering system for Myanmar script, but not included Myanmar script fonts by default. Moreover MariaDB 10.0 support myanmar collation.
Since WordPress 3.5, I’ve been considering to use Unicode Consoritum Standard. But a lot of things need to do before changing to new encoding. I’ve developed encoding converter and change old encoding contents to new encoding. Starting from WordPress 4.0, localizationLocalization Localization (sometimes shortened to "l10n") is the process of adapting a product or service to a particular language, culture, and desired local "look-and-feel." package for my_MM will use Unicode Consortium standard encoding.
I have another thing to consider. Although I choose Unicode Consortium standard encoding, more than 90% of the web users do not use that standard. 100% of mobile device users use only non standard encoding. Even popular mobile device vendor such as Samsung, HTC, Huawei sell devices supported and fully localized with non standard encoding font called Zawgyi-One.
So I don’t know what to do with that non standard encoding.
Should I request separate localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/ site for non standard encoding for more user support?

#locale, #my_mm