View source for Thread:Support/Portal:pap

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)

First page
First page
Last page
Last page

Understanding Review Queue

I'm trying to understand review workflow. I started translation of a project ( which has multiple subprojects. In one case, the translations is parked for review (where I cannot act). In another case, I was able to review and act. Does this workflow depend on individual project settings? If yes, who is the the person to approach for reviewer role?

ajaysajay (talk)05:45, 24 May 2021

What do you mean by "parked for review"? Was the translation not committed upstream at MantisBT?

Nemo (talk)05:50, 24 May 2021

When I see the status it shows "100% translated, 0% reviewed". At another translation platform (transifex) there may be two different roles for translator and reviewer. I read the documentation and could not find if translatewiki also has two different roles for translator and reviewer.

As regards commit, overall translation level is still below min expected percentage (MantisBT page says 40%) in main project, so I'll continue to translate and verify the results once I achieve that level.

ajaysajay (talk)07:34, 24 May 2021

There is only one role here, which allows both to review and translate. You cannot review your own translations though, only translations from others.

There is currently no review threshold for exports, the threshold only checks translation completion percentage.

Nike (talk)10:01, 28 May 2021

That's what appeared to me when I started. Since some of work have progressed and reflected in commits to respective projects, I've full visibility of the process.

Thanks for help and clarification.

ajaysajay (talk)05:56, 29 May 2021

IRC updates

Our IRC channel has moved from Freenode to Libera Chat and is now called #translatewiki instead of #mediawiki-i18n. There is also #translatewiki-rc that relays recent changes feed. If you are using IRC, please join our new channel.

If you come across old references, please update them to the new channel, or let me know so I can do it. You can help by updating outdated translations for pages Project:About and Translating:New project.

I would also like to ask whether you are interested in translatewiki branded cloaks on Libera Chat? If so, I am wondering whether we should have flat cloaks like translatewiki/username or role-based like translatewiki/translator/username, translatewiki/staff/username.

Nike (talk)10:10, 28 May 2021

Request for variants under Wuu

Wuu has two writing systems. At this time, most of the messages are written in simplified Chinese characters, I wish to enable two new variants: wuu-hans "吴语(简体)" and wuu-hant "吳語(繁體)", and fallback to wuu when they are unavailable.

Subarupan (talk)08:01, 27 May 2021


Moment.js doesn't have a Chechen (ce) time format support and falls back to Russian, so Notifications are in an incorrect time format.

Умар (talk)13:03, 26 May 2021

I am not sure if this can be fixed here. Better to report it upstream:

Raymond13:12, 26 May 2021

link issue on MediaWiki:Growthexperiments-help-panel-question-subject-template-with-title

There was a problem with Growthexperiments-help-panel-question-subject-template-with-title ("Help panel question on $1"). If $1 is "Category:something" it will be sometihing like [1] ("หมวดหมู่" is alia for Category) and add page to category. I would suggest to add ":" to escape category magic like [[$1]] → [[:$1]]

Thank you for the report. I have submitted patch Gerrit:693604, waiting for review now.

Raymond11:12, 23 May 2021

Above patch was approved and will go live this or next week.

Raymond11:00, 24 May 2021

Tarandine - false not update messages

In group list about Tarandine localization, I see (since last March) some groups with not update percentage, but when I try to fix the messages I've NO MESSAGE TO UPDATE

Group list.png

Please fix this error

Joe Taras (talk)08:40, 23 April 2021

It's very difficult work with you! A simple request to clean the summary abour group messages becomes an impossible things. This language has one of more translated but os not right by you don't care about it.

Joe Taras (talk)08:03, 4 May 2021

Hi Joe,

All those skins have optional messages that are translated but have become outdated and need to be translated again.


Also see: and to understand why optional but translated messages count towards the group statistics.

Here's how you can access optional messages:



Abijeet Patro (talk)06:35, 6 May 2021

Thank you dear. I've no checked the opzional messages. Have a nice day ;)

Joe Taras (talk)08:18, 17 May 2021

Changing translations directly at the source code

I am the developer and project contact of Cita. The translation project began a couple weeks ago and it's been translated to multiple languages already. That's so cool! Before having the project on translatewiki, I took care of Spanish translations, which is my native language. Development of Cita continues and there usually are new messages or message changes. I would like to be able to change the Spanish translations directly at the source code when corresponding changes are made to the English strings. Otherwise, I have to wait until changes are pulled by translatewiki, then translate to Spanish online, and then wait again until translatewiki sends a pull request. Would this be possible? Something similar happens with message documentation (qqq). When a new message key is added, it would be easier to immediately add the corresponding message documentation, rather than waiting until changes are available at translatewiki (chances to forget are so high). Thank you very much for your support!

Diegodlh (talk)22:24, 11 May 2021

Hi Diegodlh, adding new/updated translations together with new/updated messages is OK.

But for changes of translations unrelated to patches I kindly ask you to do this in translatewiki. Otherwise the import process could get out of sync.

Raymond20:09, 12 May 2021

