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

Hello. The current option is no longer used. Wikibooks, Wikisource, Wikipedia, Wiktionary, Wikiquote.

Ana Səhifə —→ Ana səhifə

Turkmen (talk)20:58, 11 June 2021

Incorrect file name for MantisBT - hindi translation

A user recently submitted translations for new Hindi language on MantisBT project.

Changes were committed to MantisBT repo but the file strings_hi.txt is not following the naming convention, so the translations are not picked up by the Lang API.

File should be called strings_hindi.txt

Can you please fix that ?

Please update when done, thank you.

-- Damien09:43, 30 May 2021

Done and done.

Nike (talk)08:41, 31 May 2021

Thanks !

-- Damien07:30, 1 June 2021

Problem on MediaWiki:Wsu-js-batchtable-status/en

There is a problem with MediaWiki:Wsu-js-batchtable-status/en. If $2 is zero, extra "." appears in the resulting text like this: "99% complete. .". I suggest joining "." into the inner text like {{PLURAL:$2|0=|$2 failed.}}.

UsagiNeko (talk)06:45, 30 May 2021

Thanks. Fixed upstream. Will be reflect here soon.

Nike (talk)08:26, 30 May 2021

Offline PO File

If I update translation file using gtranslate and create an update PO file, will it be accepted for translatewiki? Is there any criteria for offline translation approval?

ajaysajay (talk)14:45, 29 May 2021

Please read the guide at Then submit a link to your translated po file here. After one successful submission, you will be given the rights to use Special:ImportTranslations yourself.

Nike (talk)08:24, 30 May 2021

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

Just below the orange notice there is a word 'papamientu'. I'm not sure what a papamientu is, but could it be that the word 'papiamentu' is misspelled here?

Ciell (talk)18:11, 9 May 2021

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