Support

show archives

Problems? Questions? Suggestions? Write your message below. – See also the FAQ or try to catch us in IRC.

Your request has been forgotten? It's suggested to use {{Support}} in thread summaries, see also documentation.

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

 Done

Can someone block User:Obsuser? He's edit warring, behaves stubbornly, does not respect the agreements made between Serbian translators regarding translations, and translates too literally. For example, the changes he has made in this edit only make it difficult to understand the text. He translated "Intended blockee" as "Намењено да се блокира" (Intended to block) -- which is very unclear in general, let alone in the Serbian standard language. The previous translation was "Блокирани корисник" (Blocked user) -- which was a very natural option. Due to the same pattern of behavior, he was blocked on Serbian Wikipedia permanently more than a year ago. User:Kizule can confirm this since his mother tongue is also Serbian. Thanks in advance!

I can confirm all things which BadDog said. He (Obsuser) still doesn't understand what teamwork means.

Hello!

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!

• chemical formula and more from the Math extension
• graph and more from the Graph extension
• map and more from the Kartographer extension

Thank you, @Raymond:!

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.

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.

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?

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).

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).

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.

Ok then, ko-Hani it is.

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.

"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.

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.

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).

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

Edit: There are also obsolete <tt> codes in this link: https://translatewiki.net/w/i.php?title=Special:SearchTranslations&query=tt&language=en

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)...

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.

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

Discussion: https://ku.wiktionary.org/wiki/W%C3%AEk%C3%AEferheng:D%C3%AEwan#Guhertina_nav%C3%AAn_r%C3%BBpel%C3%AAn_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î

Thanks.

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.

Thank you, Raymond.

Patch create for Notifications (Echo extension).

Gerrit:632917.

Why does not ⧼Lang⧽ displayed correctly?

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)

I see. Thanks.

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.

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.

Hi all. Yesterday, I made some changes to the Pywikibot translations (ar, ary and arz languages). Today, L10n-bot only exported the ar translations but not the ary, arz ones. Specifically, it didn't export Pywikibot:Redirect-broken-redirect-template/arz and Pywikibot:Redirect-broken-redirect-template/ary. @MarcoAurelio: suggested that this may be due to a configuration issue. So, could someone take a look at this issue, please? Thank you.

Only special thing I see is that these are optional messages and the only ones in that language for that group.

There are others too but shipped years ago: https://gerrit.wikimedia.org/r/plugins/gitiles/pywikibot/i18n/+log/1625ccca46e697df922195a03f23e3461f0efc8c/interwiki/arz.json

Hi,

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).

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

Could someone fix this?

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

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.

Patch committed: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/631908

Waiting for review

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

Hello

I would like to change my name to eduaddad

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

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

yes

Request username change: ghkdekdns71 → Drhyme

 Done

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

 Done

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.

Done, thank you for asking promptly.

Many thanks.

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!

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.

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.

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".

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

I confirm.

Thanks. Patch committed waiting for review.

Their documentations (common_details, note, diary_entries) say “Leave untranslated to use the default for ‘en’.” This sounds much like optional messages.

THe description may be just an indication. In my opinion it is superfluous indication, as all translatable messages use "en" for their default, as long as they are not translated. Note translating them is still a bad idea: it's still best to confirm that the English term is actually the one used for "coordinates", which is obviously not correct in all non-Latin languages and most Latin-written languages that have their own word (even if it's an orthographic variant). E.g. in French, "coordinates" would look wrong, we want "coordonnées"...

Optional messages are for things whose translation is not needed for common users, e.g.

