Since everyone is experiencing the problem of Unicode Font error in Mon Wikimedia projects, I would like to ask if it is possible to use Font auto like Chinese and Japanese language Wikimedia projects. (Evidence sample=User Htawmonzel was experiencing a Unicode Font error on his computer, and was finding that the letter (င) was constantly being used in Mon Wikimedia projects, but I myself used to use the letter (င) as I was experiencing a problem with Unicode Font error. Since the letter (င) is not a Mon letter, if the letter (င) continues to be used, there may be confusion in the future Mon literature that cannot be solved by scholars, so I would like to stop using the letter (င), currently, many Mon people are experiencing Unicode font error problems, so they write Mon characters out of order, but the above reasons, Mon scholars have been facing problems related to Mon spelling until they cannot be solved. The Mon alphabet is only (ၚ) and not (င), but the true Mon spelling is ၚ်, not င်) If show the appropriate Font for the current Mon language, only Pyidaungsu Font produced by Burma is suitable, but other fonts are experiencing various errors. If Pyidaungsu Font is set to Mon Wikimedia projects Font auto, I think that everyone who uses Mon Wikimedia projects will not encounter any Unicode Font error problem, but can compare the characters with the Pyidaungsu Font that I gave to see what kind of Unicode Font error it is, thanks.--Music writer Dr.Intobesa of Japanese idol NMB48 and BNK48. (talk) 16:19, 8 May 2023 (UTC)Reply[reply]
Fonts depend on your system installation; we don't use all the same fonts. If you use a Chrome/chromium-base browser, open the development console and look at the tab showing the Elements, select the element in the display that looks wrong for you, right-click on it to select "Inspect" then the tab "Calculatedat the bottom of this tab you'll see which fonts are really used by your browser. You may see for example "Myanmar Text", or "Noto Sans Myanmar". It is important to know which font has the defect, because I do not see any defect in my "Unicode Font", so this does not look like a defect in Unicode. You may setup your browser or add a "custom.css" stylesheep in your user page to change fonts for the specific CSS selectors you need to override (you can see which CSS rule is currently selected in the "Styles" tab of the console when you "inspect" any element (you may need to override the font selcetion in different selectors for messages rendered in the message views or in the input box of the message editor. Verdy p (talk) 11:55, 9 May 2023 (UTC)Reply[reply]
Here are some known Unicode-encoded fonts for the Myanmar script : 'Noto Sans Myanmar', 'Noto Sans Myanmar UI', 'Noto Serif Myanmar', Padauk, Parabaik, TharLon, 'Myanmar Text', 'MyMyanmar Unicode', 'Win Uni Innwa', 'WinUni Innwa', 'Masterpiece Uni Sans', Myanmar2, Myanmar3, ThanLwin, Yunghkio... Not all of them support all combinations of base letters and diacritics (they may be tuned only for Burmese, not all Mon-Burmese languages, the Noto family is well maintained but may need to be updated; correctly positioning he diacritics requires more advanced fonts, otherwise they may overlap or could display a "+" sign below the base letter that is not entered in the expected order valid for Burmese, e.g. if there are intermediate diacritics; advanced Unicode-encoded and OpenType-based fonts require also advanced renderers that recognize their embedded tables the definitions for compositions, basic TrueType fonts cannot do that and renderers such as web browser do their best to approximate the rendering with fonts that are insufficiently defined). Verdy p (talk) 11:57, 9 May 2023 (UTC)Reply[reply]
Font error on my phone.Cast screen on my computer.
Hello @Verdy p, I have used various fonts, but except for Pyidaungsu Font, other fonts did not work well and I encountered various character error problems. Most of us Mon people use less computers and more phones, but Mon people have less money and use mobile phones, but not everyone has enough money to use a computer. It can be said that the main source of Font error is the phone, but although the Font error can be fixed on the computer, it costs a lot of money to fix the Font error on the phone. On my phone, it cost 500 Thai baht to solve the Font error, but the Google Chrome, Tiktok, Wikipedia software still has the Font error. The Font error problems that I mentioned above are not the only ones that I am facing, but almost everyone is facing them, but some people are Mon people who can't read Mon, and some are not Mon people, so I think they don't know about this font error problem. As a practical example, I suggest you check out this (starsi) page and I also want you to take a closer look at the phone and computer Cast screen that I gave you, Thanks.--𝓓𝓻.𝓘𝓷𝓽𝓸𝓫𝓮𝓼𝓪|𝒯𝒶𝓁𝓀 15:05, 9 May 2023 (UTC)Reply[reply]
Note that font problems on target devices is not something we can solve here. If this does not work properly for your prefered Mon language, the only thing you can do is to contact those that develop and maintain fonts for Myanmar (Mon-Burmese) script. For example submit bug request to the Google Noto project if there's a need to fix "Noto Sans Mayanmar". But then you'll have to wait to find usable smartphones that can feature this updated font. Some devices allow installing custom fonts, or allows it via a store (like Google Play on Android, or AppleStore on iOS). If you run Windows or Linux, it is generally easy to install other fonts on your system.
Still you have still not said which fonts were used above in yoru screenshots so we cannot guess reliably which font has the correct renderning expected for Mon languages (or other languages like Karenic langauges written with it) and which one is incorrect. Translatewiki.net cannot solve rendering problems, but would be pleased to know which font is working and then there could be preferences changed in CSS especially for Mon languages (the default fonts generally workl well for Burmese, but may have not been tested for complete coverage of for other languages. However this is also documented in the Unicode standard itself: renderers do their best as they can with the avialable fonts, But approcimative rendering causing overlaps or incorrect relative positioning is accepted as a transition as this strill does not makes the text completely undecipherable (that problem is not specific to the Myanmar script, it also occurs with various combinations of base Latin letters and diacritics, where a advanced positioning is only possible if fonts contain enough data tested for covering more languages).
Over time, operating systems are supposed to update their fonts for better coverage, but in the interim, all you can do is to install other fonts on your system. As well, opensourced projects cannot distribute these fonts directly (e.g with 'webfont' technology), if they are not redistributable, due to their licence (Noto fonts can be redistributed, but this is probably not the case with all the Myanmar fonts I listed above, some of them being distributed only by OS vendors with their own propriatery licences. So if you want to continue on this, please identify the fonts that work and those that don't, and may be you'll be able to know who to contact to get a fix for covering your favorite languages. And I don't know that "Pyidaungsu" font and where it comes from, so it may not be proprietary. If you think it is correct, then submit bug requests to the Google Noto font project and explain very precisely what you expect (may be this doesnot wotrk because you've violated an expected encodig order or used the wrong characters (there may be the need to input characters that are not present in the input method proposed by default on Android if you've set your input to the "Burmese" language, and may be what it is needed is to develop a new input method or keyboard layout, more suitable for Mon languages).
You say that the Pyidaungsu font costs you 500 Thai baht, so it is very likely proprietary and unfortunately we cannot redistribute it for free for an unlimited number of users: you need to fing a suitable font with a free licence (that's why I suggest you to submit a bug request to the Noto project, including some screenshots of what is expected). Once an open font works, it will work here, as well as on Wikipedia, Tiktok, and almost other websites, as long as your device is updated to have that suitable font. Translatewiki.net or Wikimedia don't develop or support any font with a suitable open licence, so you need to look for such projects developing that support. For now the Myanmar script works well ni Burmese with existing common fonts (even if they have problems for other languages), so this is not a bug that can be solved here. Verdy p (talk) 14:27, 10 May 2023 (UTC)Reply[reply]
Note that https://mcf.org.mm/pyidaungsu-font-version-history/ says that Pyidaungsu requires the support of the "mym2" script tag in featured of the font (instead of the legacy "mymr" tag) in their shaping engine. It is very likely that most existing Unicode-based font for the Myamar script are using "mymr" and do not contain any "mym2" feature table. And this is probably what happens with Android's building shaping engine. That website explains what can be done to use that font on Windows, but says nothing at all for other OSes.
On development site for 'Noto Sans Myanmar" font, you can also read this issue at "https://github.com/google/fonts/issues/412" where people complain not seeing the correct result, but in fact the strings were actually not correctly encoded in the standard way, but only on system using "tweaked" fonts. So make sure you first respect the encoding standard for the texts you want to test with suitable fonts. The Opentype specifications also contains this interesting note:
"The OpenType lookups in a Myanmar font must be written to match glyph sequences after re-ordering has occurred. OpenType fonts should not have substitutions that attempt to perform the re-ordering. If a font developer attempted to encode such reordering information in an OpenType font, they would need to add a huge number of many-to-many glyph mappings to cover the general algorithms that a shaping engine will use."
What this means is that it's not up to the Opentype font to apply the reordering suitable for the Maynmar script, but to the shaping engine used by the renderer (so you also need an up-to-date renderer to perform the reordering preparation, before searching for lookups in OpenType fonts; as well the lookups are supposed to be made in the appropriate order: subtitutions first, then positioning; and substitution occurs in separate steps: local substitutions for specific languages, using per language feature definitions in the OpenType font, then generic substitutions; and not all features are required in fonts, notably "local" subsitutions for specific languages are optional, as well as positioning features, so a font is conformign even if it shows non-optimal placements with kerning and mark-to-mark positioning to avoid overlaps in complex clusters).
As well, there will soon be an update from Unicode 15.0 to Unicode 15.1 that will change some published algorithms to handle complex clusters in South-Asian and Southeast-Asian languages (notably but not only for automatic linewrapping by better syllable-based segmentation). Soon after the final publication (still in beta), there will be updates to web browsers and possibly in their shaping engines. Note that OpenType specifications for Myanmar script were updated last year (recent versions of Windows 10/11 have that support, but possibly not all past versions, and possibly not Android on older smartphones; so make sure your webbrowsers are also up-to-date if they feature their own text shaping engine that should support the "mym2" script tag for the recommended OpenType support, and avoid using very old legacy fonts with "mymr" script tag, based on incorrect specifications).
If you see "+" signs below some consonant glyphs, or if composition of diacritics does not show the proper placement (with overlaps), the most likely cause is in fact not the font, but the shaping engine built in the renderer of your web browser, that still does not support the "mym2" OpenType specification, but only the legacy "mymr" specification which depends on very large substitution/positioning tables built in fonts (with many possible orders) that are no longer supported: the legacy shaping "mymr" engine (no longer recommanded even by authors of the Pyidaungsu font) doesn't order properly by itself the glyphs and only support texts encoded in a non-standard way with specific encoding orders of clusters. So in that case, you should try with another browser complying with the latest OpenType specifications (that's why it works on Windows with Edge or Chrome, but possibly not with old Android smartphones with their outdated builtin browser). Verdy p (talk) 14:56, 10 May 2023 (UTC)Reply[reply]
The following are the problems I encountered with my Mon font character error (In 2014, when I was using a computer with Windows 7, every font at that time had a variety of Mon character errors, so I had to use A1Mon Font and Zawgy Mon Font in order to write Mon, but A1Mon Font and Zawgy Mon Font are still not the best and still have various weaknesses. In 2018, I used Anonta Unicode font in Windows 8.1, but it is still not the best, but Anonta Unicode font can be used in Mon and Eastern Pwo Karen languages, but it is not suitable for use in other languages. In 2019, 2010 Windows 10 I used the MUA Office font, but I later found out that the MUA Office font has the wrong Mon script code(MUA Office font Mon script code misplaced reference). After 2022, when I was looking for a suitable font for both the Mon language and other languages, I started using the Pyidaungsu Font as directed by the Anonta Facebook page, but Pyidaungsu Font has not been updated yet, so it is not convenient to use today's new version of phone and Windows 11 anyway, Pyidaungsu Font is still the only font that is convenient to use for the current Mon language. Please see the following link for the code of Mon writing with Pyidaungsu Font, but now the Mon writing codes I have given are 100% true. I tried using Google font, which is widely used in the current wiki, but I found that there are many wrong characters in the Mon language code. I am a person with poor technical knowledge, so I explained only as I understood it, but I pray that you understand what I have told you, thanks. 𝓓𝓻.𝓘𝓷𝓽𝓸𝓫𝓮𝓼𝓪|𝒯𝒶𝓁𝓀 15:54, 12 May 2023 (UTC)Reply[reply]
so please report yuor findings to Google's opensourced Noto project. You may exhibit there screenshots about what looks good for your Mon language with a sample with the font tht works for you, and what does not work and looks wrong with "Noto Sans Myanmar". These issues are tracked in their GitHub project. Yuo may also look precisely at what is currently documetned in the "mym2" OpenType specification (with the 2022 update). May be Noto has still not integrated the 2022 update and there are pending tasks to fix it and test it. Those projects need you samples to test their results. The syntax of Myanmar grapheme clusters (documented in OpenType) is quite complex: there may be subltle errors of interpretation, but there are a lot of experts Noto opensource designers. Of course, supporting more Mon languages must NOT break existing texts written in Burmese or Rankhine (the two major languages using that script, but not using or needing all the features documented in OpenType, which also focuses other languages using that script, including Sanskrit and Pali or Karen languages, with their own "locl" features when they are different from the default language-neutral behavior used in the Burmese language). Verdy p (talk) 18:20, 16 May 2023 (UTC)Reply[reply]
I don't have any contact to report to solve this issue, but I have been trying for a long time to contact the Unicode organizations to resolve this issue. Currently, Mon people who are proficient in Mon literacy, including me, are facing various difficulties in writing Mon because of the Unicode font error, but because of the Unicode font error, some Mon people have become undisciplined in writing Mon, due to some Mon people's irregular writing of Mon script, I explain the problem of Mon spelling to those interested in the Mon language so that they can understand it.
To type these clusters
Concatenation of letters:
Type these keyboard keys:
Numbers without Shift + F
က္က
(က + ◌္ + က)
(u + F + u)
က္ခ
(က + ◌္ + ခ)
(u + F + c)
ဂ္ဂ
(ဂ + ◌္ + ဂ)
(* + F + *)
ဏ္ဌ
(ဏ + ◌္ + ဌ)
(P + F + X)
ဍ္ဎ
(ဍ + ◌္ + ဎ)
(! + F + ~)
ဋ္ဌ
(ဋ + ◌္ + ဌ)
(# + F + X )
ဏ္ဍ
(ဏ + ◌္ + ဍ)
(P + F + !)
ကာဲ
(က + ◌ာ + ◌ဲ)
(u + m + J)
ကောံ
(က + ေ + ◌ာ + ◌ံ)
(u + a + m + H)
တိုင်
(တ + ◌ိ + ◌ု) + (ၚ + ◌်)
(w + d + k) + (i + f)
တီု
(တ + ◌ီ + ◌ု)
(w + D + k)
တဵု
(တ + ◌ဵ + ◌ု)
(w + ^ + k)
တုဲ
(တ + ◌ဲ + ◌ု)
(w + J + k)
တုံ
(တ + ◌ု + ◌ံ)
(w + k + H)
ပါဲ
(ပ + ◌ါ + ◌ဲ)
(y + g + J)
ပါံ
(ပ + ◌ါ + ◌ံ)
(y + g + H)
ပါ်
(ပ + ◌ါ + ◌်)
(y + g + f)
ကြီု
(က + ◌ြ + ◌ီ + ◌ု)
(u + j + D + k)
ပြီု
(ပ + ◌ြ + ◌ီ + ◌ု)
(y + j + D + k)
ကိုဟ်
(က + ◌ိ + ◌ု) + (ဟ + ◌်)
(u + d + k) + ([ + f)
ကီု
(က + ◌ီ + ◌ု)
(u + D + k)
ကဵု
(က + ◌ဵ + ◌ု)
(u + ^ + k)
သၚ်
သ + (ၚ + ◌်)
o + (i + f)
သၚ်္ချာ
သ + (ၚ + ◌် + ◌္ + ခ + ◌ျ + ◌ာ)
o + (i + f + F + c + s + m)
သၚ်္ချေ
သ + (ၚ + ◌် + ◌္ + ခ + ◌ျ + ◌ေ)
o + (i + f + F + c + s + a)
ပိုဲ
(ပ + ◌ိ + ◌ု + ◌ဲ)
(y + d + k + J)
တ္ၚဲ
(တ + ◌္ + ၚ + ◌ဲ)
(w + F + i + J)
ကဏ္ဍ
က + (ဏ + ◌္ + ဍ)
u + (P + F + !)
ဂန္တွာ
ဂ + (န + ◌္ + တ + ◌ွ + ◌ာ)
* + (e + F + w + G + m)
နု
(န + ◌ု)
(e + k)
နူ
(န + ◌ူ)
(e + l)
နျ
(န + ◌ျ)
(e + s)
နှ
(န + ◌ှ)
(e + S)
ဣန္ဒြိယ
ဣ + (န + ◌္ + ဒ + ◌ြ + ◌ိ) + ယ
E + (e + F + K + j + d) + ,
ဣန္ဒြေ
ဣ + (န + ◌္ + ဒ + ◌ြ + ◌ေ)
E + (e + F + K + j + a)
မည္ည
မ + (ည + ◌္ + ည)
r + (n + F + n)
ဍုၚ်
(ဍ + ◌ု) + (ၚ + ◌်)
(! + k) + (i + f)
စှ်ေ
(စ + ◌ှ + ◌် + ◌ေ)
(p + S + f + a)
စှော်
(စ + ◌ှ + ◌ေ + ◌ာ + ◌်)
(p + S + a + m + f)
တိံ
(တ + ◌ိ + ◌ံ)
(w + d + H)
သိၚ်္ဂဳ
(သ + ◌ိ) + (ၚ + ◌် + ◌္ + ဂ + ◌ဳ)
(o + d) + (i + f + F + * + T)
ကၠုၚ်
(က + ◌ၠ + ◌ု) + (ၚ + ◌်)
(u + Y + k) + (i + f)
တၟေၚ်
(တ + ◌ၟ + ◌ေ) + (ၚ + ◌်)
(w + R + a) + (i + f)
This is the 100% Mon spelling system on the computer from Pyidaungsu Font that I use, it's 100% Mon spelling, but I don't know how it looks on other computer fonts. Currently, I am studying many other languages and writing a dictionary in order to improve the Mon language, another problem with Mon spelling is Thai-Mon and Korea-Mon, for this reason, I forbade mixing Thai-Mon and Mon-Burma spellings on the wiki, I think User Octahedron80 was very angry with me because of my forbade, but I think User Octahedron80 is angry because he doesn't understand my actions. if have to show evidence of Mon spelling, for example (The Mon people call the Burmese people (Hamaeဟမာ) but Since the pronunciation of (Hamaeဟမာ) cannot be used in Mon literature, it will only be correct to write it as (Bamaeဗၟာ) in Mon literature.) by studying this example, will understand how deep Mon literature is, therefore, the Mon language has been borrowed and adopted by many peoples, including Thailand and Burma. In the first century AD, due to the close similarity between the Mon language and the Khmer language, Mon scholars borrowed many Sanskrit words from their mother tongue as a modification of the Mon language. The letter က that we see today was borrowed by the Mon people from King Ashoka, this letter က was modified many times by Mon scholars, but Burmese scholars slightly modified this က alphabet and continued to use it in the same way as the Mon people used it, but what is hurtful and resentful is that some Burmese scholars are spreading propaganda about this letter က by falsely saying that it is their own alphabet, thanks. 𝓓𝓻.𝓘𝓷𝓽𝓸𝓫𝓮𝓼𝓪|𝒯𝒶𝓁𝓀 19:24, 18 May 2023 (UTC)Reply[reply]
Your table above was not properly encoding the sequence of letters and diacritics in the first column (not the way it was composed according to the second column): it contained extra characters (dotted circles, that should be present only in the second column after "+" signs and before a diacritic). As well some characters were transformed into emojis, by some unsafe wiki editor. Once I cleanup the encodings, all these strings are properly displayed (with Noto Sans MyanMar at least). So my opinion is that you use a broken (or not up to date) webbrowser, whose input method for the Myanmar is definitely wrong (probably based on the deprecated OpenType 'mymr' specifications instead of 'mym2', like current versions of Chrome, or Edge, that specification being also strongly recommanded by designers of the Pyidaungsu Font themselves). It should then be interesting to know which web browser, version and OS you use (which cannot properly handle 'mym2' sequences and cannot properly even use that 'Pyidaungsu' font or the 'Noto Sans Myanmar' font which is the default on Android. If users are trying to use an old browser with old fonts based on the old 'mymr' specification, all encodings will be broken with the current standard! (For fun, I also color-coded the delimitation of syllabic clusters). Verdy p (talk) 13:35, 23 May 2023 (UTC)Reply[reply]
I also tested to view the table above after installing the current (free!) version of Pyidaungsu Font, and everything is OK (the same is OK on Windows 11 with its builtin font for the Myanmar script). Stop using your broken fonts (that you should not have even paid from an unsafe source!). Use the original website from the official designers to load that font if you wish (but not broken files that you find shared illegally on some personal Google Drive, or sold illegally), or use 'Noto Sans Myanmar' (from Google Noto website), and all works as expected with a modern and supported browser for Android or Windows (I did not test what happens with Safari on MacOs or on iPhones). Verdy p (talk) 13:52, 23 May 2023 (UTC)Reply[reply]
Note that I could not test the ASCII-based input mehod that you present in the third column. If such input method is used however, with all clusters correctly entered in the correct order [the central (or top) consonnant, then subscripted consonnants separated by combining joiners, then other subscripted diacritics (like nukta points), then "enclosing" diacritics, then diacritics prepended to the right, then diacritics added on top (from left to right), then trailing diacritics on the left], it should generate that order in the Unicode sequence even if diacritics are entered in the wrong order. Such sequence should be in canonical order
Not all text renderers support the expected visual reordering if sequences are not first encoded in the canonical order, and MediaWiki editors will not necessarily force that canonical normalization order (based on Unicode when editing or saving messages), but it strongly recommanded to use this "NFC" encoding form. Renderers need to parse strings and make limited lookups in strings to compute the vidual order inside each syllabic clusters in order to use fonts with Unicode mappings (this is the case for all OpenType fonts), but they have limitations on "overlong" sequences (even if Unicode says that they should support sequences with at least 30 characters). It's the renderer that then use fonts that don't need to be made aware of all these ordering details (provided that they are following the correct set of "Opentype features" for the script (at leasr those that are "required" by OpenType; language-specific behaviors in the "locl" feature however are not required, they may be used to alter some glyph forms or positioning for specific languages, but the default behavior should be the one that works at least in the Burmese language, then possibly in Rakhine, or some Mon or Karenic languages even if they are not the best forms for them).
I made various tests on Windows, Linux and Android, and all looks fine for me with the "Noto Sans Myanmar" font or the default system fonts provided for the script, as long as texts are correctly encoded and normalized.
I also took various historic texts using the Myanmar script found in Wikisource, and found no defect when they were properly edited and validated by experienced users: they all work properly with "Noto Sans Myanmar" as well as with "Pyidaungsu" or with the system default fonts on modern and supported OS versions. Verdy p (talk) 15:21, 23 May 2023 (UTC)Reply[reply]
The font error problem that we face every day is compared in the following image, I myself am a person with little technical knowledge, so I don't really understand how to solve this problem. Currently, I created global.css to temporarily solve this problem, but it still doesn't work in practice. Regarding this issue, in my opinion, I think that some people will have a hard time explaining it because they don't have the ability to understand the Mon language and Western Pwo Karen language, only Mon and Western Pwo Karen languages have this problem, but the Western Pwo Karen language is involved in this problem due to the similarity of writing with the Mon language, thanks. 𝓓𝓻.𝓘𝓷𝓽𝓸𝓫𝓮𝓼𝓪|𝒯𝒶𝓁𝓀 11:21, 26 May 2023 (UTC)Reply[reply]
I do not see any bug here in that last table. Waht you get is the normal default behavior of Myanmar script. But the default Microsoft's font you tried to use and exhibit does not include the *optional* features, notably not those that allow languages than Burmese to exhibit different layouts (such as the absence of rotation of the subscripted consonants in the third row, or the replacement of subscripted consonants by the left part of that consonant glued to the left and not below: these require the "locl" feature to be enabled, with necessary subsitution/positioning mappings for a list of specific languages; this also requires the application to properly pass the language to be rendered (normally, webbrowser provide these mappings in their text renderers using Opentype fonts by converting from BCP47 language tags to OpenType language codes). The alternative is to use other OpenType fonts that change the default behavior (but then these fonts won't work well in Burmese unless these fonts provide as well a "locl" feature with a mapping for the Burmese language: this is permitted by OpenType specificafor all features that are not defined as "mandatory" but are rather optional; however developing those alternatives that chan ge defaults just complicate the maintenance work for font designers, if they need to define the same font, but for two different set of defaults targetting different language without needing the renderer to support such language switchings; generally fonts are designed with default behaviors matching what is the most commoàn convention used b most peoples; there are some font tools that allow switching the default behaviors selected in OpenType fonts by changing priorities betweel languages; but these tools are very technical and generally not used by average users; as well Windows provides no way in its list of installed "Fonts" to select the default behavior to be used in absence of a language code being specified to the text renderer, as a matter of user's preference, and the same is true for text renderers made for Android or iOS, where the supported "default" behavior is always targetting the major languages usnig the script and variants can only be rendered in documents that have properly set the language they are trying to represent, and without such information, renderers are language-neutral and only know the script you're using, not the language itself). Verdy p (talk) 18:11, 26 May 2023 (UTC)Reply[reply]
And did you look at the table above, does it look fine to you? Verdy p (talk) 18:11, 26 May 2023 (UTC)Reply[reply]
Finally, your last screenshot showing text rendered with Microsoft's "Myanmar Text" font exhibit no severe errors. The top white lines may not be optimal, but they are correct, the one just above yellow line (showing 23 clusters) is a case where the subscripted consonnant is rotated differently between Mon and Burmese, but it remains readable (changing the rotation requires a "locl" feature to be implemented in that font). The last 5 rows are also not completely wrong, even if the exact placement of diacritics is not optimal (the 7th and 8th line show undesirable overlaps that obviously should be fixed to be really readable, I can ackowledge that, but others are just minor adjustment and are still perfectly readable and not confusable!). We cannot do here anything about that: ask support to Microsoft to better tune its Opentype font (thisi s strange that they did not do it by default, given that Microsoft maintains and published the specifications for the OpenType standard, and everything is correct in that specification, but not fully implemented in the font currently provided by Windows which just provides the minimum required). We are not developing and supporting fonts on this wiki, this is too technical and requires typographic skills that are hard to find, especailly for Brahmic abugidas with complex shaping behaviors and when the source information for needed changes exists in languages that have very few active users and no skilled developers. Microsofot will likely update its font only after tests have been made elsewhere and discussed: that's why the opensource Noto project is interesting: if Noto is fixed, and accepted, it can be exhibit to Microsoft to instruct them what they need to do in their own fonts, but Microsoft is very careful about changing fonts if changes may break existing applications depending on the old behavior and without enough people to notice the differences. And if render all these clusters using "Noto San Myanmar" on Windows as well as on Android, all is perfect (so this is clearly an issue of a specific Microsoft font from your version of Windows). Verdy p (talk) 18:29, 26 May 2023 (UTC)Reply[reply]
For more information, you may need to contact Microsoft Typography or use its feedback form on https://learn.microsoft.com/en-us/typography/font-list/myanmar-text; prepare a web or wiki page, or PDF exhibiting your problems, and showing the difference you get with other fonts. Send them a link to the document to look at. Also make sure you have at least version 1.18 of that font (designed for Windows 10) or version 1.20 (current version for Windows 11, which may already have some fixes); that font added in Windows 8 was an old version 1.00, with some fixes with version 1.10 in Windows 8.1; there was no builtin support in Windows 7 (except possibly in old versions of MSOffice and with some Office updates). Verdy p (talk) 19:29, 26 May 2023 (UTC)Reply[reply]
Error on Samsung
No problem on Vivo
As for this issue, based on my testing, I think it's due to the type of device, but I am currently experiencing this problem only with the Samsung model, when I tested it on Vivo and iPhone, this problem did not occur at all, but in my opinion, Samsung may have this problem because of Zawgyi and Unicode installed, my current Asus Windows 11 is experiencing this problem, I can't understand why Asus Windows 11 is having this problem. the Sony Windows 8.1 that I used at one time did not have this problem at all, I changed my current Asus Windows 11 to Windows 10, but I was having this problem in Photoshop, and it was very difficult to write Mon, I'm so frustrated with this issue and I can't explain it anymore, but if you know how to solve this problem please suggest, thanks. 𝓓𝓻.𝓘𝓷𝓽𝓸𝓫𝓮𝓼𝓪|𝒯𝒶𝓁𝓀 15:31, 28 May 2023 (UTC)Reply[reply]
Android devices must also have updates for their fonts. Unfortunately this is not something we can solve by support for specific devices. You may find ways to install updated fonts on your device, either from Samsung with their firmware updates, but be careful about some customization tools like skins, that may replace system fonts. There may exist apps that allow you to install updated version of "Noto Sans Myanmar" loaded from Google Noto site, if Samsung does not feature this update i their firmware updates or app updates for the webbrowser you use (Samsung has its own version of Chrome, if this does nto work, you may try installing Chrome from Google Play, which is often more reliable than Samsung's app store). Here again, if this does not solve the issue, contact the Samsung support, there's not much translatewiki.net can do for specific devices or webbrowsers.
Note that the default fonts on Windows 10 and Windows 11 are featuring different versions of the "Myanmar Text" font. On my Windows 11, I have version 1.20 (Microsoft's typography says Windows 11 supports at least version 1.19, so I suppose it was updated; on Windows 10 it is an older version, but there may be updates or you can visit Microsoft Typography site or use the Fonts control panel to update this font; if this still does not work, download and install "Noto Sans Myanmar" (or update to the last version, because there's no automated update from Microsoft for Noto fonts, and possibly not even from Google Chrome itself).
As well we can't offer support for other unrelated apps, especially proprietary ones like Photoshop (out of scope for Translatewiki.net, or Wikimedia projects, or any existing projects supported on this wiki), contact their respective vendor support). Verdy p (talk) 02:01, 29 May 2023 (UTC)Reply[reply]
Saraiki language
Code for Saraiki language is used skr-arab. When Saraiki language is employed in sites it uses Urdu or Punjabi translations in many places in the sites. I think this is due to fallback. So this problem be solved. Urdu and Punjabi translations should not be shown.
2nd problem is that in many place translated to skr-arab are shown in English for example Islamic months are translated https://translatewiki.net/wiki/MediaWiki:Hijri-calendar-m10/skr-arab
But in https://skr.wikipedia.org/wiki/سانچہ:تقویم_صفحہ_اول it is English language. This problem also should be solved. Saraiki (talk) 09:10, 10 May 2023 (UTC)Reply[reply]
There are two different (but interrelated problems) here. The first problem is that Saraiki has a somewhat unusual configuration, where there are two language codes in use: skr and skr-arab. The former is not used, and is just set to fall back to the latter.
Due to the way fallbacks work, they are not inherited. So because skrwiki (the Saraiki Wikipedia) is set to the language skr, it only falls back to skr-arab, while skr-arab's fallback of ur, pnb is essentially ignored.
The second problem about MediaWiki:Hijri-calendar-m10/skr-arab is related to the first problem. The message is not actually translated – it may appear to be if you just visit it, because it is actually displaying the fallback from ur. That, however, is not displayed on the Saraiki Wikipedia because that Wikipedia's fallback chain is essentially just skr -> skr-arab -> en; if you want the Wikipedia to also fall back to Urdu and Punjabi (it seems to me like you're requesting the opposite, though), we'd have to add ur, pnb to MessagesSkr.php in addition to MessagesSkr_arab.php. A better solution, though, and my recommendation, would be to set skrwiki's language to skr-arab directly, thus "bypassing" that fallback. This can be done via a request in Phabricator.
If you wish to remove the fallbacks to Urdu and Punjabi, we would probably need consensus to do that from the Saraiki Wikipedia and Wiktionary communities. But to be clear, what would happen then is that it would just fall back to English instead. Since Saraiki is a right-to-left language and English is left-to-right, the results may look worse (but it would be even more obvious what is untranslated), so there are pros and cons depending on which way you look at it.
Hi @Saraiki, just to make sure: When a message is not translated into Saraiki, in which language should it appear: Punjabi, Urdu, English, or something else? Amir E. Aharoni (talk) 10:26, 10 May 2023 (UTC)Reply[reply]
@Amire80 @Jon Harald Søby I think that if it is not translated, It should be in English only. Because this will show that this message is untranslated. Punjabi and Urdu are confusing. Saraiki (talk) 11:36, 10 May 2023 (UTC)Reply[reply]
Its ISO language code is "bzs". Brazilian Sign Language (M525x528S14c0a476x498S14c11489x472S29904511x496 in bzs) is the first language of deaf communities in Brazil (so should fall back to pt-br). It has a test Wikipedia in Incubator and many lexemes in Wikidata. SignWriting (a vertical script) is the dominant writing system, but its Unicode is not used. To represent the signs, the wikis use ASCII strings, which can be properly displayed using code (like: 1 and 2). Translatewiki already supports American Sign Language, using the same mechanism. I'm making this request in order to add a monolingual language code to Wikidata (apparently, this is needed to the language to be requested here). I can myself translate basic sentences, and if necessary I can try contacting native speakers for help. EnaldoSS (talk) 17:48, 13 May 2023 (UTC)Reply[reply]
Portal:bzs exists but shows that it's still disabled for now. However the "ASCII notation" used is not really a Latin transcription. it is a complex notation, like programming languages or SVG, and does not easily support plain-text searches (due to many numerical positions encoded, it requires a complex computing rule in search engines to round up them); as well it allows multiple encoding for various sequences (the current standard has not defined any canonical order for encoded writing blocks that are composed with multiple glyphs, each one have varable attributes, and the stadnard says that this order is not sdignificant in most cases (except some overlaps). Supporting that script would require extensive development, using properties that are still not encoded in Unicode; as well that notation does not want to use the encoded SignWriting unicode characters that should still finally be used to render the interpreted sequences by a custom renderer. may be tyhis will change later (possibly by adding other combining characters or grapheme joiners to the SignWriting Unicode block(s) and more properties like those defined for Emojis). For now I doubt this will occur soon (this is also the case for other scripts with complex layout, like Egyptian hieroglyphs, that are supported in a limited way for now in Mediawiki using a specific extension to render them as images, but very impractical for inputing text by common users). Supporting the script first requires developing an input method, then improving the search engine capabiltiies, then determine rules to generate a usable "canonical" form which could be the good base to develop a stable orthography for which it is possible to reach to a consensus and to make links between articles working as expected, without having to define tons of page redirects).
So for now, all that can be done is to propose a way to allow supporting OCR-like features, e.g. in Wikisource to reproduce existing documents with trustable and verifiable sources, that may otherwise only be represented by scanned or photographed facsimiles; it will be possible to define very short extracts of text, but very write inoovative texts editable by multiple persons (but it would be possible to use it to communicate privately between users, each one writing it as they want for their own talks). But it will be very hard to have a usable and maintainable Wikipedia or Wiktionnary for example with extensible, improvable and correctable articles, if we don't have a relatively stable orthography described by some standard (the existing source foundation for the SignWriting standard is still not ready for that, and is studying other forthcoming options, that may later need additions to Unicode and or CLDR, and possibly new standard algorithms). Verdy p (talk) 18:24, 21 May 2023 (UTC)Reply[reply]
EnaldoSS, thanks for the request. I want to verify how should the name of the language appear: "M525x528S14c0a476x498S14c11489x472S29904511x496" or perhaps "Língua brasileira de sinais"? The American Sign Language appears as "American sign language". It's not necessarily good, but that's how it appears. --Amir E. Aharoni (talk) 12:05, 23 May 2023 (UTC)Reply[reply]
The syntaxic notation is not really SignWriting, it's an ASCII notation that should be handled by a server-side extension (like WikiHiero) or by some client-side javascript plugin. It will be complex to do especially with the vertical layout, or with multingual contents. For now SignWriting characters from Unicode alone are not sufficient (it only encodes basic glyphs, and some modifiers for color filling or rotations, but not positioning within "signbox" clusters (there's no specied cluster joiners and modifiers to properly delimit the cluster boundaries; the vertical layout of clusters is a secondary problem (but this vertical layout is optional in SignWriting, exactly like it is with Han ideographs, Mongolian, or Yi scripts ; initially the SignWrting script was designed for horizontal layout, the vertical one was suggested to allow another refinement, i.e. horizontal placements for representing "roles" when there are multiple relaetd speakers and a central narrator: the whole signbox is moved to the left or right at different positions, that are easier to see in the vertical layout, but where the horizontal layout would require additional leading signs to specify the played roles; note also that signboxes do not rotate when switching between horizontal and vertical layouts, but this is not the case of punctuations which are horizontal in the vertical layout, but rotated and vertical in the horizontal layout; as well SignWriting does not specify the roles of whitespaces for justification of rows of text, which also switch their horizontal vs. vertical metrics; and it's not clear how signboxes are separated in true SignWriting, because they are invisible, but this separation is important for allowing break opportunities in long texts and some whitespaces may be used for that: in the ASCII-based notation, signboxes are sometimes represented using hyphens to join signs and modifications, and spaces and puntuations to separate them; all this is not specified in the current Unicode encoding, so these Unicode characters may only be used alone, but not for proper text, just like this is the case as well for Egyptian hieroglyphs).
A proper SignWriting translation would still need to be rendered as images, not as plain text, because this is still not possible, except for invidual signs that are part of signboxes, and for whitepaces and punctuations that do not participate to signboxes but separate them and have a simple linear layout, and that also are possible break opportunities (forbidden in the middle of signboxes). Verdy p (talk) 12:23, 23 May 2023 (UTC)Reply[reply]
I can update them, initially there was no names at all (so they were already using fallbacks, except for the autonym of [crh-ro] which was set probably by Amire as just ""tatarşa" and not "tatarşa (Romanya)", but this was discussed above in the "Make a language variant active" discussion started in 27 March up to 3 May), but you're right they were based on Romanian (as a "reasonable" fallback). They were just initialized (basically for English used in category names). Look at these updates now. Verdy p (talk) 10:20, 14 May 2023 (UTC)Reply[reply]
In Crimean Tatar (Latin) is written "tatarca (Romaniya)", it will be better when it is "qırımtatarca (Romaniya)" and for the code crh is written "qırımtatarca / къырымтатарджа", you can rename it as "qırımtatarca / къырымтатарджа / tatarşa". Otherwise all seems to be ok. Thank you! Zolgoyo (talk) 10:46, 14 May 2023 (UTC)Reply[reply]
OK done, I added the third alias (second in Latin) for [crh]. Verdy p (talk) 11:37, 14 May 2023 (UTC)Reply[reply]
Favicon no longer displayed on this wiki.
This wiki uses the following code (in the page header) to specify a "favicon", the icon that should be displayed on tabs. These icons should be small 16x16 color bitmaps.
<link rel="icon" href="/favicon.ico">
However, recent version of Chrome/Chromium no longer displays these icons: notably the legacy "'.ico" format is no longer used (probably due to security reasons, as this is a Windows specific format that may embed active code; though webbrowser will discard/ignore this non-image content). This will probably be the case for other Chrome-based browsers (Chromium, Edge, Android). Chrome prefers now using the PNG format (which is safer and does not require proprietary tools to create them), like this:
<link rel="icon" type="image/x-icon" href="/favicon.png"> (you can see on example of use on Gmail's website and Google site)
The interest of the .ico format however is that it can embed several resolutions of the icon in the same file (this makes it easier to use them as well as desktop icons or menus for navigation shortcuts, at the price of a larger downloaded size). Windows suggests the following resolutions: 16x16, 24x24, 32x32, 48x48, and so on up to 128x128, to adapt to various display resolutions (e.g. on Hi-DPI devices or for larger thumbnail views). When a specific resolution is not available, icons will be scaled up or down from the nearest resolution, giving good results that don't look too blury at any practical resolution.
PNG images may be rescaled if their resolution is large enough, but may sometimes look blurry or insufficiently contrasted when scaled down, notably if they embed text (requiring some subpixel changes of the geometry, like with glyphs of hinted fonts). However some good renderers may use some autohinting algorithm to preserve contrast, colors and sharpness when scaling images at low size (this is used for example for rendering textures mapped on 3D surfaces with the mipmap technic implemented in hardware graphics accelerators used on all modern devices). Autohinting is not necessary when icon files are embedding images at multiple sizes on the scale suggested by the Windows documentation, because the filtering convolutions are simpler to implement in software only; with the use of modern graphics hardware, it is generally no longer needed, so icon files in PNG format may just be defined with a single suggested resolution of 64x64, and will look good at all sizes when the geometries are simple with a flat design (this is the case of the favicon for Translatewiki).
Other sites are suggesting this syntax (with another "shortcut" keyword in the rel attribute, so that it also works for creating shortcuts, e.g. on desktop, and a more standard value in type="" specifying the media type, however the effective media type should be the one specified by HTTP(S) headers when effectively downloading the icon, or when the icon is specified by a "data:" URL, encoded in Base64 with its prepended mediatype):
You may combine these lines on the same HTML page (the first that works will be used if other lines are not suitable). Without these favicons, using multiple tabs in a webbrowser complicate the task (adding the "shortcut" keyword is optional but may be fine to create desktop icons. I don't know if other graphic formats are supported (e.g. SVG, GIF or JPEG, but beside GIF they are probably useless for favicons). And maybe the favicons in .ICO format are no longer used if there's no "shortcut" keyword, just "icon", in the rel attribute. another possible cause is the currenty content of the "favicon.ico" file, which fails some internal safety checks made now by Chrome if it includes some unsafe extensions or if its data is not properly aligned and padded.
Can we have such PNG icons hosted? (note that Safari on Apple also uses PNG images for its touch interface) Does this require an update in MediaWiki? Verdy p (talk) 18:56, 16 May 2023 (UTC)Reply[reply]
Really a nightmare. I don't understand why the W3C did not made a unified standard, allowing various formats, but recommanding one that can either support mipmaps (for bitmap icons), or SVG, or a syntax working like normal images in HTML (where you can specifiy a list of URIs for various scales or pixel resolutions, something that MediaWiki already supports). Chrome is apparently unstable across its versions, sometimes ICO files disappear and can't be rendered. Safari on MacOS or iOS also don't play the same game! (Note that my question above is not strictly about translatewiki.net, I've seen similar issues as well with Wikipedia, or any Mediawiki site in general, and creating shortcuts by dragging a link from a browser by to a desktop folder does not always work as well, depending on sites and the various tricky/unstable syntax and formats they use; so this is also a question that may be posted to MediaWiki developers and see how they intend to support this nightmare). Verdy p (talk) 19:42, 27 May 2023 (UTC)Reply[reply]
FuzzyBot doesn't seem to help CeJS update anymore?
Not sure what's going wrong, FuzzyBot seems to have stopped updating CeJS since last week after this commit? I wonder if someone can help to solve the problem? Kanashimi (talk) 21:16, 23 May 2023 (UTC)Reply[reply]
Incorrect web font currently used for the Myanmar script
Since recently a new webfont was added on this site, however it breaks displays in many case: the "Tharlon" font replaces extended Latin letters with completely unrelated characters or symbols, most probably because it is not coded with Unicode but uses some strange mapping from legacy charsets. This is visible in all Myanmar translated pages that attempt to display non-Myanmar texts. For example it shows the incorrect glyph for '®' (U+00AE) instead of the expected 'é' (U+00C9).
Please disable that incorrectly encoded webfont (it is even deprecated, because it was designed in 2011 before OpenType fixed new rules in 2016 for the Myanmar script, and it has not been maintained at all, see https://code.google.com/archive/p/tharlon-font/downloads and issues listed on https://code.google.com/archive/p/tharlon-font/issues since 2015, but never corrected: That old Google project has been archived because it was not maintained). Tharlon was based on the preliminary "mymr" specification for OpenType, and OpenType has deprecated and strongly discouraged its use. New OpenType fonts use the "mym2" specification.
For the Myanmar script, please use "Noto Sans Myanmar" instead. "Tharlon" is even worse than "Myanmar Text" provided in Windows (at least version 1.10 since Windows 8, now it is at version 1.20 with Windows 11; windows 7 was initially providing version 1.00 which was also based on the old/deprecated "mymr" OpenType specification, but I don't know if Microsoft has provided updates to that font for Windows 7 users, given that it no longer supports that OS since many years) and cannot be a "safe replacement" to the "Myanmar Text" font. Verdy p (talk) 10:54, 27 May 2023 (UTC)Reply[reply]
