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
Translations by ChoiChong009:15, 9 November 2020
RC Wikidata207:44, 28 October 2020
Error on MediaWiki:Wmobile-copyright/en323:24, 26 October 2020
Transadmin013:46, 24 October 2020
[Sxr] [Xnb] Translation of MediaWiki interface is not supported by translatewiki.net207:37, 24 October 2020
Start Hanja Script language for Korean1617:09, 23 October 2020
Parameters for illustration118:11, 22 October 2020
Known issue with Timeless014:28, 21 October 2020
Rename my username107:19, 21 October 2020
MediaWiki Visualeditor tooltips (Slovenian)213:21, 20 October 2020
MediaWiki:Lookupuser-id/en218:58, 14 October 2020
New special page names for Kurdish (Latin script) [ ku-latn ]315:13, 9 October 2020
{{int:Lang}}409:40, 8 October 2020
Mediawiki:Blocked-notice-logextract/fr and Mediawiki:Sp-contributions-blocked-notice/fr416:07, 5 October 2020
Change Username322:52, 2 October 2020
Username change104:57, 30 September 2020
Username change105:41, 25 September 2020
Someone please revert my last few 50+ edits to British English MediaWiki massages208:02, 23 September 2020
GRAMMAR for Rusyn201:15, 22 September 2020
Translating namespaces (MediaWiki)307:05, 18 September 2020
First page
First page
Last page
Last page

Translations by ChoiChong

A thread, Thread:Support/Translations by ChoiChong, was moved from here to User talk:ChoiChong. This move was made by Nemo bis (talk | contribs) on 9 November 2020 at 09:15.

RC Wikidata

I'm searching for the MediaWiki-page that shows "Show/Hide Wikidata" in the Recent Changes. Anyone know which one that is? --Ooswesthoesbes (talk) 09:52, 20 July 2017 (UTC)

Ooswesthoesbes (talk)09:52, 20 July 2017
Edited by 0 users.
Last edit: 01:02, 27 July 2017
Liuxinyu970226 (talk)01:02, 27 July 2017
Edited by 0 users.
Last edit: 10:42, 31 July 2017

That might be it. Thank you!

Ooswesthoesbes (talk)10:42, 31 July 2017

Error on MediaWiki:Wmobile-copyright/en

Hi, can someone change MediaWiki:Wmobile-copyright/en to use quotation marks rather than apostrophes in the links as they're currently broken


Nintendofan885T&Cs apply14:25, 26 October 2020

Single quotation marks are valid in the HTML syntax for attributes.

Remember that this resource is NOT written using the Mediawiki syntax, but the plain HTML syntax, so even if it does not render correctly on this wiki, this is only because this wiki attempts to parse it as Mediawiki (where even the <a href="URL">text</a> is not permitted by the wiki; so if it was written using the MediaWiki syntax and rendered by MediaWiki, it would be .[URL text] instead; this is not the case here).

So changing the ASCII single quote to ASCII double quotes would not change the way this message is rendered here on this wiki. Keep it in plain HTML: the message is intended to be rendered only locally by the Mobile app (which uses its own internal HTML renderer with its own embedded browser component, and does not parse the Mediawiki syntax, this text is emitted as is) and NOT on a MediaWiki server...

Nothing is broken here!

