View source for Thread:Support/Problematic edits of Verdy p (again)/reply

Jump to navigation Jump to search
NoteProblems? Questions? Suggestions? Write your message below. — See also the FAQ or try to catch us in IRC.

Your request has been forgotten? Feel free to post a reply to bump the thread to the top. Very old threads have been archived.
(The thread summarization feature is broken, see: Phab:T245109)


Thread titleRepliesLast modified
[TWN] [Waymarked Trails] non-working link for their help pages in Group descriptions107:28, 6 May 2021
[ms-arab] Activate new language: Malay (Arabic script) - 'بهاس ملايو'307:58, 5 May 2021
Problems for Ajapaik in pms504:54, 4 May 2021
Moving messages?111:10, 2 May 2021
Start Hanja Script language for Korean1707:05, 29 April 2021
Typo in MediaWiki:Wiki-seo-param-google_bot?115:55, 24 April 2021
Problematic edits of Verdy_p (again)710:25, 23 April 2021
How I can rename my account?810:11, 23 April 2021
Encyclopedia of Life: no export since 29 August 2019308:26, 21 April 2021
Missing space after punctuation in Phabricator:phabricator_ext-core-*/en105:09, 21 April 2021
Phabricator:phabricator-config-f1fa5528f9aeb0d9/en104:48, 21 April 2021
Account problem104:27, 21 April 2021
MediaWiki:Contenttransfer-too-many-pages-warning/en and various typos in today's Mediawiki package for content transfers and page merges109:42, 15 April 2021
MediaWiki:Bs-insertmagic-nocontentconvert/en: is "phase" a typo for "phrase" ?106:45, 15 April 2021
Problem saving links with hardcoded diacritics via the translation interface417:22, 14 April 2021
North-Central Dargwa (or Dargin) language [dar]123:17, 12 April 2021
Not allowed to translate a message114:47, 9 April 2021
TheWikipediaLibrary - json-based i18n files in addition to existing gettext1014:48, 7 April 2021
Activate new language-code: Aruban Papiamento [pap-AW]520:50, 3 April 2021
Please add the Kom language [bkm]114:25, 1 April 2021
First page
First page
Last page
Last page

[TWN] [Waymarked Trails] non-working link for their help pages in Group descriptions