• messages in technical logs, mostly intended for being reported to a bug maintainer, and not directly part of the UI (even if you can see them by pressing a "Detailed" button, or if they occur on the middle of log files containing many untranslated items such as fragment of code, track traces, encoded values in hexadecimal or compressed bitfields, locale-neutral timestamps, CPU/resource usage, objects/classes names, API names...
• or if they are about messages only seen by a few authorized admins of the service; or just a few users choosing to use an "advanced mode" or participating in "beta tests".
• or if they are about transitory messages that won't last for long, waiting for another solution to be finalized and deployed.
• this also concerns many untranslatable names like brands (which are often restricted in the number of translations that they registered for specific markets) or people names (if they have several public identities for specific markets or specific uses such as romanizations of Chinese people name, which are not easily transliterable unless these people transliterated these names themselves and registered them to get some valid status for their travels abroad or their international business).

I think you misunderstood what these messages are about. They don’t translate the word “coordinates” (which should be translatable, as it’s likely to be different in other languages), but just the comma separator—just like MediaWiki:comma-separator from MediaWiki core, which is optional.

Done.

Hello,

The name of Guianian Creole (gcr) in French is "créole guyanais" ([1]). The name of Western Armenian (hyw) in French is "arménien occidental" ([2]). Currently, the names of the languages on the links from the french wikipedia to wikipedia in these languages is displayed in English. Can you please insert the French names above? Otherwise, please point me to the relevant support board. This request was deemed out of their scope by CLDR [3].

C'est déjà bon maintenant en français pour les noms affichés sur les portails de ce wiki et la description des catégories (voir Portal:gcr et Portal:hyw).

Pour l'arménien oriental, pour l'instant il est groupé sous le code de macro-langue "hy" (arménien sans précision, l'arménien oriental restant utilisé par défaut si pas de traduction en arménien occidental, qui est de création plus récente)

Pour traduire les "#language:" (mot-clé magique de Mediawiki), ça se passe ailleurs (dans la base de données CLDR des noms de langues pour BCP 47, et sinon dans la localisation de MediaWiki lui-même en attendant, à demander aux admins développeurs de Mediawiki et chargés du déploiement sur les sites Wikimedia qui peuvent définir des surcharges spécifiques à Wikimedia y compris pour des codes non conformes à BCP 47). Ce n'est pas fait ici, hormi pour quelques projets qui proposent de traduire ces noms dans certaines unités de traduction correspondant à leurs besoins propres! pour faire la demande à Wikimedia, aller sur Phabricator, il sera décidé ensuite si cela va dans Mediawiki ou seulement dans un patch spécifique de déploiement interne pour les wikis de Wikimedia (et pas forcément tous non plus: le patch peut aussi être intégré dans des modules PHP spécifiques à chaque wiki, par les admins de chaque wiki ayant le droit modifier ces fichiers de ressources PHP qui modifient le comportement par défaut de Mediawiki, lequel s'appuie uniquement sur les imports de CLDR, donc sur les votes des participants sur la plateforme d'Unicode).

Sans intervention des admins de chaque wiki, la solution la plus rapide est d'utiliser un modèle wiki local qui, comme ici, va utiliser #language: en dernier ressort (fallback par défaut) pour les paires de codes de langues non pris en charge par le modèle lui-même. un tel modèle wiki ne demande pas de demande spéciale, mais il est à faire accepter par les communautés de chaque wiki. Sur Wikimedia Commons ce n'est pas un modèle wiki mais un module Lua qui vient surcharger le mot-clé "#language" (puisqu'il faut très longtemps pour faire approuver un nom dans CLDR (des années...) puis ensuite l'importer dans Mediawiki, le déployer dans une version et permettre l'adaptation des modules PHP ou Lua existants et éventuellement nettoyer plus tard les modèle wiki (une fois passé l'accord de la communauté locale du wiki qui peut vouloir conserver les surcharges selon les usages au moins pour éviter de casser des liens vers des noms de pages dépendant de #language, ou du code PHP local, ou de modèles ou modules locaux).

Changer un nom de langue déjà utilisé sur un "gros" wiki n'est pas évident, d'autant que les langues ont de nombreux noms synonymes ou alias, et que les articles et pages peuvent regrouper plusieurs langues ou dialectes dans le même article (différentes sections) ou des articles différents: cette décision est communautaire, et que la classification des langues , variantes et dialectes est évolutive et pas définitive et qu'on découvre des tas d'homonymes et noms ambigus dont la désambiguisation est spécifique à chaque wiki en fonction de son contenu local. Et il y a souvent des controverses sur des tas de noms de langues minoritaires selon l'usage (vernaculaire ou scientifique/technique/systématique), la géopolitique, ou les besoins courants (où on abrège souvent...). Sur les wikis de Wikimedia, les noms doivent respecter une règle de neutralité et de consensus parfois dur à obtenir quand une même langue a des noms "officiels" mutliples (selon le gouvernement, le régime, ou l'entité politique ou sociale et leur perception du contexte historique). Même sur CLDR, on a du mal à trouver les consensus nécessaires à tout changement. Des débats animent aussi l'ISO concernant les noms dans la norme ISO 639, et à l'iETF concernant les noms dans la base IANA des sous-labels pour BCP 47.... Les débats n'en finissent plus si on veut satisfaire tout le monde, alors autant obtenir un consensus local réduit à un seul wiki (qui pourra s'appuyer sur l'usage local dans le wiki lui-même et faire des "mesures" pour voir si ça vaut le coup de changer un nom ou changer une orthographe dans des langues où il n'y a pas d'orthographe officielle ou bien où il y a plusieurs autorités académiques qui ne s'entendent pas entre elles, comme on le voit même en anglais, en chinois ou en espagnol)..

Patch created: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/cldr/+/627812 waiting for review.

You ask me to review it in GerritWikimedia, I've replied to the notification I received by mail, but GerritWikimedia fails to login me: I have an account, it was created, I have tried resetting the password, it worked, but then the logon screen rejects the logon/password (visibly it has a bug if it does not accept the underscore in my user name, even if it created the account with it!)

Anyway I can reply here that your patch (for LanguageFr.php in Mediawiki's localisation files) looks good for me (from the diff displayed).

You may include a link in Gerrit showing this talk thread with my review here, if you did not receive my reply by mail after the notification I received, or you can copy-paste the previous paragraph.

The patch was reviewed and submitted a few minutes ago. Should go live on Wikipedias & Co next week.

? This issue is unconfirmed, still to be investigated

Hey, I was wondering, is it possible to have an expedited export for newly translated (to Farsi) strings in Translating:DiscordWikiBot? We finished translations two hours after the Monday export schedule, and we really need them by tomorrow. Thanks.

Sorry, I did not see this message earlier. I have done an export now, anyway.

Hello, please rename my account Zoranzoki21 to Kizule for consistency, as I've requested it already on "metawiki".

Also rename Zoranzoki21-Bot to KizuleBot for same reasons.

Best regards, Zoran.

For security reasons, I want to confirm request via this account, that this is my bot account.

Best regards, Zoran

 Done for both accounts.

Thank you Raymond. But, I've found that L10N-bot added in .json files new username (example). Should I remove my old one from these files?

Hi Kizule, I think that was an expected behaviour. Removing your previous username is not necessary. A lot of work if you want to do it by yourself....

Okay, thanks! I'll leave everything as is. :)