Note: you are still free to change these quotes in translations, as long as you use a valid HTML syntax (so don't change the ASCII < and > delimiting the HTML opening and closing tags. As well only use a plain URL (which you may need to change if it has to link to another translated page on the same target site, and keep the "https://" protocol unchanged).

And you are free to use the the quotation marks and apostrophes and all other punctuation appropriate in the target language for the text part of the link. You can test your translation by copy-pasting it in a plan-text file saved in ".html" format, and open it in your browser (unfortunately, the source message is not "meta-tagged" as using the HTML syntax; that's something that Translate wiki should propose to indicate its expected syntax, but that would also involve importing the source message with metadata in the package).

Such message, given it contains plan HTML, should also be modifible only by admins (to avoid injection of dangerous HTML code, such as link to spammed sites, or injection of bad javascript attempting to steal data or break the privacy in the Mobile app). This is something that authors of the Wmobile app should change: they can preprocess this message to generate the HTML code they will inject in their app (without the need to integrate a MediaWiki parser phase in the app itself), and only use Mediawki syntax on this wiki. But anyway this wiki is itself protected and renders the plain HTML link code, so this wiki remaing protected.

Verdy p (talk)18:01, 26 October 2020

Oh, I thought it was broken because the links broke when I clicked on them (it went to')

Nintendofan885T&Cs apply20:38, 26 October 2020

This is a parsing bug of MediaWiki on this wiki; this won't occur with a regular HTML parser. As I said, plain HTML links are not supported by Mediawiki as Mediawiki incorrectly includes the "trailing" quote in it. That's something that MediaWiki should fix as these quotes in HTML are never taken into account, unless they are URL-encoded in HTML.

Note that in HTML both the single quote and the double quotes are valid delimiters for attributes, and which ones are valid as part of the quoted value depends on which delimiting paired quotes are used:

  • If attribute values are between double quotes "...", litteral single quotes ' in the embedded value don't need to be encoded, but double quotes in attribute values have to be HTML-escaped as &quot; (or only if the value is an URL, they can be URL-encoded as %22, which won't need any HTML-escapes)
  • If attribute values are between single quotes '...', litteral double quotes " in the embedded value don't need to be encoded, but single quotes in attribute values have to be HTML-escaped as &#39; (or only if the value is an URL, they can be URL-encoded as %27, which won't need any HTML-escapes)

Note that any single quote or double quotes by IS valid in any standalone URL (except for the leading protocol part or the host/domain part, it is valid anywhere in the optional parts: the path, the query string, fragment identifier) or any URI. Inside a standalone URI, there's no support at all for the HTML-encoding, or for the URL-encoding (which depends on the protocol and the target host/domain part in its own URL parser, but noit at all of the HTML-parser!!!).

Here MediaWiki (on this wiki) does not parse the HTML completely correctly and so it does not use the correct HTML-parsing for delimiting attributes, and then it considers the value as if it was between double quotes (no check is made about which effective delimtier is used in the HTML attribute, so it incorrectly accepts the single quote as part of it, then it takes the wrong decision).

This is effectively a bug of MediaWiki (which could be reported given that the MediaWiki should still parse HTML correctly and should be an extension of it), in its own custom parser. But as I said, this message is *not* to be parsed by MediaWiki and will be parsed by a regular HTML parser which makes the correct decision. The bug is bisible on this wiki when viewing the translated page, but it does not affect the application.

Verdy p (talk)23:17, 26 October 2020


How can I be a transadmin?

--ToprakM 13:46, 24 October 2020

[Sxr] [Xnb] Translation of MediaWiki interface is not supported by

Edited by another user.
Last edit: 07:37, 24 October 2020

Hla’alua Wikipedia (incubator:Wp/sxr) and Kanakanavu Wikipedia (incubator:Wp/xnb ) ,both are open test wiki of the Wikimedia Incubator. There also have valid ISO 639 language code. Due to approval of Wikipedia, translation of MediaWiki interface into their own language in the is one of the requirements before a wiki can be created. But now said that there are not yet enabled. We would like to know what steps are necessary to get the language enabled.

Mecytan (talk)02:46, 22 October 2020

These two related Tsouic languages (originating from a small central area in Taiwan) have their portals (Portal:Sxr, and Portal:Xnb), created since long in 2017, which you can subscribe as a translator. They also indicate already their Incubator wikis.

They are still disabled as there's no support for now in the Translator tools and statistics. Languages are enabled for translation when there's a demand and a convincing desire to start translating them (probably starting by the Mediawiki interface). However, even if this is still not enabled, you can work on these incubators and develop there some pags of terminology that you may want to discuss, and that may be needed to start translting the Mediawiki UI on this site.

This suppoort page is to demonstrate you commiment to this project and ask these to be enabled (but note that if there's no progress or there are signs that you don't work actively with Wikimedia to support the import on the Incubator wiki or on a test wiki, this could be disabled by the admins until there are more contributors taking the project seriously, notably because generating the exports from has a cost that should find a usage on an actual wiki (Wikimedia Incubator is supported but you also need an agreement with other users of its local community to monitor the initial progress and ask for a reasonable review)

Another thing you msut discuss is some additional support in Incubator itself and in the Wikiemdia multinigual tools. Now if the Incubator goes well to the creation of a new Wikipedia, of course these languages should be enabled because the support for these languages will be demonstrated. Note that Wikimedia wikis are not the only projects that you could be working on. For example you may want to translate OpenStreetMap tools, or communication tools that are hosted on this wiki, or would like to develop a wiki for any topic outside Wikimedia, that would benefit as well of the translation of the MediaWiki UI.

You made the appropriate step here. Hope your arguments will be enough to convince an adminsitrator of for you (I cannot do that myself).

Verdy p (talk)03:08, 22 October 2020


I can do this, but I want to make sure first: Who is going to do the actual translations? The two languages have very few speakers. By itself, it's not a problem, but the pages in the Incubators are quite repetitive, and the activity in the Incubators is quite low. Are there people who speak these languages, know them well, and plan to work on localization?

Amir E. Aharoni (talk)15:00, 22 October 2020

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

Parameters for illustration

These words are in the Chechen Wikipedia in Russian. Did I do something wrong?

"img_right = аьтту, справа img_left = аьрру, слева img_center = центр, центр img_frameless = гура_боцуш, безрамки"


Умар (talk)23:55, 21 October 2020

Your edits to MediaWiki:Sp-translate-data-MagicWords/ce have no effects, sadly :-( The process to export such edits from translatewiki to Wikipedias & Co are broken since years. You (or someone else) have to submit a patch to this file:

Raymond18:11, 22 October 2020

Known issue with Timeless

Just heads up that during the latest code deployment today we noticed an issue with the Timeless skin. The echo notification icons are misplaced. We have reported the issue at Phab:T266135 and will deploy a fix once it is available.

Nike (talk)14:28, 21 October 2020

Rename my username

Can you please change my username to Awesome Aasim? I have done so on other MediaWiki wikis, but not here.

Ups and Downs ()09:41, 20 October 2020

Done Done

Raymond07:19, 21 October 2020

MediaWiki Visualeditor tooltips (Slovenian)


I'm looking for translations of MediaWiki buttons for insertion of special objects to translate them to Slovenian and can't locate them.

I'd need help with the following:

  • Chemical formula
  • Map
  • Graph

Thank you!

Eleassar (talk)09:23, 26 August 2020
  • chemical formula and more from the Math extension
  • graph and more from the Graph extension
  • map and more from the Kartographer extension
Raymond15:57, 27 August 2020

Thank you, @Raymond:!

Eleassar (talk)13:21, 20 October 2020

Could someone change the <tt> to <code>? Thanks.

Edit: There are also obsolete <tt> codes in this link:

MuratTheTurkish (talk)09:04, 14 October 2020

I don't like the fact that "code" is "decorated. "tt" just implies a monospaced font and no decoration (which changes the line-height). Such deprecation is badly welcome. The alternative is "kbd". Anyway this "deprecation" is the result of a bad decision, given it is still fully supported in HTML5, and "code" has a different semantic which implies the use of a colorization in a supported programming language (which is not specified here, so it implies a default behavior as plain-text, which is wrong when it may contain internationalisable text)...

Verdy p (talk)18:34, 14 October 2020

Very bad then. That obsolete tag will completely removed in the future. I don't agree some users when they still want to use deprecated tags. Anyways, thanks for the information.

MuratTheTurkish (talk)18:58, 14 October 2020

New special page names for Kurdish (Latin script) [ ku-latn ]

Hello, we want to translate some of the current English names into Kurdish and update one Kurdish translation for special pages (Special:... (Taybet:...)).


In short,

  • LonelyPages -> Rûpelên_sêwî
  • WantedPages -> Rûpelên_xwestî
  • Guherandinên_dawî -> Guhertinên_dawî
  • WhatLinksHere -> Girêdanên_li_ser_vir
  • Contributions -> Beşdarî
  • Watchlist -> Lîsteya_şopandinê
  • Preferences -> Tercîh
  • Notifications -> Agahdarî


Guherto (talk)18:02, 6 October 2020

Hi Guherto,

I have created a patch special pages of MediaWiki core (all except Notifications): Gerrit:632913

The patch needs review. Please check my pach too.

Patch for Notifications follow.

Raymond13:21, 8 October 2020

Thank you, Raymond.

Guherto (talk)15:13, 9 October 2020

Patch create for Notifications (Echo extension).


Raymond13:36, 8 October 2020


Edited by author.
Last edit: 18:09, 20 September 2020

Why does not ⧼Lang⧽ displayed correctly?

Pseudo Classes (talk)10:21, 20 September 2020

Yes We know. There's no support on this wiki.

  • missing code in the Mediawiki hook implementing the "int:" namespace, so it just performs normal lookup of subpages in "MediaWiki:Lang/*" that would need to be created just to contain the same language code used in the subpagename; these pages are not present and maintaining them is long and not efficient; as these resources are not found, all you get is this fallback static text: ⧼Lang⧽
  • no other way to get it from one of the extensions with a custom magickeyword
  • no way to get it from Lua as Scribunto is not installed.

This just means that the rendering (and caching) local pages on this wiki never depend on the current user language (they just depend eventually on the current time or some statistics available about this site with other magic keywords, forcing these pages to expire in caches sooner, and be parsed again). As this wiki runs on a small server, may be this is wanted, however the wiki has many extensions loaded, some of them being very costly (and useless for now, like SemanticMediaWiki which causes troubles). Still there are some contents that are sensitive to the user language, such as statistic graphics shown on "portal:" pages. That's very strange for a wiki that is supposed to be opened to user languages and that promotes translation and translatability, it is not making itself a good demonstration of how the work we do to translate the various projects (including Mediawiki) can also be useful for this site (a Mediawiki-based wiki). This forbids making some local tests: things get translated here, then exported later, imported in other wikis where bugs are noticed, then corrected here (may be) or locally on the target wiki (with overrides, that will then be protected by admins to avoid them to be rewritten by the imports, and finally all work made here or any changes are no longer imported on the target wikis). This causes a break in the translation work cycle, for Mediawiki or for all hosted projects, unless these hosted projects all have a live demo site showing the result early before feeding the actual projects. anyway this lack of {{int:Lang}} has no severe impact on this wiki as there is very few contents outside the translate UI for projects, the portals. And there's almost no article or help page or templates to translate here: all portals are almost monolingual, the only multilingual part is the support page where each posted message is threaded in separate pages in their own language used directly by each sending user (and not translated automatically, users will post add the necessary translations manually below). The portals are just posting lists of links (possibly to other sites) with few details, and this wiki remains small. Verdy p (talk) 13:28, 20 September 2020 (UTC)

Verdy p (talk)13:28, 20 September 2020

I see. Thanks.

Pseudo Classes (talk)13:42, 27 September 2020

Note that I am not the admin of this site; I just help to maintain it so that it remains coherent within its existing limits. The intent is not really to create new contents: the "hosted" projects are here only for one goal: create translations for messages that each project want to localize. The purpose is not to make development, but just create the basic structure that will help translators (not technicians) to do their work appropriately for each language, using the current best known classification and differentiation of languages. That's thy there are:

  • portals for each language, but they are very basic: they just provide some basic links to relevant sources, help people join together, to work across multiple projects that may be translated in the same language. Most discussions for such things will occur in well-known linguist lists (for that we provide codes for relevant standards, and well-known external sources, and in portals you can add a few). On each of these portals, users can register themselves just by pointing to their own user page, where translators can also point to their home pages for any kind of project they want to support (including other projects not translated here). This is a just point of contact.
  • portals for each hosted project: talks about them occur in the relevant maintenance site for each project independently of the language, but there's sometimes the need to create a specific terminology for this project that is difficult to reach but influences how these would then be translated (with more or less difficulties, or specific technical limits that are often independent of the language or script used), so the talks there are more technical but scoped only to the internationalization aspect of the hosted project. If the project already has a dedicated section for this part, it will be enough to just point to it. So there's little actual content here too. And contributors in those sections should still be multilingual but would be more English-savvy than in the previous type of portals.
Verdy p (talk)14:30, 27 September 2020

Thanks. So does this mean I can't create subpages to solve this problem? Sorry, I am not online often and thus there is a delay in reply.

[使用者:偽類]偽類= ([用戶談話:偽類[談話])09:40, 8 October 2020

Mediawiki:Blocked-notice-logextract/fr and Mediawiki:Sp-contributions-blocked-notice/fr


These two messages support the magic word GENDER:, it’s written in the /qqq and it works fine in the French Wikipedia (where they are hardcoded for the moment: [1] [2]), but for some reason they are marked as !!FUZZY!! and the magic words keep getting reverted (ping Gomoko).

Could someone fix this?

Thibaut (talk)12:51, 2 September 2020

German uses GENDER for these messages too without problems. Maybe Gomoko can explain his/her edits?

Raymond14:56, 2 September 2020

Most probably this is because the original English message makes no reference to any variable. Then the "Fuzzybot" changes what is edited and marks it as fuzzy, as if we forgot to remove a reference to an older variable (whose name or ordering would have changed in past versions.

This can only be fixed if the English version makes an explicit reference to {{GENDER:$1|}} even if it is empty in its second parameter or contains a single text (which will be still displayed independently of the variable.

The fact that a variable is marked as "supported" by the underlying app or in the "/qqq" doc page is not enough. Such variable should be present in the source message, even if its value is not used in English or does not change anything.

I tried to use the GENDER there too, I got the same behavior. I don't kwno why it works in German (may the German version was validated BEFORE FuzzyBot makes this check, and not modified since, so FuyzzyBot sees no reason to change it after edit if there's no edit at all.

Note: I the German version is *also* marked now as fuzzy (even if did not change since 2015. The source English message also did not change since 2010).

Or may be the German version was not created by using the normal Translate UI or the normal wiki editor, but by an admin-only tool (such as ReplaceText) whuich can bypass any action made silently by FuyzzyBot or any other deployed hook for Mediawiki on this wiki (this tool makes direct access to the underlying data store, nothing is checked, that's why this tool is reserved to admins only). In summary, ask to the maintainer of the English version to include this variable in the source, even if its value does not change the generated message.

So this can only be caused by a new rule added in FuzzyBot, making SILENT edits (invisible in the history log of the edited pages): Click the "Edit" link on any page. Don't change anything, save the page as is: Noting will be reported in the history log of the page, but FuzzyBot performs changes (it never even adds any tag for the pages that it marks as "FUZZY". Most probably, the "!!FUZZY!!" mark is not even part of the wikitext, but saved as a separate status, it only becomes visible in the wiki editor where it is automatically prepended to the wiki text in the input form.

Each time you press the "Save changes" button in the Translate tool or the wiki editor, there's some hook on this wiki which allows Fuzzybot to check if "!!FUZZYBOT!!" is still present at started (it is silently removed from the actual wikitext, but the fuzzy statis is kept to be set) otherwise Fuzzybot parses the edited text and compares it to the source text, to detect placeholders: if there's any mismatch (notably references to variables that are not part of the source text, it forces the "fuzzy" status. But no change will be really made to the wikitext which is still saved as is (so there's nothing visible in the page's history). Still the status is applied and kept in a specific separate data table of the local database (this table is not part of the core Mediawiki engine).

This really means that

  • But really the English source message should be updated to explicitly contain a reference (even a dummy one) to the "GENDER" magic keyword and to the "$1" placeholder. This requires action by MediaWiki developers to reimport a new version of the English source message to this wiki.
  • This is also another bug in the Translate tool : FuzzyBot makes silent modifications and is not auditable. Only some admin can use admin tools to remove these incorrect status inside the SQL store. This requires action by developers of Fuzzybot for the Translate tool (notably a way to list additional supported variables or magic keywords that can be used in translated messages even if they are not present in the source message, and a modification of the UI for the Translate interface so that it can list these supported placeholders/variables, and some additions to properly tag the syntax to parse the source and target message: Mediawiki / PHP/ C /C++ printf formats/ Java / Javascript I18n/ etc. ? or other flags like restrictions on some forbidden characters, or case folding/normalization, or some custom regexps for filtering whitelisted or blacklisted text fragments, and other options similar to those used in online translate tools for .po/.pot files used in many opensource projects, or other common formats like resource bundles in java, XML-based formats, HTML with a way to associate them with pluggable parsers...)

Two bugs in one (but 3 separate actions to fix it by different admins, plus an admin action on each target wikis where the translated message will be imported) !

  • For now, a local admin on this wiki must use "Replacetext" or some similar SQL tool to remove the status (we know that admins on this wiki have lot of work and have a long list of reported problems they don't fix, including those related to incorrect permanent lokcs left by the "SemanticMediawiki" extension in many categories). Normal users cannot set this status with the existing UI. They just see the result because what is visible is not what they edited and saved themselves.
Verdy p (talk)19:11, 2 September 2020
Raymond09:52, 3 October 2020

Patch submitted and live on translatewiki. The messages should not longer throw an error/fuzzy.

Raymond13:31, 5 October 2020

Change Username


I would like to change my name to eduaddad

Eduardo Addad de Oliveira (talk)17:59, 21 March 2019

I would like to delete this account to make sure the username migration

Eduaddad (talk)18:03, 21 March 2019

Just to confirm, you want "Eduardo Addad de Oliveira" to be deleted right?

Abijeet Patro (talk)14:15, 11 March 2020

Username change

Request username change: ghkdekdns71 → Drhyme

Ghkdekdns71 (talk)14:38, 29 September 2020

Done Done

Raymond04:57, 30 September 2020

Username change

Hi, can I request a username change to stonecy, please? Thank you.

Grkn gll (talk)17:12, 24 September 2020

Done Done

Raymond05:41, 25 September 2020

Someone please revert my last few 50+ edits to British English MediaWiki massages

I recently made more than 50 and less than 100 edits to British English MediaWiki messages, because I accidentally did not notice that my translation language was set to British English. Sorry! Would someone be able to revert all my recent edits to British English MediaWiki messages? Just check my contribs to see them.

Heahwrita (talk)07:20, 23 September 2020

Done, thank you for asking promptly.

Nemo (talk)07:24, 23 September 2020

Many thanks.

Heahwrita (talk)08:02, 23 September 2020

GRAMMAR for Rusyn

Hello! Would it be possible to create GRAMMAR files for Rusyn (rue) please? So far I've only seen it with project names. Wikipedia is the only project in Rusyn (except for translatewiki and Wiktionary in Incubator) - please let me know if it would be preferable to just use the word for Wikipedia instead of SITENAME then. Here is the declension for Wikipedia:

default nominative form: Вікіпедія

genitive: Вікіпедії

dative: Вікіпедії

accusative: Вікіпедію

instrumental: Вікіпедіёв

locative: Вікіпедії

Thank you!

Tkalyn (talk)10:54, 18 September 2020

Is that grammar enough documented (e.g. in Rusyn Wiktionnary or a relevant article that can be reviewed? or some reliable sources?) Declensions are frequently complex and have many exceptions, it's not easy to formalize it it a simple automated function without lot of data and it's not always just a word list because there are also usages, and complex mutations depending on the context and not a single isolated word). That's the same for the complex rules related to transliterations and conflicting orthographic conventions even in the same script (see for example Belarusian). That wiki is not the place where this can be developed: Phabricator would be a more appropriate place to track the project and the plan the efforts needed or evaluate the first proposed solutions (which will almost allways be partial and not working to cover all cases). Human languages are complex, they have a complex history and borrow lot of exceptions from other related languages and social interactions that evolved over the history of peoples and their migrations or invasions (aggressive or progressive). When a language becomes used only as a minority (this is the case of Rusyn) there are no longer strong rules, many forms that would have seemed first as being incorrect become standard, and people forget their historic language or develop new variants which may become divergent with lack of mutual understanding or that cause conflicts of interests.

Verdy p (talk)19:36, 18 September 2020

Hello, there are normative Rusyn grammars that we use in the project, that contain declension information. In this specific case, the word for "Wikipedia" can only have the forms listed. Any other words would also have a limited number of forms. I don't know if there are even any other words that would be needed since I've only encountered grammar being used with SITENAME.

Tkalyn (talk)01:15, 22 September 2020

Translating namespaces (MediaWiki)

MediaWiki: Romanian: Please translate "Gadget" to "Gadget", "Gadget talk" to "Discuție Gadget", "Gadget definition" to "Definiție gadget", "Gadget definition talk" to "Discuție Definiție gadget" "Campaign" to "Campanie" and "Campaign talk" to "Discuție Campanie".

NGC 54 (talk)09:42, 17 September 2020

For the Gadget extension: The upper/lower cases look a bit inconsistent. Could you confirm this pls?

$namespaceNames['ro'] = [
	NS_GADGET => 'Gadget',
	NS_GADGET_TALK => 'Discuție_Gadget',
	NS_GADGET_DEFINITION => 'Definiție_gadget',
	NS_GADGET_DEFINITION_TALK => 'Discuție_Definiție_gadget',

Campaign is part of the UploadWizard extension. Currently no way to localize the namespace, see Phab:T134078

Raymond13:44, 17 September 2020

I confirm.

NGC 54 (talk)15:41, 17 September 2020

Thanks. Patch committed waiting for review.

Raymond07:05, 18 September 2020
First page
First page
Last page
Last page