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
MediaWiki:Notification-bs-pageassignments-user-group-add-summary215:41, 12 November 2020
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
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


The last revision to this message I see is “You have been added to group $4 that have pages assigned to them”.

This message needs a documentation update, a GENDER magic word for “You have been” (so the name of the current user account must be passed as a parameter) and possibly a PLURAL magic word for $4 if it still can be a comma-separated list of groups.

EDIT: I noticed similar errors in other messages: MediaWiki:Notification-bs-pageassignments-user-group-remove-body, Notification-bs-pageassignments-user-group-remove-subject, MediaWiki:Notification-bs-pageassignments-user-group-add-body, MediaWiki:Notification-bs-pageassignments-user-group-add-subject. All of these are marked as outdated in the translation tool.

The group manager's username (the person who is adding or removing the addressee from a group) is omitted and probably isn't necessary in any language, but the addressee (the currently logged user who's reading the notification) is mandatory.

Thank you, and I hope my explanation isn't confusing.

ArenaL5 (talk)20:33, 10 November 2020

Maintainer per email informed. Hopefully he will answer here.

Raymond08:50, 12 November 2020

Thanks for this feedback! I have created an internal ticket to address this. Will be fixed soon. Reference is ERM21752.

Osnard (talk)15:41, 12 November 2020

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

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