The current English source (Translations:Group descriptions/waymarked-trails-help/en) indicates a non-working link ( to its supposed help pages.

However such help pages do not exist as they are actually hosted on several distinct subdomains (and are using HTTPS, not HTTP).

This message is part of the translatable page Group descriptions, listing and summarizing all translation projects currently supported in (this page is not managed by Waymarked Trails authors themselves).

The actual help pages are on:

I did not find any general index page on (whose HTTP site redirects instantly to HTTPS). In all cases, the current link is misleading and just displays a 404 (Page not found) and does not go display any info or link, and does not redirect anywhere else.

If you don't want to include the previous (corrected) list of working links, may be you can just link the base website (https// where you can select the subtopic: then below the map, there's a [i] button at the bottom linking to appropriate info and help pages (this button goes to one of the links listed above, depending on the selected subdomain). But may be there's a specific help page for all Translating:Waymarked Trails.

Do we even need this line containign such link(s) in the Group descriptions page, shouldn't it be on Translating:Waymarked Trails ?

Verdy p (talk)15:55, 21 April 2021

Hi Verdy p,

Thanks for the details. I've updated the group description.


Abijeet Patro (talk)07:28, 6 May 2021

[ms-arab] Activate new language: Malay (Arabic script) - 'بهاس ملايو'

Hello. Malay is written in two scripts and one of it is Jawi script which is based on the Arabic script. It is still taught in schools and it is one of the co-official script in Brunei.

Tofeiku (talk)05:40, 1 January 2021

I have already done translating all the MediaWiki (most important messages) for ms-arab. Can this code be activated now? It is said ms-arab is now disabled. The code "ms-arab" is now available in Wikidata lexemes.

Tofeiku (talk)17:54, 27 February 2021

I've removed the messages saying it was disabled, given that now it is working within the translate interface of this wiki, and the fact it also has updated completion statistics running.

The message posted is informative only, except in the portal of a language showing variants that may be disabled as long as the link going to translate UI on this wiki does not load it in the correct language but loads translations for a fallback language: this is problematic when users follow these links and think they are actually translating for the correct language selected

(this is in my opinion of itself which should NOT redirect to another fallback language, using the language preferences of the currrent user! We've seen in the past that not disabling them caused troubles where peopel started to replace correct translation for a given language by translations for an unrelated language still not supported but that they selected either with ULS, or by modifying the URL in the address bar; such redirect should either not use any fallback return an error, or if they perform the redirect, there should be a strong banner notice at top of page that the content of the page does not match the user-selected language...)

Note: the removal of these messages had NO effect of the fact that the language [ms-arab] was enabled or not: I cannot change that, only admins can enable it (that's why there's this support page to contact them and make them aware of your request). I'm not an admin, I can just help admins maintain the site to avoid common errors and inform users.

So if you see other messages syaing that the target message you want to translate to is still disabled, test the language code in the UI, by trying to change the language code in parameters of URL displayed in your browser, and then press enter and check that the page will render effectively the language selected and not another fallback language before replacing any displaed translation.

The '"disabled=*" options in parameters of the Portal page are there as a protection. Of course when the user's fallback language is English, typing an unsupported code will fallback to the Translate UI for English, but English is protected (you can't translate from English to English, only from English to a supported English variant), so there does not seem to be any risk on a first approach

But not all users have English as their primary language (selected in their preferences of with the Universal Language selector at top of pages. In that case, typing any unsupported language may fallback to some other frequent fallbacks like French, Chinese, German, Russian or Standard Chinese: if the user types an unsupported code, and don't notice that the server has made a fallback to ressources already edited and validated to French, German, Chinese, Russian, then they'll start "corrupting" these languages with translations intended for the other language they selected, and all these edits will need to be reverted and reviewed again.

Verdy p (talk)21:22, 27 February 2021

I'm going to enable it as a full-fledged translation target language in translatewiki. This will make it usable as an interface language in Wikidata, and also as a language for values in Wikidata, but if you want to use it for other content in Wikimedia projects, you'll have to discuss it separately.

Amir E. Aharoni (talk)07:58, 5 May 2021

Problems for Ajapaik in pms

Hi! There are still 10 messages of Ajapaik that need to be translated in pms. However, it seems impossible to do that. What is the problem?

Borichèt (talk)06:41, 16 April 2021
Abijeet Patro (talk)04:56, 21 April 2021

The fact is that when I try to translate the ten missing strings, I get the messge: Translation to this language is disabled.

Borichèt (talk)06:43, 21 April 2021

You have been able to save one of those translations, thanks a lot! But I still have the same issue with the others... I can't understand why.

Borichèt (talk)06:41, 22 April 2021

Translations to pms (and other languages) has been disabled for the group Ajapaik Android App – Play store descriptions. This as per: All the untranslated messages are from that group.

I can translate messages in that group because I'm an administrator but even so my translations are not exported out to the project repository.


Abijeet Patro (talk)12:05, 3 May 2021

Many thanks for the information.

Borichèt (talk)04:54, 4 May 2021

Moving messages?

I translated a bunch of messages to Malayalam but didn't realise that I was on "Translate to British English" mode. So the messages have been published as en-gb messages. See Special:Contributions/SD0001. I see no option to move pages in this wiki. So is there an easy way to clean up the mess?

SD0001 (talk)10:14, 2 May 2021

Hi SD0001, I moved the translations from /en-gb to /ml for you.

Raymond11:10, 2 May 2021

Start Hanja Script language for Korean

Hello. recently, Some Korean users started a new Hanja wiki and they are wanting to make Hanja Interface for their wiki. Also, in Wikimedia projects, New request for the Hanja Wikipedia is have not rejected and if LC accepts the request, It would be need of its own interfaces. according to the ISO 15924, the code kore is assigned to the Korean with hanja, so we can use the code of kore or ko-kore for it. I also have an interest in it, and more Koreans would contribute to it.

Ellif (talk)09:23, 13 October 2020

The ISO 15924 code [Kore] does NOT mean it uses only (or preferably) Hanja. This code indicates this is written in a mix of ALL scripts used in Korean, so it accepts Hangul, and Han/Hanja.

Korean by defaut uses [Kore], i.e. [ko] is a perfect synonym of [ko-Kore], just like [ja] is a perfect synonym of [ja-Jpan], ie. It uses all Japanese Kana syllabaries [Hira]+[Kana] and Kanji [Hani] (you can use [Hrkt] to indicate that all Kanjji are transcripted to kanas (Hiragana and Katakana).

Using [ko-Kore] is then NON-SENSE. Look at BCP47 and notably the IANA database which states that [ko] uses [Kore] as its default implied script. [ko-Kore] should then not be used in BCP47. It exists only for legacy applications that want to include a script subtag for all languages and do not want to perform a lookup of the language code to map it to its default script.

If you wanted to make a preference for Hanja, you should use [Hani], i.e. [ko-Hani], so that all words that have an Hanja transcription should be written with it and not in Hangul [Hang]. And as well you could do the same thing in Japanese with [ja-Hani] to restrict the use of kanas.

Verdy p (talk)10:52, 13 October 2020
Edited by author.
Last edit: 14:17, 13 October 2020

For once, I agree with Verdy p, the correct code for the Hanja script (and only the Hanja script) is ko-Hani.

EDIT: However, I see on Hanja wikis and websites that text is written in a mix of Hangul and Hanja scripts (also the case with the word given as an example on meta), maybe we should move translations in Hangul only to ko-Hang and translations for Hanja to ko?

Thibaut (talk)13:14, 13 October 2020

And it's strange that this wiki, actually uses all Korean scripts (including Hangul) everywhere in the content (I'm not speaking about the interface of the wiki itself)... So this wiki actually uses [ko-Kore] even if they want to remove Hangul (as much as possible) in favor of Hanja (I'm not really sure this is possible in modern use, unless you accept to borrow Chinese sinograms, most probably in their simplified in modern terminologies, but possibly traditional for coherence with Hanja; not sure that users will be able to read these borrowed Han sinograms, when they also are composed with phonologic traits which are appropriate to Mandarin, but most probably not for Korean).

Do you want to be inventive and create adhoc Hanjas, composed by a traditional Hanja radical and an Hangul part to replace the phonetic parts of Han sinograms? You won't be able to compose them in Unicode, so you'll fallback to use Hangul only (or maybe Latin or Cyrillic): Hangul is more complete than the basic alphabet and has many adhoc Jamos (plus a few diacritics) to compose more complex and more precise clusters that better respect the phonetic than modern Hangul which has simplified the phonology by reducing the number of jamos (the other ones being kept for historic use and encoded in Unicode even if they are not precomposable in a full syllable using a single Unicode character).

Note that Unicode contains a few clusters that don't respect the pure (L*V*T*) Hangul composition of jamos, just like Japanese has some precomposed clusters of kanas (possibly mixed with Latin, e.g. for international measurement units), and some adhoc Hanjas specific to Korean (not used in Chinese languages, Japanese, or historic Vietnamian).

Verdy p (talk)14:13, 13 October 2020

I don't think we should move Korean translation made in Hangul-only to [ko-Hang]. This is their normal modern form for Korean [ko-Kore].

The use of [ko-Hang] would be ONLY to propose a transliteration to Hangul of Hanjas still normally used in modern Korean.

The interest for [ko-Hang]would be to allow a site to display Hangul easily without needing a large Han font, and it may be useful for small devices that have limited fonts

Note also that [ko-Jamo] is not needed given that encoded Hangul clusters are canonically decomposable to Jamos (so rendering on low-resolution terminals that can only display aligned (non-composed) jamos is possible algorithmically. As well this easily allows generating a romanisation fully algoithmically. Only Hanjas cause problems as they require a lookup in a possibly large dictionnary (which is not fully defined and extended regularly in successibve Unicode versions; in some cases, Hanjas do not have a well defined phonology and may turn to several distinct Hangul clusters, depending on the reader, and that's probably why some Hanjas have been kept to avoid confusions, notably for proper names).

Verdy p (talk)14:29, 13 October 2020

Sorry, that's not how things work for Korean speakers. Nobody uses Hanja in their daily life in 2020. Proposal to mix Korean and Hanja in domain name got quite a lot of resist in 2018 when it was submitted to ICANN.

Hanja usage is basically now in the form of disambiguation and a hanja mania's area, and most words are expressed in Hangul. No hanja required for any expressions in Korean. We indeed borrow words in Hanja, but we display them in Korean. Nope. If they want to use Hanja in interface, they should be segregated in their own area, not in the way where you steal the Hangul's area.

revi11:20, 15 October 2020

Ok then, ko-Hani it is.

Thibaut (talk)14:50, 15 October 2020

You have to notice that All Korean translations in translatewiki are in Ko-hang status, not ko-kore status. After the FRAMEWORK ACT ON KOREAN LANGUAGE enacted in 2005, the language of official documents in all governments are obliged to write in Hangul only(Article 14). Also, all newspapers became Hanja only. Before 2000. So, You have thought that many Koreans like to Hanja during their Korean writings, but it goes to extinct.

If this decision goes into Korean Wikimedia community, The community will not approve your idea. Ho-hang should be the original status of Korean(ko), and gughamnun should behave the ko-kore status.

Ellif (talk)10:54, 15 October 2020

"So, You have thought that many Koreans like to Hanja during their Korean writings, but it goes to extinct."

No I didn’t think that, I know Hanja is rarely used nowadays, it was just a question, since ko and ko-Kore mean according to the IETF, a mix of Hangul + Hanja, that’s all.

Thibaut (talk)15:00, 15 October 2020

Also the Korean act applies only to official acts of the Korean governement bodies or agencies. This does not apply to all independant projects, notably wikis that are not required to use only it, and the web in general (so "ko"="ko-Kore" in IETF remains effectively, only the Korean government sticks now on using only "ko-Hang" but only for its official documents, not the informative documents and all its communication to the national or international public, and it still actively supports Hanjas in its cultural works and still works actively within the standardization bodies for Unicode/ISO 10646, notably in the IRG for the "ideographic" scripts (which should have been better named "sinographic" gen that sinograms are not purely ideographic, and there are other unrelated ideographic scripts that the IRG does NOT work on, such as "SignWriting" or various hieroglypic scripts developed far outside Eastern Asia).

Korean people in Korean-written wikis have a strong use of Hanjas (the Korean Wikipedia has many of them which are not even transliterated to the modern Hangul with an additional precision). Nothing prohibits in fact the default Korean UI [ko] to use Hanjas, even if it's rare there (but it's not forbidden at all, just a matter of community preferences, not decided by the South Korean government alone).

If there's a conflict between the South Korean governement goals and the comminuty goals, I would then prefer the addition of the [ko-Hang] locale in this wiki, so that overrides are possible for the few [ko] resources that may exhibit Hanjas (with fallback to [ko] = [ko-Kore]).

And I'm also not opposed to the addition of [ko-Hani] for the few users that still want to sponsor Hanjas as their prefered script (also with fallback to [ko] = [ko-Kore]).

In other words, we don't need [ko-Kore] here, and [ko] can remain as it is. Note that language tagging is not a requirement to use only the indicated script, it just sets a preference order (so even in [ko]=[ko-Kore] it is possible to embed Latin, not just Hangul or Hanjas, and this use is in fact not rare at all, notably for famous trademarks, including "Samsung", or international brands and compny names like "Google", "Apple", "Microsoft", Facebook", "Amazon", "IBM", "Honda", "Mercedes-Benz", and so on, or international bodies to which the Korean government bodies participate like "ITU", "ISO", or "Unicode").

In summary:

  • Adding [ko-Kore] : no, use [ko] instead (no need for this duplicate according to BCP47 rules and the IANA database), which is Sufficient for Wikipedia and Wiktionnary editions in Korean.
  • Forbidding use on Hanjas in [ko]: no
  • Adding [ko-Hang] : may be yes if there's a need for the official bodies of the South Korean governement. We have to wait for such demand for a wiki maintained by this governement.
  • Adding [ko-Hani] : many be yes for cultural reasons and if there's an intererested community to support it and prefer Hanjas in their wikis rather than the modern Hangul.
  • Adding [ko-Brai] : may be needed for blind Korean users using the Braille script, if the automatic conversion from Hangul (or worse with Hanja) is not easy to implement (and cannot work like in Chinese with their extensive dictionnaries containing normative romanizations sponsored the PRC governement, but based on Stantard Mandarin spoken language and not at all for the Standard Korean spoken language).
  • We have already accepted [ko-KP] for a different standard decided and used by the North Korean official communication, but in fact it's not actively supported because of lack of contributors and severe restrictions for local native users on the Internet. North Korean people that now reside in South Korea jsut have adopted the community rules used in South Korea and elsewhere worldwide.
Verdy p (talk)18:41, 16 October 2020

Well - I don't much care about anything about Hanja as long as no Hanja appears on [ko]. Korean-speaking wiki community's expectation is that Korean is for generally-Hangul-written and there is no need for Hanja injection - as established in w:ko:위키백과:사랑방 (일반)/2015년 제14주#한국어 위키에서의 한자 사용에 관한 의견 요청 (and w:ko:위키백과:사랑방/2012년 제40주#한자->한글 자동변환기능의 도입에 관하여 which also features wider community rejection of hanja use).

revi01:14, 19 October 2020

I could not accept your opinions.

  • [Ko-hang] is the same as [Ko] therefore Ko should not be moved from current status. If you are not agreed, I ask to see the Rodong Sinmun. I want to ask one more for you: Are there any people for teaching Ko-kore for Learning of Korean? As you can easily find out in Duolingo, No. Even North Korean and Koreans in China, Russia, and Kazakhstan do not use Ko-kore as for the writing nowadays. Therefore,
  • Yes [Ko-kore] for Korean with Hanja.
  • Nay [Ko-hani] for Korean with Hanja, because Modern Korean could not be expressed with Han characters only (except if you want to save out the Gugeyol, which is not accepted in Language Committee). If you are thinking about the writing Chinese in Korean way, You rather have to contribute to the Classical Chinese Wikipedia.
Ellif (talk)08:59, 23 October 2020

Typo in MediaWiki:Wiki-seo-param-google_bot?

MediaWiki:Wiki-seo-param-google_bot/en mentions "modue". Isn't it supposed to be "mode" (or "module" maybe)?

Rail (talk | translations)17:07, 23 April 2021

Problematic edits of Verdy_p (again)


While Verdy_p did a lot of good edit, he sometimes goes totally off rail and in this case it's seems impossible to talk with him. He has been blocked for this for a month earlier this year and now he is edit warring again...

This time, this is even more ridiculous than usual, he is basically at an OS what is an OS and why the terms everybody everywhere on Mediawiki use for decade is wrong: Thread:User_talk:Verdy_p/MediaWiki:Flow-history-action-suppress-post/fr. @Jules78120: is one of the few people (5-ish) in the world would will see these messages and he use them frequently but Verdy_p still persist to think is right.

This is very disruptive. On consequence is that we have to put local messages on Wikimedia Project (and other wikis) because of these unconsensual changes. This make Translatewiki worthless and look bad to wiki communities.

I don't know what could be the solution. Verdy_p raised a good point when he said (in a earlier dicussion) that the context is not always clear and the system should be improved. But even then, this explain the first error he made not why he continues to edit war after he was warned that this is an error. I'll let admin decides (meanwhile, I'm still staying far away from Translatewiki and cleaning local messages to have correct translations).


VIGNERON (talk)09:25, 22 April 2021

You do not have permission to edit this page, for the following reason:

The action you have requested is limited to users in the group: Users.

You can view and copy the source of this page.

Return to Thread:Support/Problematic edits of Verdy p (again)/reply.

The history of a message like is textbook editwar.

« I've proposed several things », changing a message without talking to anyone before and then reverting everyone who disagree with you is not "proposing".

The first replacement of « masquer » by « cacher » on  MediaWiki:Flow-moderation-confirm-hide-post/fr was done by @Arkanosis: in 2014, which is not 3 years ago and that can count as some sort of review.

If you distord such plain and obivous fact, how can we even start to have a real discussion?

@Nemo bis and Nike: about the « prior blocking » being « unfair ». You had 7 blocks here, 7 blocks on fr.wp, 1 block on en.wp (in fine, almost always for the same reason: edit waring) and you still don't understand... It has also been said countless time to stop dumping long blob of text, this is not helpful and clearly you don't listen to other editors.

Ping @admins: at the very least, what do you think of instoring a 0RR to stop the editwar?

VIGNERON (talk)11:34, 22 April 2021

I have not seen any change in 2014... Flow was not even existing at that time (at least not in fr.wikipedia as it was possibly just in alpha and not deployable except for custom tests). The "evidence" that was given to me (in the discussion) was effectively pointing to 2017... Still Mediawiki exists since much longer time, and the term chosen for Mediawiki for the non-adminsitrative term "hide" dates since longer, as well as the choice decided to use "masquer".

As well the docuumentation in "/qqq" for that message was pointing to a common terminology supposed to unify the term hide with the MediaWiki usage (which was broken only in French and fiors the first time in 2017 from the evidence given, and not discussed anywhere by its submitter, just because he was confused by the terms used in English for the two adminsitrative options "delete" and "suppressed")

Once again when I just reviewed that term in Flow (which was never reviewed before), this was clearly not an edit war, but the instant reaction from another user was excessive, and largely abusing the rules of politeness. I can understand the irritation, but this should have lead to discussing the problem, instead of once again accusing me for things done that respected the common rules and guidelines.

I've not lied, I've not changed my mind though, but this does not mean that my polite talk is means that it's "impossible" to talk with me (at first, that user that complins now, had not initiated any talk, he just expressed his irritation in offensive terms, and once he started talking and I replied calmly, he complained again. Who is refusing to talk? If it's "impossible" to talk it's not my fault, and in fast it has always been possible.

I've iven a rationale, may be you don't accept it, but it can be evaluated, and there's efectively a problem. And no need to use bird's names. I contribute a lot and let a lot of existing translations pass (including many changes). Very few terms will cause a discussion because there's a disagreement or misunderstanding, but no need to use bad tone. I've made my best, that user also tried his best at that time, without seeing the problem. I'm only more exposed to such conflict because I contribute a lot, and I take care of remembering the past as much as possible (it may happen that I can't remember everything in the past, notably if there were old discussions made years ago, without leaving any comment or documentation).

The document I used was the "/qqq" page, but the complaining user commented with "which doc?" meaning that he had not even read it, even if it was very visible in the normal UI of TWN. That "/qqq" page was the first evident source and the main cause of this unification of common terminology already used and decided since long in MediaWiki core messages.

"I've proposed several things": yes, see the talk thread that was initiated by the complainer and linked in his edit summary. He initiated the talk, I replied promptly and calmly (without using the unpolite tone he used and repeated later), so where is it "impossible" to talk with me?

Verdy p (talk)12:24, 22 April 2021

Please keep you answer short and it also wouldn't hurt to know what you are talking about (a simple look at the history shows the message exist since 2013 and the term here is used by Flow - now known as Structured Discussions - but not from Flow, it is older and used in other older messages).

Your first edit was indeed not an edit war and could be seen as a simple honest good-faith mistake, the following reverts are clearly an unconstructive edit war. Other people shouldn't have to start the discusion, you are responsible for your edits ; when reverted, the usual and correct wiki way is to start a discussion, not to revert (as you have been told multiple times already).

For the MediaWiki:Flow-moderation-confirm-hide-post/qqq, did you really read it yourself? by putting the same translation "Masquer" on two different message use in the same context,  MediaWiki:Flow-moderation-confirm-hide-post/fr and  MediaWiki:Flow-moderation-confirm-suppress-post/fr, you obviously less the interface less clear.

VIGNERON (talk)13:14, 22 April 2021

Bien sûr que j'ai lu la doc "/qqq" et j'ai justement veillé à éviter toute confusion, il n'y avait PAS (et il n'y a jamais eu) la même traduction "masquer" dans les deux messages (quelque soit le contexte d'utilisation).

Et bien sûr que c'était PLUS CLAIR :

  • "hide"="masquer" pour l'action d'interface de navigation donnée à tout le monde (sans privilège et sans conséquence pour les autres visiteurs ou utilisateur, et uniformément conforme à l'interface de MediaWiki)
  • "delete"="supprimer" (uniformément conforme à l'interface de Mediawiki, même si cette option dans Flow n'est disponible qu'aux "sysops")
  • "suppress" (problématique en anglais aussi, disponible aux seuls "oversighters", une poignée): c'est là le désaccord car les premiers traducteurs y ont mis "masquer", qui ajoutait de la confusion non plus avec la deuxième option quasi-synonyme pour sysops comme en anglais, mais a perturbé les millions d'utilisateurs de Mediawiki, car la première option a été unilatéralement remplacée avec "cacher", quasi-synonyme sans ajouter aucune clarté réelle, et sans dire non plus dans l'option 3 que c'était non pas l'option 1 commune de navigation personnelle sans privilège mais bien une action de modération administrative.

La doc "/qqq" notamment inclue une liste de termes "identical" (ou supposés comme tels et voulus ainsi par les auteurs de Flow): il suffit de la dérouler (justement avec un lien "afficher/masquer" basculable !) pour voir qu'en français ce n'était pas pour Flow le terme attendu et utilisé depuis longtemps (et dans cette liste pour l'interface de Mediawiki il y a a eu déjà diverses autres unifications de "cacher" vers "masquer": Flow ne devrait pas faire exception et c'est à lui de s'adapter dans ses autres options administratives, en ajoutant une précision claire)

On peut ne pas être d'accord avec ce que je désigne comme "modération" pourtant c'en est une, le terme seuil d'indiquant pas la raison de la modération, mais le fait de rendre invisible à tout le monde (et pas juste soi-même) de façon contraignante (selon une politique donnée, qui peut être de protéger la vie privée mais peut être toute autre raison justifiée par une politique en vigueur ou une obligation légale que le site doit respecter ou qui lui est imposée par une autre autorité plus forte).

Verdy p (talk)13:30, 22 April 2021

« il n'y avait PAS (et il n'y a jamais eu) la même traduction "masquer" dans les deux messages (quelque soit le contexte d'utilisation) » : c'est faux.

C'est précisément parce que dans l'interface des historiques Flow il y avait deux liens « masquer » que je suis venu corriger ici. Et c'est bien vous qui avez introduit cette erreur. MediaWiki:Flow-history-action-suppress-post/fr indiquait (à raison) « masquer » et MediaWiki:Flow-history-action-hide-post/fr indiquait aussi « masquer » depuis votre revert de novembre 2020. Donc soit vous êtes totalement de mauvaise foi, soit vous ne savez pas consulter des historiques.

Quant au reste de votre argumentaire, ça fait dix fois que je vous explique que « masquer » est un terme systématiquement utilisé pour décrire des actions admins ou OS (masquage léger/masquage lourd, cf. [1] ou [2]), donc ne doit évidemment pas être utilisé pour l'action hide qui est une action accessible à tout le monde. C'est pour cette raison qu'Arkanosis ([3], [4], [5], etc.) ou Kvardek du ([6]) avaient corrigé.

Si l'erreur initiale est compréhensible, il est tout de même incroyable que vous me révoquiez puis que vous persistiez dans l'erreur.

Jules* (talk)10:25, 23 April 2021

Thanks for the warning, blocked again. (I forgot to disable the autoblock, but for this length it doesn't matter much.)

Nemo (talk)13:32, 22 April 2021

How I can rename my account?

Hi. I am the user NikosLikomitros, from Greek Wikipedia. I had the same name with my Translatewiki account until 26 December 2019, when I was renamed, however I still use the old name in Translatewiki. Can someone rename my account to NikosLikomitros, or direct me to the correct page if we file the requests somewhere else?

Nikosgranturismogt (talk)17:54, 4 December 2020

Done Done

Raymond17:38, 5 December 2020

Hi @Raymond:. Could you rename my account in User:Jules* please, to match my Wikimedia accounts ([1])? Thank you very much.

Jules78120 (talk)19:01, 21 December 2020

@Raymond: Thank you for your quick response.

NikosLikomitros (talk)23:19, 23 December 2020

Hi NikosLikomitros, I am not sure if I understand: Do you request another username change? to "User:Jules*" now?

Raymond13:35, 24 December 2020

Hi @Raymond:. No, I'm a different user, I'm not NikosLikomitros. I'm user:Jules78120 I would like to rename my username to user:Jules* as "Jules*" is the username I use on Wikimedia projects. Is that possible, please?

Jules78120 (talk)09:50, 21 April 2021

I think that Nikos (alias "Nikosgranturismo" or "Nikosgranturismogt" or "Jules72120" or "Jules*": not clear!) wants to restore the asterisk at end of his preferred account name. But may be there are issues on with such asterisks, e.g. for tracking changes, or exporting data in various formats (not just for Wikimedia). But he made two different demands, and he should be consistant in his renaming demands (repeated now and alrady in the past!).

MediaWiki accepts the ASCII asterisk in their page names (including user pages, but this is an artefact as the real intend was to allow it in article names), but this is not true for all tools (not even in all tools used by Wikimedia, e.g. in Phabricator, or IRC, or Toollabs, or other CMS like Wordpress). Asterisks are not part of acceptable identifiers in programming language according to CLDR and Unicode character properties; they are rejected in many internet protocols (e.g. in the DNS for the start of authority and in the Whois database for domain owners). The same is true in many filesytems and applies to the question mark (?) which is also problematic. Choosing such user names with ASCII asterisks or question-marks in Wikimedia is definitely not recommended (even if it still works for now, there's a risk that in the future such possiblity will be refused and all these users will have to choose a better name, notably if this causes damaging security issues).

But Nikos should be aware that is not bound to Wikimedia rules and local user accounts are completely independant (and not linked with Wikimedia SUL for example). Renaming an account cannot be honored from an account that the user cannot authenticate with (this could be used for abuses and defamation of unrelated and legimate users, in,cluding in personal attacks to unfairly get someone being administratively blocked). Renaming may be needed in some cases for anonymization, in which case the demanding user will not be able to specify the anonymized account witll be be very generic with a common prefix and a random pattern at end (such as "Anonymous-9823141"). Renaming an account is costly in terms ofresources in the server as it involves global searches and edits in many pages, and there's not even a warranty that this will succeed everywhere (including many existing third-party mirrors).

There's then NO assumption (or requirement) that any account name will match between TWN and Wikimedia (and no reason to unlink/rename one account from one domain or another, if they were validly created and are still in use (this is also still true for many legacy accounts in Wikimedia that were registered separately with the same account name but by different users on different wikis, before SUL was implemented and deployed: such renaming requests are also rejected by Wikimedia if their existing owners are legitimate, and active or have made many of useful contributions, because this is required for respecting their respective copyrights and authorship).

No user should assume they have an universal right to reserve an account name on various domains they may want to subscribe and use separately in the future (or never...). However, as as the desired account name is available (and not used by any link, don't just look at the existence of the user page), users may just take these accounts themselves (with a new registration after logging off) and then alter their previous account using a local redirect (they can legitimately alter their previous user page if they logoff and logon again with their previous account). Such thing must not be abused: users should limit the number of account names they need and the only ultimate right is just the legitimate right to anonymize themself to protect their privacy, or the need to work with a separate identity to match a specific role (e.g. as an approved worker in an organization, or for operating a bot separately from the personal human interactions). This should not be used at all to avoid a blocking, or falsify votes: account creations by the same user should be limited

Verdy p (talk)11:05, 21 April 2021

Hi Jules*, I have done the requested rename now. And excuse my mix-up with User:NikosLikomitros. For the future please open for every request a new thread. Thanks.

Raymond17:48, 22 April 2021

Encyclopedia of Life: no export since 29 August 2019

Edited by author.
Last edit: 08:26, 21 April 2021

Is the "Encyclopedia of Life" (EOL) project still actively maintained ? Or just dormant (waiting for further developments). There's not been any commit in their repository since 29 August 2019:

But in fact there's not been any other commit for any other part of their project in their repository (and no progress at all in their online bug reports). As well the online version of the site seems to be frozen from the same date.

If it is maintained now by another administrator, using another repository, or going to become a closed project, or waiting for a new admin, we should be informed.

Verdy p (talk)19:17, 26 March 2021

Hi Verdy p,

Changes to Encyclopedia of Life are pushed to this repository:


Abijeet Patro (talk)10:22, 31 March 2021

Then the projet portal gives the wrong repository if it has changed. It needs to be updated.

Verdy p (talk)12:44, 1 April 2021

I see you have done that, thanks.


Abijeet Patro (talk)04:08, 21 April 2021

Missing space after punctuation in Phabricator:phabricator_ext-core-*/en

Most probably, there where newlines between sentences in the original source code, that were incorrectly stripped while joining lines, instead of being converted to at least a whitespace.

Another typo in the same "phabricator_ext-core" package:

Verdy p (talk)09:25, 14 April 2021

Account problem

Hello, is there an option to regain access to my account User:Spacebirdy. I can verify who I am.

Password reset did not work, I did not get a mail nor in my spamfolder.

Kind thanks in advance, --TheSpacebirdy(talk): I am Spacebirdy 11:22, 8 April 2021 (UTC)

TheSpacebirdy(talk): I am Spacebirdy11:22, 8 April 2021

I've also requested a password reset for the user. Let me know if you still don't receive an email.


Abijeet Patro (talk)04:27, 21 April 2021

MediaWiki:Contenttransfer-too-many-pages-warning/en and various typos in today's Mediawiki package for content transfers and page merges

Dummy repetitions of the word "pages" in the source English message (inside and outside the PLURAL tags). And other typos in "Contenttransfer" (all are on new resources changed or created in the last few hours):


Verdy p (talk)15:34, 14 April 2021
  • For ContentTransfer: Gerrit:679637
  • For MergeArticle: Developer informed per e-mail.
Raymond06:35, 15 April 2021

The word "phase" present in the English source (as well as in the "/qqq" page where it was probably copy-pasted) may actually be probably a typo, used instead of "phrase". I don't see any case where "phase" would make sense for the automated conversion of language variants (i.e. actually characters and phrases) by MediaWiki...

Verdy p (talk)23:13, 12 April 2021

Developer informed per e-mail.

Raymond06:45, 15 April 2021

Problem saving links with hardcoded diacritics via the translation interface

Hello. I'd like to report a problem when saving links with hardcoded diacritics (č, ž, š) via the translation interface. The error provided was as follows: "The following parameter is unknown: %8". I have been able to save the link by editing the source of the message directly. The error occurred in Blockly:MATH CONSTANT HELPURL/sl. Should I file a bug on Phabricator? Thank you for your feedback.

Eleassar (talk)12:26, 20 March 2021
Edited by author.
Last edit: 21:05, 3 April 2021

URLs in basic format are not "hardcoded", they are usually "url-encoded", by transformating each byte of UTF-8 sequences for non-ASCII characters into 3 ASCII bytes ("%nn" in hexadecimal). The leading byte is URL-encoded in "%C2".."%FD", the following 1 to 3 trailing byte(s) are in "%80".."%BF" (the number of encoded trailing bytes depends on the value of the encoded leading byte), so this bug affects any Unicode character that contain any trailing bytes URL-encoded in "%80".."%9F", i.e. one half of all non-ASCII characters, because the's UI incorrectly assumes that "%80".."%89", "%90".."%99" (or "%8" and "%9" for actual bytes URL-encoded as "%8A".."%8F" or "%9A".."%9F") are an incomplete scanf/printf placeholder, not correctly terminated by a valid type/format letter (so yes this is a serious bug)

When trailing bytes are in "%A0" .. "%BF", this bug does not occur because "%A" or "%B", in capitals, are not recognized as valid placeholders for C/C++, but the bug would occur if these bytes were encoded using non-standard lowercase in "%a0".."%bf" (because "%a" and "%b" could eventually be placeholders in some C/C++ libraries using extended scanf/printf formatters). actually does not properly check if theses are valid C/C++ placefolder for print/scanf. It does not even know that the message will be used with a C/C++ library, and it also supposes this could be placeholders for other languages (such as DOS-Command or NT-CMD shell variables, or libraries for Java, Javascript, PHP, Python...).

Here you tried "%8D" which superficially looks like a printf/scanf placeholder for a format of length 8 but unknown type/format letter "D"; as this is not recognized, then TranslateWiki assumes this could be also a basic "%n" placeholder for another syntax (a shell syntax for or some other programming language of library), and errs because there's no such "%8" placeholder in the original string to translate. What does is just making superficial guesses, with frequently false assumptions.

  • One possible workaround could be to link to another redirecting article that does not use these characters in their title (e.g. redirecting the English title).
  • Another alternative would be to not URL-encode non-ASCII characters in the URL, using the IRI syntax supported by modern browsers (and supported also by the MediaWiki parser).
  • You've found the wordaround using the MediaWiki editor instead of the Translate UI (but note that even if you've edited it there, the text cannot be validated in the "review" UI of TranslateWiki, or will resurrect if one needs to point to another URL on the target wiki).

This is a bug of the Translate interface itself: the solution would be to mark the resource to translate as not using the Mediawiki syntax (if this is the case) and containing no C/C++ "printf/scanf-like" placeholder when importing the resource on, so that its UI won't perform an incorrect validation check.

As far as I know, the UI of still does not support such flagging (unlike what other common UIs for translations of .po/.pot files for gettext) and just makes some "magic" guess of the format used, assuming it is either using the Mediawiki syntax (where such URL-encoding of URLs is not needed, but where "{}" and "[]" are special-cased for MediaWiki's parser, as well as "$name" for Translatewiki's syntax itself and supported in the Mediawiki API internal libraries, and a few other syntaxes) or the placeholders in C/C++ "printf/scanf" format strings. should not perform such magic guess of the expected format. It creates false positives and does not properly validate all what may be needed for projects. It should support resource-flagging like in .po/.pot translation tools (where the uncompiled ".po" format uses special comment-lines starting by "#," before the resource texts starting by "msgid" or "msgstr"), using some metadata separated from the original string, possibly stored in the "/qqq" doc subpage, or in a dedicated "/qqx" subpage, or using some hidden tag in the source page (like TWN already does when prepending hidden "!!FUZZY" markers in translated subpages that need updates).
I would suggest prepending "!!FORMAT(...)" or "!!{...}" markers is source pages to store that metadata, and possibly as well in the translated pages to make sure that these special markers are in sync with the original).
As well, a project should be able to store such global metadata for their whole message group (to provide some defaults that could be overriden in specific resources using the special marker), notably the programming language that will use these resources, so it will know if printf/scanf format strings are really needed, or if Mediawiki or HTML syntax is expected. This means creating a special page for each message group, containing the group description, contact info, supported formats (including supported plural forms), URL to help/support pages, URLs to their bug tracker and relevant discussions or terminologies for specific languages...
These changes in TWN would make this wiki more universal to better support more projects. The alternative for these projects are to use online translation tools other than (most of them are built for .po resources with gettext)...

The alternative would be for Blockly to accept this string in IRI format, natively in UTF-8 (like in the address bar of modern web browsers, or in the Mediawiki parser), documenting that the URL should not be URL-encoded (this would require Blockly to URL-encode that IRI itself, either in its runtime code or during the import of translated resources from TWN to their code repository) and documenting that info in the "/qqq" doc subpage of However that last alternative requires involving Blockly developers, notifying them, and make them aware of what they can do when importing/exporting their project with (only these developers can instruct translators about what they can do).

Verdy p (talk)19:32, 20 March 2021

Hi, Verdy. Thank you a lot for your detailed and clear explanation. The last option would certainly be best but would require someone with the relevant technical knowledge to communicate with developers. Would you be willing to take this on? Otherwise, I'll ask a colleague or will try to do it myself. For the time being, I'm staying with the workaround. --Eleassar (talk) 08:14, 21 March 2021 (UTC)

Eleassar (talk)08:14, 21 March 2021

Feel free to link this talk thread. I would be pleased to see such suggestions implemtend somewhere for improving and better support the hosted projects with better communications and reporting with translators, and improved checking and validation of translations.

Verdy p (talk)22:32, 3 April 2021

I have disabled variables check on this message.

Nike (talk)17:22, 14 April 2021

North-Central Dargwa (or Dargin) language [dar]

Hello, here is the Incubator of, as I understood, literary Dargin (Dargwa) language, with the "dar" ISO code. But I couldn't find this language on Translatewiki. I also ask to enable the ability to translate the interface of the Tsudakhar language (the north-central group of Dargin languages). I believe that it has no ISO code, so it could be "dar-tsud" or "dar-cud".

Soul Train (talk)15:38, 12 April 2021

North-Central Dargwa is in Translatewiki./net, but may need to be opened for work: Portal:Dar, and I think it is already appropriate for your demand, even if the "babelbox" incorrectly abbreviates the language name to just "Dargwa", the ISO 639-3 code [dar] is already for the north-central group of Dargwa (or Dargin).

For such dialectal division (actually you propose a dialect within North-Central Dargwa), you need at least 5-letters of extension (and the extension registered in the IANA database, such as [dar-tsuda] or [dar-cudar]) : effectively, all "extang" subtags (3-letters after the primary language subtag) are permanently reserved in BCP 47, and since the publication the reform in RFC 4646, they are deprecated by the publication of ISO 639-3, which stil considers Dargwa [dar] as a single language (but still not as a macrolanguage, because it contains no other single language).

As long as the dialect group is not in the IANA database, you would have to use a private-use extension (starting by "-x-", followed by another subtag using 1 to 8 letters or digits), such as [dar-x-tsuda] or [dar-x-cudar].

So certainly not "dar-tsud", nor "dar-cud", per BCP 47 encoding rules.

Look at: (and related entries in The Linguist List), which list these dialect groups (Glottlog assigns its own private-use codes for language groups or dialects, using 4 letters followed by a number; but they are distinct from ISO 639 codes and BCP 47 tags):

  • Megeb
  • North Dargwa
    • Cudaxar (or Tsudakhar) : this is probably the dialect you are speaking about...
    • Gapshin-Butrin
    • Kadarskij
    • Muirin
      • Dejbuk
      • Xarbuk
    • Nuclear North Dargwa
      • Mugin
      • Murego-Gubden
      • Upper Mulebki
      • Aqusha-Uraxi (or Uraxa-Axusha)
        • Akusha (or Akkhusha, Urakha-Akhush, Urkarax)
        • Uraxa

You are refering to the North and Central group of Dargwa dialects, which is exactly what [dar] itself encodes as a single language. Your reference to "Tsudakhar" is just one possible alternate name of the language, used when focusing just on one of its dialects (and not the whole group, i.e. [dar] itself). So your request seems quite confusive.

The "South Dargwa" group is not part of [dar] and refers to two other languages with their own separate codes (in Glottolog and the linguist list, even if they still don't have an ISO 639-3 code for them). South Dargwa languages are still not encoded in ISO 639, most probably due to lack of studies and litterature about them (very few references found in Glottolog and the Lingist list, all quite recent, with only one in 2003, the next one in 2012, the first dictionary Southwestern Dargwa having been published only in 2017 by a single author for the "Sanzhi-Icari" dialect which is apparently its most common one buyt possibly partly covering some other dialects; no litterature is found for the 2nd South Dargwa language, i.e. Kajtak, also not encoded in ISO 639-3).

It is highly probable that South Dargwa languages speakers are/were already using North-Central Dargwa (Cyrillic script) as a lingua franca or for administrative/legal purposes in Dagestan (or some other bordering languages or scripts, like Azeri with the Latin script, or Dagestan and Russian with the Cyrillic script, or Georgian with Georgian script, or the Arabic script for religious purposes), or that informal writings were developed but not widely published, using some phonetic adaptation were needed).
Verdy p (talk)18:39, 12 April 2021

Not allowed to translate a message

I tried to translate (edit a translation) a message in the MediaWikicore message group but i get this message: "You do not have permission to edit this page because it contains raw HTML which can be modified to affect all visitors." So how do i translate it?

yardom78 (talk)12:40, 9 April 2021

This is to prevent insertion of malicious code (notably rogue links to bad websites, or dangerous javascript that could steal data from the user).

Usually this occurs when the resource to translate contain raw HTML and the HTML elements or some of its attributes are not completely safe, or is not checked automatically as being safe, or uses an uncommon encoding and is not fully plain-text or the encoding could be used to bypass a HTML security).

You need to specify the link to the message you want to translate, and the language code.

Then submit your translation proposal in a thread posted here, asking for an admininstrator to submit it for you. Your message will also help project maintainers find a better solution to make these resources more easily translatable without the possible security issue. In some projects, the doc page ("/qqq") shows a contact address or link that you can use (possibly on a repository or bug tracker).

Verdy p (talk)14:47, 9 April 2021

TheWikipediaLibrary - json-based i18n files in addition to existing gettext

Hi there,

We're working to address a longstanding issue that precluded some of our content from being translatable via translatewiki. We're moving messages from the database into json files over the course of a few PRs, with the idea that these would be picked up by translatewiki. Our first take on this is to do a json file per message type and language, and we've started with the descriptions of our partners who provide resources for the library. You can see here that we've got the descriptions for all partners together in a file for each language. If we move forward with this, we'll add new files for other fields as we take that content out of the database. Before we proceed any further, I'd like to check in to see if this approach is workable on your end, or if we need to organize the data differently. Here's our 1st PR to make this move, so you can see what it looks like currently:

Feel free to ignore the python, which does the job of extracting the info and creating those initial json files, and just focus on the json.

Feedback is welcome!

Jsn.sherman (talk)16:47, 30 March 2021

Thanks a lot! JSON is generally easier to manage than PO.

One issue I immediately see is that you output non-ASCII characters as escapes, such as "101_short_description": "<p>\u0627\u0644\u0645\u0646\u0647\u0644", etc. According to the convention documented at mw:Localisation file format, it's preferable to use the actual letters and not escapes. Will it be possible to do it? Since humans won't have to deal with these files very often, it's probably not a blocker, although User:Abijeet Patro and User:Nike should correct me if I'm wrong. That said, humans may have to deal with it; for example, sometimes it's too difficult to find things in translatewiki itself and it's more convenient to grep through the source.

Moreover, perhaps you don't need to convert the translated files at all: maybe it will be enough to add en.json and qqq.json and let the translatewiki import/export scripts generate the JSON files with the translations.

Amir E. Aharoni (talk)16:58, 30 March 2021

I agree that using plain UTF-8 would be better (the "\uNNNN" escape can cause problems, as it requires encoding pairs with surrogates from every character in Supplementary planes, and the convention is not universal, as some tools will require the long form "\U00NNNNNN" instead.

As well it is overlong and some tools may not accept leading zeroes, generating ambiguities, unless they use a strictly conforming JSON parser). No such problem with UTF-8, as the only escapes needed are for quotation marks and backslashes inside actual texts, and some ASCII controls like TAB and NEWLINE: this is much simpler to parse anyway even with only a few ASCII exceptions).

You should ensure that the generated JSON is strictly valid to the JSON standard (and not dependant on the old Javascript implementations that had these caveats). You may eventually be lenient when parsing input JSON, as long as there's not any possible ambiguity.

Verdy p (talk)17:20, 30 March 2021

This is all extremely useful stuff. We should be able to do UTF-8 in our initial output and add a json linter to our CICD process to make sure that we can parse the input.

On the creation of files: It's actually easiest for us to create them all no matter what, but we can update to cull the empty ones. We do have a couple of existing translations currently, so it sounds like the ideal process might be to create qqq, en, and then any translations that we do have?

Jsn.sherman (talk)17:46, 30 March 2021

Hi Jsn.sherman

The JSON structure appears to be good and we should be able to process it on It will require a small change on our end to read the new JSON file. This change will also be needed if more JSON files are added in the future. You can also use the banana-i18n format for strings in the JSON.

Could we skip the keys that don't have any definition such as: "24_description", "78_description"? These keys appear to be machine generated, can we assume that these keys will not change?

I see that (almost) all the strings in the English language end with "\n". Can this be added programmatically? It maybe difficult for translators to recognize and add this at the end of every translation that they make.

Regarding creation of the language / translation files, only create the language files for which you have translations. When importing the messages will take care of reading them.

One more thing, will add a @metadata key to the JSON file. Example: I hope that this is not an issue.


Abijeet Patro (talk)09:03, 31 March 2021

Yeah, I can see that we need to normalize those trailing newlines. Would stripping them out everywhere (instead of adding them) be a good solution?

We can add that metadata key to start with.

And yes, those keys will not change. We may add new ones over time, but won't change what's there.

Jsn.sherman (talk)14:23, 31 March 2021

Opened: to track this


Abijeet Patro (talk)14:36, 7 April 2021

Our team was just discussing this some more today and we realized that we may be able to accommodate the content covered by this change with our existing ugettext workflow. Feel free to de-prioritize this task while we verify. We should know in a week or so. I cross-posted this to the phab task as well.

Jsn.sherman (talk)14:48, 7 April 2021

Activate new language-code: Aruban Papiamento [pap-AW]


I'm active in the Wiki goes Caribbean working group and would like to request another language code for Papiamento. We already facilitate Papiamentu ('pap'), spoken on Bonaire and Curacao, but Papiamento, spoken on Aruba, is slightly different in grammer and spelling. Per my conversation with Amir, I would like to suggest to use 'pap-aw' for this variant of the language.

Please let me know if you have any questions.

Ciell (talk)20:04, 24 February 2021


Amir E. Aharoni (talk)10:03, 4 March 2021

Hi @Amir, Can you help me find this language on translate wiki?

Ciell (talk)09:03, 29 March 2021

Hmm, for some reason it cannot easily be found in the language selector! I'll try to fix that.

In the meantime, here's a direct link that should work as a start:

This link is for core MediaWiki. You can select other components, such as "Visual Editor" in the project selector on the top right side of the screen.

Amir E. Aharoni (talk)10:34, 29 March 2021

Hi Amir, We seem to have the same problem on Wikidata, the language is not visible yet.

Ciell (talk)16:07, 29 March 2021

Please ask Wikidata developers about it.

Amir E. Aharoni (talk)06:17, 30 March 2021

Please add the Kom language [bkm]


I speak the Kom language of Cameroon, and I'd like to translate MediaWiki into this language.


X-Savitar (talk)11:14, 31 March 2021

This is now enabled!


Amir E. Aharoni (talk)15:31, 31 March 2021
First page
First page
Last page
Last page