This is an archive page for the Support page. Do not post new threads here, they will likely not be read. If you wish to continue an archived discussion, start a new thread on the Support page and include a link to the archived discussion.
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)
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)
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)
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)
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)
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)
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)
So please report your 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)
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.
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
Due to the various error problems I mentioned above, I requested that Mon Wikimedia projects like the Chinese and Japanese language Wikimedia projects ones install font auto, but I am not the only one facing this error problem. If you don't believe my statement, you can vote on the Facebook Mon Wikipedia Group, this kind of error problem is a big annoyance for someone like me who works on Wikimedia every day, but you can check out how hard I worked for Wikimedia in no time. I'm a writer who travels daily, so it's not convenient for me to work on Wikimedia full time on my computer, so I still want to continue working on Wikimedia on my phone while I'm traveling, but I do a lot of work on Mon Wiktionary by myself, so I'm worried about Mon Wiktionary because I'm often getting harassed by unknown IP accounts, thanks. 𝓓𝓻.𝓘𝓷𝓽𝓸𝓫𝓮𝓼𝓪|𝒯𝒶𝓁𝓀09:18, 30 May 2023 (UTC)
I did not say that I did not believe you But that's not something can be worked here in translatewiki.net to solve these problems. Translatewiki.net is not developping any font, OS, renderer or webbrowser, we an just try finding solutions that follow the best practices known, available and actively supported by their developers. Verdy p (talk) 18:03, 30 May 2023 (UTC)
But as far as I know, when access Chinese, Russian, Japanese, Wikimedia on your phone, no matter what font use on your phone, still see Chinese Wikimedia designated font, but I like that system very much, so I think that if use that system, I can solve this kind of error problem. 𝓓𝓻.𝓘𝓷𝓽𝓸𝓫𝓮𝓼𝓪|𝒯𝒶𝓁𝓀22:47, 30 May 2023 (UTC)
Chinese, Russian, Japanese are not using the Myanmar script, they use their own set of fonts for scripts that are better maintained since longer time, and that don't have any complex shaping. The Myanmar script has many problems and the early specificaiton were not tested across all languages using that script. Still, there are some issues in Chinese with newly encoded Han characters with fonts not containing them and displaying "tofus" (this happens more rarely however, as most of these new characters are extremely rare, many of them historic or for proper names, or specific Chinese dialects (in the next release of Unicode 15.1 there will be about 600 new characters added, some of them are for neologisms, but with forms with a well know radical, and wellknown phonetic traits, but sometimes some additional or modified distinctive strokes). For modern usage however these scripts are well supported across OSes, browsers, and fonts. The Myanmar script is still in development to support more languages (and yes thre may still remain issues with Mon and Karenic languages that exhibit some specific shapings for some combinations of diacritics). Verdy p (talk) 01:33, 31 May 2023 (UTC)
It means that I like that method, but means to use the font used by Chinese Wikimedia it is not. I have used various fonts for the Mon language, but those fonts are not the best and have weaknesses. now when I write Mon text, I have to be very careful not to make mistakes, but I myself have a weak knowledge of technology, so I don't understand the font system, but my main wish is to write Mon text on Mon Wikimedia projects on the wiki so that there is no font error problem. 𝓓𝓻.𝓘𝓷𝓽𝓸𝓫𝓮𝓼𝓪|𝒯𝒶𝓁𝓀19:48, 31 May 2023 (UTC)
It suggest you to jsut input text that is not rendering any dotted cicle with diacritics or no small "+" sign for the correct placement of subscripted consonnants. The exact glyph positioning or adjustment may look wrong for Mon (e.g. a diacritic below for a subscripted consonnant that should loose its tail in Mon when it's followed by another diacritic above, or the rotation of subscripted consonants which may look wrong in Mon but would still be correct in Burmese, or unadjusted positioning of some diacritics above that may partly overlap another tall diacritic on the right): this is still readable and usually not confusable even if it's not optimal. More advanced versions of fonts will come later, but we can't develop them here, this is the wrong project for that because the necessary development tools and test suites are not available and supproted here in translatewiki.net, like they are in Google Font opensourced projects or those used in proprietary font foundries. Once again don't speak here about Chinese or Russian, their scripts are well supported since much longer and have been much more widely tested and are widely available (even if all fonts, including those for Latin/Greek/Cyrillic may have small bugs or quirks like not optimal placements or too confusable glyphs, they are generally OK for many language and all important languages. The situation if different for Mon and Karenic languages only due to lack of knowledge or interest, when the primary gaols of font designers was to correctly support Burmese first.) Once again if you wantto accelerate the resolution of these quirks, participage to their opensource development by posting your findings (not here! it's useless), notably snapshots of unexpected results compared to other expected results that you can still create using other fonts or any graphic editor, even if you don't understand the complex technology behind font design and development. Verdy p (talk) 12:55, 2 June 2023 (UTC)
May I use AutoWikiBrowser to help me batch translate?
I never tried using AWB on translatewiki. It's not supposed to be necessary because the interface here is already supposed to be optimized for translation. What kind of "batch translation" do you want to do? Amir E. Aharoni (talk) 07:08, 4 June 2023 (UTC)
I don't know if this is suitable place to ask this, but by the way, how do I change my username in this wiki? It's like changing my username in Wikipedia. I don't like my current username to be used anymore, so I needing to change it. Nghiemtrongdai VN (talk) 14:08, 7 June 2023 (UTC)
Replace the English HTML code with the Greek one that we will provide you
Hello everyone,
We are translating parts of translate.wiki from English to Greek. We have completed 99% of the translation and there are still 8 untranslated entries remaining. These entries contain HTML code, and we have been "restricted" from inserting code due to code sensitivity. Editing is now limited to administrators, so we are attaching the Greek translation and kindly ask you to replace it. Thank you in advance!
(Sorry, I didn't pay enough attention before – the same question applies to the "Page text" part in number iii, and the "additional text" part in number v. Jon Harald Søby (talk) 12:01, 16 June 2023 (UTC))
This field contained one word - "default". I deleted it, but nothing changed (and the word "default" automatically reappeared in this field). The list of languages has not changed.
After that, I manually entered the language codes and then everything worked out. Thanks for the help. Rut (talk) 11:08, 20 June 2023 (UTC)
Language name in Language search-box
Hello!
When I enter the name of "Rutulian Language" in English, it cannot be found (it can only be found if I enter the original name (мыхаӀбишды) in the native language). How to make it so that in the language search-box, the language is found by different names? For example, English can be found if you enter "English", but you can also find it if you enter in Russian "Английский". Rut (talk) 11:42, 20 June 2023 (UTC)
If you write just "rutul", it does work. It's more likely that people will type that and not the whole English name "Rutulian language". That's how it works for all languages. Amir E. Aharoni (talk) 12:32, 20 June 2023 (UTC)
Messages that can only be translated by administrators
There are some messages that can be translated only by administrators for security reasons. Most notably, this happens in the WikiEditor extension, and also in a few other places.
Getting administrators to do it all the time, doesn't scale very well, but giving the administrator right to a lot of people is also not great.
Perhaps as a workaround, we can change it from protected to administrators only? Here's one idea:
Separate all those messages to different groups under their current group. For example, split the WikiEditor group to "Wiki Editor - regular messages" and "Wiki Editor - secure messages", and put them in the aggregate group "Wiki Editor".
Put all those message groups in the aggregate group "MediaWiki - Secure messages", so that translators would be able to do all of them quickly in one go.
Create a new user group, something like "secure messages translator".
Change the protection settings of these messages to allow translation by members of that group.
Grant these permissions to trusted users for a limited time, e.g. a week, so that they can finish translating all of them using that aggregate group.
@Amire80: Is there something we can do with the extensions and/or core to make these messages not require any "security clearance"? Some of them must contain HTML, but that HTML wouldn't change from language to language, would it? So we could just replace that HTML with $parameters in en.json, and then insert the HTML in the PHP code/JavaScript code.
You can try, and if you succeed, it will be ideal. I always say about such things that I know localization quite well, but I don't know almost anything about security. Amir E. Aharoni (talk) 12:34, 20 June 2023 (UTC)
As always, I am going to be the grumpy person to say no, because I really want the root cause to be fixed, and what's a better way to make the current way as painful as it can be? Well, except that the pain is inflicted to wrong people.
I don't want to retract JHS's enthusiasm of fixing these for real, but I think the simplest workaround would be to use the "prefix" feature for these messages. Nike (talk) 13:48, 21 June 2023 (UTC)
@أيوب: Hi! Wikimedia wikis are updated from the master version of the source about once a week (with some exceptions, mainly due to holidays in the US, such as last week's Juneteenth federal holiday).
Hello, we are several users to translate the CLDR for the Kurdish language. All have been translated but for some translations the number of voters is not enough (like here). I wonder if someone from wikimedia can approve these to get them validated? Thanks! ping @Bikarhêner and Balyozxane:Ghybu (talk) 11:03, 30 June 2023 (UTC)
This is an archive page for the Support page. Do not post new threads here, they will likely not be read. If you wish to continue an archived discussion, start a new thread on the Support page and include a link to the archived discussion.
Done, but there are some problems with the move of the translatable subpages of your user page. I'm trying to figure out how to fix that. Jon Harald Søby (talk) 12:36, 13 June 2023 (UTC)