Thanks, Raymond! I'm planning to do this only occasionally and mostly for new messages, sure. Thanks!

Diegodlh (talk)23:34, 15 May 2021

TheWikipediaLibrary - more json-based i18n files

Hi there,

We're working to address a longstanding issue that precluded some of our content from being translatable via translatewiki. We've now moved the last of that content into json files, with the pattern: `locale/<locale_code>/tag_names.json` example:

We'd love to have these picked up as translatable strings.


Jsn.sherman (talk)16:07, 11 May 2021

Problem saving translation

This concerns an issue saving a Dutch translation for the following message:
{{PLURAL|zero=No reports|one=1 report|%{count} reports}}
{{PLURAL|zero=Geen rapporten|%{count} rapporten}}

Editor -this should be the most recent text according to the History page-:
{{PLURAL | zero = Geen rapporten | één = 1 rapport |%{count} rapporten}}

My attempt which did not get saved and would not return an error message when published -only an empty page-:
{{PLURAL|zero=Geen rapporten|one=1 rapport|%{count} rapporten}}

There is also an issue previewing a topic on this Support page; it sends you to a different page and as such returns "this topic does not exist". This does not happen with previewing translation edits in the wiki editor.

Danieldegroot2 (talk)16:04, 11 May 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/Portal:pap.

Blocking system

Hello! I usually contribute in another project, such as Wikipedia. I don't really understand about technical stuffs in translatewiki. So, I found an abuser's (AJBot2) contributing here, he's already global locked there. I want to make block request for him but i dunno how and where. His translations are mostly nonsense. Anyone can help me for this case? Thanks for the help!

ANukuma (talk)01:10, 30 April 2021

Hi ANukuma,

Thanks for bringing this to our notice.

I've left a comment on their talk page:,_unnecessary_and_unwanted_contributions

I will check back their contributions again after 7-10 days to see if anything has improved.


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

Thank you so much for your help! Cheers.

ANukuma (talk)08:21, 7 May 2021

[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

I've not edit-warred, even if a user disagreed on some thing, he started to discuss after the fact, and changed his mind several times, using unexpected brutal comments. And it's definitely NOT "impossible to discuss with me".

I've proposed several things, and again he continues with the lack of politeness. I've discussed fairly (and the prior blocking you invoke against me was also unfair, disregarding as well all efforts I made to negociate calmly and discussing the various options: this blocking was appealed but in fact only this blocking unfairly blocked any kind of discussion, so it was only me that was in the impossibilty to discuss, but not because of any action I did myself).

It is a fact that the existing old translation was NEVER reviewed before by anyone, and reviewing is a full part of if this causes any conflicts, there's no need to forget politeness and discussions should start allowing anyone to give his arguments and propose solutions and comparing them.

I was once again absolutely not "off rails" like you state here. This was fully in respect of the TWN site (for an extension which is also not targetting specifically the French Wikipedia where it is seldomly used just by few users, and even less users having the privileges where confusion is possible: there's no confusion at all for the vast majority of users).

So your statement that this could be "very disruptive" is unfair: for whom? very few admins in French Wikipedia or millions of users not having these privileges but that are exposed with incoherent translation with Flow's options? It's a fact as well that the choices made in English are using another kind of confusion ("delete" vs. "suppress", two different admin optins), which does not help the translations. A single user made an unreviewed choice 3 years ago and tyhat problem was not even reported before. Still, coherence of translations in TWN are a documented goal (that Flow somewhat violates, and the "solution" proposed 3 years ago only in French does not match what was currently used with English that at least avoided breaking the MediaWiki UI coherence for the vast majority of users).

My change in november was part of a normal review for coherence, using the doc provided by Flow authors themselves and visible in the "/qqq" page: this what guided me during the review.

And you are wrong when you say that I changed something used since very long: in fact I just used and respected the translation made since very long in the Mediawiki UI (Flow changed it only in 2017 when it started but this caused an unreported and undiscussed confusion since then in all languages, including English but only for or those very few users having sysop or oversight rights and that should be better trained than the vast majority of users seeing and using "hide" in English, "masquer" in French, without any privilege, but jsut as theur own personal navigation preferences).

I feel that your reaction is very stange: anyone that contributes a lot in TWN will fall into some disagreements with a few users that contribute rarely. This is completely unavoidable. But there's a way to discuss that, and I used that, without forgetting politeness like what your contact did instantly.

Why using such procedure now instead of solving the existing problem created recently only in Flow (2017 for the initial beta tests, but even in French Wikipedia this started being used later in very few user pages) ?

The only real problem is the incoherence (in French only) for not translating "hide" as "masquer" (like it is in MediaWiki since very long) for ALL users. The very few oversighters (on French Wikipedia) should use their own translation for their specific administrative actions without disrupting millions users exposed now with an incoherent translation that does not even follow the **existing** documentation (the "/qqq" page with its links, that I fully respected during a basic review that was not performed by anyone since the initial submission by a single user).

Verdy p (talk)09:39, 22 April 2021

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
First page
First page
Last page
Last page