Page MenuHomePhabricator
Search Global Search

Global Search
Use Results
Hide Query

Use the application-specific Advanced Search for better results and additional search criteria: Tasks, Commits. (More information)
  • T437160: Special:CheckUser: Clicking "copy" scrolls off the page
    • Task
    **Steps to replicate the issue** (include links if applicable): * Set the interface language to a RTL written language in Special:Preferences * Go to Special:CheckUser, and get the actions of a certain user * Under "See results in a table", click the "copy" button **What happens?**: It does get copied, but the wikitext box is far away on the page, and if the CU wants to go back to see the table, they need to scroll a lot sideways to get back to the page. **What should have happened instead?**: It should be like in ltr languages, where this box doesn't appear. **Other information** (browser name/version, screenshots, etc.): {F102000407}
  • T437100: Localize Scribunto namespaces for Magahi (mag)
    • Task
    The Magahi Wikipedia (mag.wikipedia.org) graduated from Incubator recently. Its core namespace names were localized in T432382, but the `Module` and `Module talk` namespaces were not covered, since those are defined by the Scribunto extension rather than MediaWiki core and cannot be translated on translatewiki.net. There is currently no `mag` entry in `Scribunto.namespaces.php`, and `MessagesMag.php` sets no `$fallback`, so both namespaces still display under their canonical English names on magwiki. The [[ https://translatewiki.net/wiki/Support?markasread=288883#c-%E0%A4%90%E0%A4%95%E0%A5%8D%E0%A4%9F%E0%A4%BF%E0%A4%B5%E0%A5%87%E0%A4%9F%E0%A5%87%E0%A4%A1%E0%A5%8D-20260829191000-Srishakatux-20260819214600 | community has requested ]] the following, per the namespace table agreed on the Incubator talk page: | English | Magahi | | `Module` | घटक | | `Module talk` | घटक वार्ता | with `मॉड्यूल` and `मॉड्यूल वार्ता` kept as aliases, since that transliteration is in common use and readers are likely to type it. **Proposed change** to `Scribunto.namespaces.php` in `mediawiki/extensions/Scribunto`: ```lang=php $namespaceNames['mag'] = [ 828 => 'घटक', 829 => 'घटक_वार्ता', ]; $namespaceAliases['mag'] = [ 'मॉड्यूल' => 828, 'मॉड्यूल_वार्ता' => 829, ]; ``` I am not familiar enough with this codebase to be sure that is the right or complete approach, so please correct as needed.
  • T436856: Add Godoberi (gdo) to translatewiki.net
    • Task
    Requested at: https://translatewiki.net/w/i.php?title=Support&oldid=14417271#Request_to_enable_language:_Godoberi Autonym according to: гъибдилӀи мицци. [ ] Add to language-data -- [ ] Run `src/util/ulsdata2json.php` before adding -- [ ] Run `src/util/ulsdata2json.php` after adding [ ] Add to translatewiki configuration -- [ ] Add assistant languages to `mw-config/AssistantLanguageSettings.php` (if needed) [ ] Deploy configuration to translatewiki [ ] Add an entry to LocalNames/LocalNamesEn.php in the CLDR extension (if needed) [ ] Add jquery.ime keyboard (if needed) -- [ ] Add keyboard documentation [ ] Update jquery.uls and jquery.ime in the ULS extension [ ] Deploy ULS to translatewiki [ ] Create the translatewiki language portal [ ] Make sure that the category for the language is not marked as disabled [ ] Update the translatewiki language portal to indicate that the language is enabled [ ] Add the requester (and possibly other relevant users) to the translators list on the portal [ ] Enter the autonym in the Wikimedia Portals project [ ] Test language search in UniversalLanguageSelector and fix the search index (if needed) [ ] Enable machine translation and test that it works (if needed)
  • T436690: [[Wikimedia:Starterkit-starterkit-infobox-step-foundation/id]] translation issue
    • Task
    Foundation what is the context of this string/label? is it "Wikimedia Foundation", or like "a building foundation"? Documentation also not clear: "Label for step 1 in the infobox tool stepper bar. " ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=starterkit-starterkit-infobox-step-foundation&group=starterkit&language=id
  • T436357: Change the hardcoded word 'Wikipedia' in [[MediaWiki:Vector-night-mode-issue-reporting-preload-content]]
    • Task
    ``` <!-- Instructions Please describe how the dark mode colors are making Wikipedia difficult to read. Please include the section of the article where you found the issue. --> '''Issue Description''' ``` The word `Wikipedia` should be changed to `the wiki`. Something like `{{SITENAME}}` would be better but it cannot be used in the comment, so I think just `the wiki`. ---- **Message URL**: https://translatewiki.net/wiki/MediaWiki:Vector-night-mode-issue-reporting-preload-content https://gerrit.wikimedia.org/g/mediawiki/skins/Vector/+/dfc5937e8e5acb7d788d4f71621ef89fb412762f/i18n/en.json
  • T436319: Working pagelinks appear as redlinks
    • Task
    Translated [[ https://www.mediawiki.org/w/index.php?title=Project%3ASupport_desk&diff=8578329&oldid=8578062 | from the support desk ]]: == Page links with errors appear as red links. == When the page title is in Traditional Chinese, using a Simplified Chinese link causes the link to turn red, though clicking it works fine. Note: MediaWiki version 1.47.0-wmf.17.
  • T436094: Show IP: Better RTL support
    • Task
    ==== What is the problem? IPv6 addresses don't display correctly in RTL languages: {F100214617} ==== Environment **Wiki(s):** local docker MediaWiki 1.47.0-alpha (cbea8bf) 04:19, 26 August 2026. CheckUser 2.5 (26ff07a) 14:10, 25 August 2026.
  • T435117: Standardize Latin digits (0-9) for dates, times, and math calculations in Tulu Wikipedia (tcywiki)
    • Task
    ### Summary This task proposes updating the local configuration for the Tulu Wikipedia (tcywiki) to use Latin digits (0, 1, 2, 3, 4, 5, 6, 7, 8, 9) instead of Kannada digits (೦, ೧, ೨, ೩, ೪, ೫, ೬, ೭, ೮, ೯) for specific technical domains, specifically dates, times, page number and math calculations/equations. ### Motivation & Rationale While Kannada digits are part of the script's traditional representation, using them universally in technical contexts on MediaWiki creates significant friction: 1. Dates and Timestamps: Automated templates, infoboxes, and system-generated timestamps often break or display inconsistently when forced to handle non-Latin numeral systems, causing synchronization and parsing issues. 2. Math Calculations: Complex mathematical formulas, equations, and data tables become difficult to edit, maintain, and render accurately for editors and readers alike. 3. Search & Accessibility: Standardizing on Latin digits for numeric data improves search engine indexing, cross-platform data compatibility, and overall readability for users navigating technical content. ### Requested Changes * Update the default language settings/number formatting rules for Tulu Wikipedia (tcywiki) to utilize Latin digits for: * System dates and times. * Mathematical expressions and data variables. * Technical templates and infobox parameters where numeral consistency is critical. ### References / Community Discussion * Tulu Wikipedia Community Discussion Link: https://tcy.wikipedia.org/wiki/Special:Permalink/365394#Proposal:_Standardizing_Latin_Digits_for_Dates,_Times,_and_Math_Calculations_in_Tulu_Wikipedia
  • T434377: Rename "grant" to "scope" in MediaWiki
    • Task
    MediaWiki borrowed the concept of "grant" (bundle of permissions you can grant to an application to use on your behalf) from OAuth 1. OAuth 1 is largely extinct now, and OAuth 2 unhelpfully renamed the concept to "scope". We should probably bite the bullet and rename things: * the `$wgGrantPermissions` / `$wgGrantPermissionGroups` / `$wgGrantRiskGroups` configuration variables (needs B/C) * the `GrantPermissions` / `GrantPermissionGroups` / `GrantRiskGroups` fields in `extension.json` (needs B/C) * the `GrantsInfo` and `GrantsLocalization` classes / services and many of their methods * the ListGrants special page * the bot password UI, form handler, the `BotPassword::getGrants()` method, and some of the options / code of `createBotPassword.php` * maybe the `bp_grants` DB field (might not be worth it) * maybe a ton of message keys (might not be worth it) * a bunch of documentation ([[https://www.mediawiki.org/wiki/Manual:Grants|Manual:Grants]], [[https://www.mediawiki.org/wiki/Manual:Bot_passwords|Manual:Bot_passwords]], [[https://www.mediawiki.org/wiki/Manual:Bot_passwords_table|Manual:Bot_passwords_table]]...)
  • T433811: System message not translatable
    • Task
    Hello, The message [[ https://www.wikidata.org/wiki/MediaWiki:Setlabeldescriptionaliases-summary | Setlabeldescriptionaliases-summary ]] on the [[ https://www.wikidata.org/wiki/Special:SetLabelDescriptionAliases | Special:SetLabelDescriptionAliases ]] page is not available for translation on TranslateWiki: "You may have reached this special page because the item you tried to edit wasn't fully loaded for label/description edits to work there." [[ https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2019/03#Item_not_fully_loaded | Since 2019 ]], there have been several requests to translate this sentence into various languages. Could you please add it to the "Wikibase - Repo - User interface" translation group? Regards. —Eihel
  • T433742: Brand name translatewiki.net is all lower case
    • Task
    Please correct all incorrect souce message in English. Even at the start of a sentence, translatewiki.net should be all lower case.
  • T433645: show localized logo on portal headers
    • Task
    although [a localized project name](https://gerrit.wikimedia.org/r/plugins/gitiles/wikimedia/portals/+/refs/heads/master/src/common/templates/header-logo.handlebars#5) is supposed to be seen at the top, for some reason it is not the case, as observed across multiple projects & locales: | {F96557296} | {F96557624} |
  • T433410: Timestamp tooltip text order is reversed ("years ago 8") on RTL wikis with LTR interface language
    • Task
    When hovering over a timestamp generated by DiscussionTools on an RTL wiki (tested on arwiki and arzwiki), the tooltip text containing English characters and numbers is displayed in the wrong visual order due to bidirectional text rendering issues. Instead of showing "8 years ago", the tooltip visually displays "years ago 8". Steps to Reproduce: - Visit a discussion page on Arabic Wikipedia (e.g., User talk:Vermont). - https://ar.wikipedia.org/w/index.php?title=نقاش%20المستخدم:Vermont&uselang=en - Your interface language should be an LTR lang - Hover your cursor over a comment timestamp to trigger the title tooltip. {F96302019} ```lang=html <a href="https://ar.wikipedia.org/wiki/%D9%86%D9%82%D8%A7%D8%B4_%D8%A7%D9%84%D9%85%D8%B3%D8%AA%D8%AE%D8%AF%D9%85:Vermont#c-Bachounda-2018-03-24T17:08:00.000Z" class="ext-discussiontools-init-timestamplink" title="8 years ago" data-event-name="discussiontools.permalink-copied">17:08، 24 مارس 2018 (ت&nbsp;ع&nbsp;م)</a> ``` Expected Result: The tooltip should correctly read "8 years ago". I guess Wrapping the string with LRI (Left-to-Right Isolate, U+2066) at the beginning and PDI (Pop Directional Isolate, U+2069) at the end would force the browser to render the tooltip correctly as LTR.
  • T433036: [[MediaWiki:Userlogin-reauth-description/nb]] translation issue
    • Task
    I'm noticing the one parameter in this message, which I assume leads to "MediaWiki:Userlogin-reauth-description-link/nb", but it's not explicitly stated. If it is, it requires to be conjugated differently than English in many other languages. Shouldn't this be clarified? (It seems a little odd to split a message in two like this.) ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=userlogin-reauth-description&group=core&language=nb
  • T432820: [APNT] Fullwidth/halfwidth colons
    • Task
    **Parent task (please check)**: T432814 **Feature summary**: Make U+FF1A FULLWIDTH COLON somewhat useful **Use case(s)**: Chinese use U+FF1A FULLWIDTH COLON. So, that namespace separator U+003A COLON is not normal for us. For many input method engines it requires swtiching to ASCII/English/Latin mode. Currently Chinese Wikipedia has [[ https://zh.wikipedia.org/wiki/MediaWiki:Gadget-fullwidth-search-fix.js | a site gadget ]] to help, but that's indierct, and it does not fix red links. I notice that TitleMatcher::getNearMatchInternal does not work on fullwidth colons, probably because of namespaces. Try search for `Special：` on zhwiki. **Benefits** (why should this be implemented?): It would really benefit Chinese users because we type in and search for colons very frequently
  • T432819: [APNT] Middle dot normalization in title resolution
    • Task
    **Parent task (please check)**: T432814 **Feature summary**: When resolving titles with one of the listed characters, check the title substituting them with U+00B7 if the page is not found. * U+FF0E FULLWIDTH FULL STOP * U+2027 HYPHENATION POINT * (?) U+30FB KATAKANA MIDDLE DOT * (?) U+FF65 HALFWIDTH KATAKANA MIDDLE DOT * (?) U+002E FULL STOP * (?) U+2022 BULLET **Use case(s)**: [[ https://en.wikipedia.org/wiki/Middle_dot | Middle dot ]] ([[ https://zh.wikipedia.org/wiki/%E9%97%B4%E9%9A%94%E5%8F%B7 | zh ]]) is a common Chinese punctuator, but it's hard to input, and different people have different practices. - Chinese Wikipedia use U+00B7 MIDDLE DOT - U+2022, 2027, 30FB, FF0E, FF65 are blacklisted - [[ https://www.w3.org/TR/clreq/#indication_punctuation_marks | W3C Draft CLREQ advise ]] U+00B7 MIDDLE DOT - Taiwan Minstry of Education uses U+FF0E FULLWIDTH FULL STOP ([[ https://language.moe.gov.tw/001/Upload/FILES/SITE_CONTENT/M0001/HAU/h14.htm | example ]]) - Reportedly all dots I listed above are sometimes used. - My Gboard on Android has a big U+2022 in the puncuation panels. but if I want to type 00B7, I have to long-press U+002D HYPHEN-MINUS to get that. Before I found out, I was BULLETing everywhere. P.S. Resolving that in the search bar (during NFKC?) would be great, too. **Benefits**: Users searching for titles with middots.
  • T432544: Cite: reference-list items on RTL wikis should take each footnote's direction from its own content (mixed LTR/RTL bibliographies render broken)
    • Task
    **Steps to reproduce** On a right-to-left wiki (I'm on fa.wikipedia), open an article whose reference list mixes Persian and English sources. Some footnotes are written as plain `<ref>...</ref>` with the citation typed by hand — very common for English books and journals — and others use citation templates. A live example is the footnotes section of https://fa.wikipedia.org/wiki/ایران_صفوی — roughly half of them are hand-written English citations. A narrower and more demonstrative example has been created at https://fa.wikipedia.org/wiki/User:Huji/T432544 **What actually happens** Every item in the reference list (`ol.references > li`) inherits the page direction (`dir="rtl"`). So a footnote whose content is English gets laid out right-to-left: - the leading/trailing punctuation may end up on the wrong side (a citation that should read `Blake, Stephen P., ed. (2013), ...` may render with its comma and period displaced), and - the whole entry is right-aligned, so the footnote number and the ↑ backlink sit on the right while the Latin text starts on the left — visually disconnected and hard to read. **What I'd expect** Each footnote should be laid out according to the direction of //its own content//: an English citation LTR (number and text on the left), a Persian citation RTL — the way a mixed-language bibliography normally looks. This is essentially what the HTML `dir="auto"` attribute is for. **Why it matters** This isn't specific to Persian — it affects every RTL wiki (Arabic, Hebrew, Persian, Urdu, …). Citing foreign-language (usually English) sources is extremely common, and today those citations are noticeably broken in the reference list. An editor has no practical way to fix an individual hand-written `<ref>` other than manually inserting bidi control characters, which almost nobody does. While a `dir="ltr"` or `dir="rtl"` workaround exists, many times people import text and references from another wiki (e.g., form English Wikipedia to Persian Wikipedia) and manually adding the `dir` attributes is too much work and editors skip it. The proposed `dir="auto"` solution will eliminate the need for ltr or rtl values for the `dir` attribute of `ref` tags in most cases to be hard coded. **The subtle part (so whoever picks this up doesn't hit the same wall I did)** I prototyped a fix and there's one gotcha worth recording: - Putting `dir="auto"` on the whole `<li>` does **not** work, because the list item begins with the localized backlink label (on fa it's the accessibility text «پرش به بالا به:», i.e. "Jump up to:"). `dir="auto"` keys off the first strong character, so that Persian label makes an otherwise-English footnote resolve to RTL. It shows up specifically on references that are cited more than once (where the label is present). - Detecting direction from the **reference content** — the `.reference-text` span, which excludes the backlink label — gives the correct result. But the footnote number is the `<ol>`/`<li>` marker, so to also place the number on the correct side, the detected direction needs to land on the `<li>` itself (or the markup needs to be arranged so the backlink label doesn't participate in the auto-detection). I'll leave the exact implementation to the Cite maintainers — I mainly want the label-pollution gotcha on the record so a `dir="auto"`-on-`<li>` patch doesn't get shipped and then regress multiply-cited refs. **Current workarounds, and why I'm filing upstream** On fa.wikipedia we can make //template// citations behave by having our CS1 module emit `<cite dir="ltr">` and matching it in Common.css with `ol.references > li:has(cite[dir="ltr"])`. But hand-written `<ref>` tags emit no such marker, and CSS can't derive direction from content, so they can't be targeted that way. The only local fix that covers them is a few lines of site JavaScript adding `dir="auto"` to `.reference-text` — and one of our interface admins reasonably pushed back that a per-wiki JS workaround is the wrong place for this and it should be handled in the Cite extension. I agree, which is why I'm reporting it here. **Related** - T300053 (bidirectionality guidelines) - T375975 (reduce reliance on hidden direction marks in MediaWiki) - T38032 (reference number bidi isolation) Thanks! — Mamouri (fa.wikipedia)
  • T432431: Migrate LanguageLa grammar transformations to JSON
    • Task
    As discussed in T115218, MediaWiki already supports JSON-based grammar transformations in `languages/data/grammarTransformations`. `LanguageLa` still implements grammar transformations via `convertGrammar()` in `includes/languages/LanguageLa.php`. This task tracks migrating those grammar transformations to the JSON format and removing the PHP implementation where appropriate. Follow-up to T115218 @Nikerabbit suggested LanguageLa as one of the straightforward languages to migrate.
  • T432291: Add Izere (izr) to translatewiki.net
    • Task
    Requested at https://translatewiki.net/wiki/Support#Request_to_enable_Izere_[izr]_language Autonym: Izere ISO 639-3 code: izr References: * [[ https://commons.wikimedia.org/wiki/File:AMatiyu_12_-_Kushu_Kufas_Kufe_Rife%CC%B1_Adakunom_01.jpg | Matthew 12 - New Testament (aMatiyu 12 - Kushu Kufas Kufe Rife̱ Adakunom) ]]. * [[ https://commons.wikimedia.org/wiki/File:Kufas_ne_Kuzibir_Izere_kufe_Inoon_-_2_01.jpg | "Kufas ne Kuzibir Izere kufe Inoon - 2," a children Izere (izr) language learning booklet ]]. * [[ https://commons.wikimedia.org/wiki/File:Kuyis_Ikere_Ni_Izere_be_Niseng_ne_Itirik_01.jpg | "Kuyis Ikere Ni Izere be Niseng ne Itirik," an Izere (izr) language booklet ]]. * [[ https://commons.wikimedia.org/wiki/File:AMatiyu_12_-_Kushu_Kufas_Kufe_Rife%CC%B1_Adakunom_01.jpg | New Testament Bible in the Izere language ]] [x] Add to language-data([[https://github.com/wikimedia/language-data/pull/512|patch]]) -- [x] Run `src/util/ulsdata2json.php` before adding -- [x] Run `src/util/ulsdata2json.php` after adding [x] Add to translatewiki configuration([[https://gerrit.wikimedia.org/r/c/translatewiki/+/1321586|patch]]) [x] Deploy configuration to translatewiki [x] Add an entry to LocalNames/LocalNamesEn.php in the CLDR extension (if needed)([[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/cldr/+/1327190|patch]]) [x] Add jquery.ime keyboard (if needed)([[https://github.com/wikimedia/jquery.ime/pull/861|patch]]) -- [x] Add keyboard documentation. **Note: **: In terms of special characters, the language does have use the minus below diacritic, the acute and grave accents on vowel sounds. Here are the special characters in Izere: e̱, o̱, á, é, é̱, í, ó, ó̱, ú, à, è, è̱, ì, ò, ò̱, and ù. See [[ https://commons.wikimedia.org/wiki/File:Bo%CC%B1so%CC%B1p_Izere_-_Kufas_ne_Kuzibir_Izere_kufe_Inoon_-_2.jpg | here ]] for orthography. [x] Update jquery.uls and jquery.ime in the ULS extension [x] Deploy ULS to translatewiki [x] Create the translatewiki language portal [x] Make sure that the category for the language is not marked as disabled [x] Update the translatewiki language portal to indicate that the language is enabled [x] Add the requester (and possibly other relevant users) to the translators list on the portal [x] Enter the autonym in the Wikimedia Portals project [ ] Test language search in UniversalLanguageSelector and fix the search index (if needed) [ ] Enable machine translation and test that it works (if needed) See documentation on how to add a language to translatewiki: https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages#translatewiki
  • T432102: Update Interslavic translation
    • Task
    NS_SPECIAL => Specialna Translations of special pages will follow translatewiki
  • T432098: Bot for updating authors in en.json and qqq.json
    • Task
    Unlike translations to other languages, which are updated by the translatewiki bot along with adding translators to the author field in the files, the en and qqq files are created manually and without documenting the authors. I think it would be nice if it ran every few months (for example, before each version release). I'd be happy to hear your thoughts on this.
  • T428613: Remove Russian aliases for special pages and namespaces in Ukrainian
    • Task
    Per. this discussion: https://w.wiki/Qkbk The community has decided to abandon Russian aliases for namespaces and special pages. This will partially reverse the forced addition of aliases that was done in {T39314}.
  • T428378: Support locale-aware ordinal number formatting in Wikimedia Mobile Apps
    • Task
    Some app strings require ordinal numbers (e.g. "1st", "2nd", "3rd", etc.). Currently, translators may need to append ordinal suffixes directly in translations when numeric placeholders such as `%1$d` are used. This approach does not work for Azerbaijani and potentially other languages where ordinal suffixes depend on the number itself. For example, in Azerbaijani: - 1-ci - 3-cü - 6-cı - 9-cu A translator cannot reliably write a single suffix after a numeric placeholder because the correct form varies depending on the value. For example, The Year in Review feature contains [[ https://translatewiki.net/wiki/Wikimedia:Wikipedia-android-strings-year_in_review_slide_app_icon_body_unlock/en | strings ]] such as: ```We're glad Wikipedia was part of your %1$d! Unlock a special reward in your %2$d Year in Review...``` In Azerbaijani, this currently requires hardcoded ordinal suffixes in the translation, which only work for specific years and become grammatically incorrect for others. MediaWiki core already supports locale-aware ordinal formatting through grammarTransformations and #mediawiki-libs-leximorph. This allows languages such as Azerbaijani to generate the correct ordinal form automatically (T426082). However, Wikimedia Mobile Apps do not run in a MediaWiki environment and therefore cannot use GRAMMAR:ordinal directly.
  • T428286: Special:GlobalContributions ignores translations of Wikimedia override messages
    • Task
    The follwing three messages are defined as empty messages: * `checkuser-global-contributions-anon-tools` * `checkuser-global-contributions-ip-range-tools` * `checkuser-global-contributions-registered-user-tools` Overrides with `wikimedia-` prefix appear to be used instead, for overrides English source as well as translations appear to be available: * https://meta.wikimedia.org/wiki/MediaWiki:Wikimedia-checkuser-global-contributions-registered-user-tools/en * https://meta.wikimedia.org/wiki/MediaWiki:Wikimedia-checkuser-global-contributions-registered-user-tools/fr Special:GlobalContributions however displays only English message regardless of interface language: * https://meta.wikimedia.org/wiki/Special:GlobalContributions/Test_0001?uselang=en * https://meta.wikimedia.org/wiki/Special:GlobalContributions/Test_0001?uselang=fr
  • T428185: Change "Adds" in action=help to "Returns"
    • Task
    The word "Adds" is somewhat ambiguous which can make it difficult for users to understand its intended actions. Translators on translatewiki.net have already misinterpreted it in certain languages, translating it as "increase" or "put together". However these actions could simply involve GET and return. Translators there might never use "api.php?action=help" and therefore never realise their mistake. This issue only happens in messages containing "Adds". Messages with "add …" are fine. This phenomenon has been observed in Chinese and Japanese translations. See [[ https://translatewiki.net/w/i.php?title=Special%3ASearchTranslations&filter=&language=&query=adds | Translatewiki - Special:SearchTranslations ]] for other languages.
  • T428126: Add Sindhi (sd-sind) to translatewiki.net
    • Task
    Requested at https://translatewiki.net/wiki/Support?markasread=285911#Request_to_add_Sindhi_(Khudabadi)_on_translatewiki Autonym: 𑋝𑋡𑋟𑋐𑋢 (𑊻𑋩𑋣𑋏𑋠𑋔𑋠𑋏𑋢) Source: https://www.omniglot.com/writing/sindhi.htm ISO 639-3 code: sd-sind [x] Add to language-data ([[ https://github.com/wikimedia/language-data/pull/507 | patch ]]) -- [x] Run `src/util/ulsdata2json.php` before adding -- [x] Run `src/util/ulsdata2json.php` after adding [x] Add to translatewiki configuration ([[ https://gerrit.wikimedia.org/r/c/translatewiki/+/1302653 | patch ]]) [x] Deploy configuration to translatewiki [x] Add an entry to LocalNames/LocalNamesEn.php in the CLDR extension (if needed) [] Add jquery.ime keyboard (if needed) -- [] Add keyboard documentation [x] Update jquery.uls and jquery.ime in the ULS extension([[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UniversalLanguageSelector/+/1320297|patch]]) [] Deploy ULS to translatewiki [x] Create the translatewiki language portal [x] Make sure that the category for the language is not marked as disabled [x] Update the translatewiki language portal to indicate that the language is enabled [x] Add the requester (and possibly other relevant users) to the translators list on the portal [x] Enter the autonym in the Wikimedia Portals project [] Test language search in UniversalLanguageSelector and fix the search index (if needed) See documentation on how to add a language to translatewiki: https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages#translatewiki
  • T427735: Localize the Magic Word Invoke to Pashto
    • Task
    Localize the Magic Word Invoke to Pashto Extension:Scribunto /** Pashto (پښتو) */ $magicWords['ps'] = [ 'invoke' => [ 0, 'راغوښتل' ],
  • T426483: Add Pashto Translation for these NameSpaces
    • Task
    Please add Pashto translations for: - Draft: `گارليک` - Draft talk: `د_گارليک_خبرې_اترې` - Topic: `سکالو` - Project: `پروژه` - Project talk: `د_پروژې_خبرې_اترې` and also these Aliases: - WP: `وپ` - Rename `ځﺎﻧګړی` to `ځانګړی`
  • T426352: [[Wikimedia:Wikipedia-ios-reading-challenge-streak-of-days/en]] {{PLURAL}} issue
    • Task
    The singular version of this message is incorrect, containing the form "25 day" (instead of "25 days"). ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=wikipedia-ios-reading-challenge-streak-of-days&group=out-wikimedia-mobile-wikipedia-ios&language=ia
  • T426195: InvalidArgumentException: Invalid language code "' + variant + '"
    • Task
    ==== Error ==== * mwversion: 1.47.0-wmf.2 * timestamp: 2026-05-13T13:20:40.890Z * phpversion: `8.3.30` * reqId: `f043a66c-96c6-4d09-8106-aab40919a98f` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2026-05-12T13:20:40.890Z',to:'2026-05-13T13:23:50.618Z'))&_a=(query:(query_string:(query:'reqId:%22f043a66c-96c6-4d09-8106-aab40919a98f%22'))) | Find reqId in Logstash ]] ```name=normalized_message,lines=10 [{reqId}] {exception_url} InvalidArgumentException: Invalid language code "' + variant + '" ``` | Frame | Location | Call | -- | -- | -- | from | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Language/LanguageFactory.php#133 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Language/LanguageFactory.php(133) ]] | | #0 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Language/LanguageFactory.php#119 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Language/LanguageFactory.php(119) ]] | MediaWiki\Language\LanguageFactory->newFromCode(string) | #1 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/libs/ObjectCache/MapCacheLRU.php#261 | /srv/mediawiki/php-1.47.0-wmf.2/includes/libs/ObjectCache/MapCacheLRU.php(261) ]] | MediaWiki\Language\LanguageFactory->MediaWiki\Language\{closure}() | #2 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Language/LanguageFactory.php#116 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Language/LanguageFactory.php(116) ]] | Wikimedia\ObjectCache\MapCacheLRU->getWithSetCallback(string, Closure) | #3 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Language/LanguageFactory.php#93 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Language/LanguageFactory.php(93) ]] | MediaWiki\Language\LanguageFactory->getRawLanguage(string) | #4 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Parser/ParserCoreTagHooks.php#261 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Parser/ParserCoreTagHooks.php(261) ]] | MediaWiki\Language\LanguageFactory->getLanguage(string) | #5 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Parser/ParserCoreTagHooks.php#234 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Parser/ParserCoreTagHooks.php(234) ]] | MediaWiki\Parser\ParserCoreTagHooks->strictlyValidateBcp47Variant(string) | #6 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Parser/Parser.php#3994 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Parser/Parser.php(3994) ]] | MediaWiki\Parser\ParserCoreTagHooks->langconvert(string, array, MediaWiki\Parser\Parser, MediaWiki\Parser\PPFrame_Hash) | #7 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Parser/PPFrame_Hash.php#345 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Parser/PPFrame_Hash.php(345) ]] | MediaWiki\Parser\Parser->extensionSubstitution(array, MediaWiki\Parser\PPFrame_Hash, bool) | #8 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Parser/Parser.php#2879 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Parser/Parser.php(2879) ]] | MediaWiki\Parser\PPFrame_Hash->expand(MediaWiki\Parser\PPNode_Hash_Tree, int) | #9 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Parser/Parser.php#1500 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Parser/Parser.php(1500) ]] | MediaWiki\Parser\Parser->replaceVariables(string) | #10 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Parser/Parser.php#621 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Parser/Parser.php(621) ]] | MediaWiki\Parser\Parser->internalParse(string) | #11 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Content/JavaScriptContentHandler.php#126 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Content/JavaScriptContentHandler.php(126) ]] | MediaWiki\Parser\Parser->parse(string, MediaWiki\Page\PageIdentityValue, MediaWiki\Parser\ParserOptions, bool, bool, int) | #12 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Content/ContentHandler.php#1574 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Content/ContentHandler.php(1574) ]] | MediaWiki\Content\JavaScriptContentHandler->fillParserOutput(MediaWiki\Content\JavaScriptContent, MediaWiki\Content\Renderer\ContentParseParams, MediaWiki\Parser\ParserOutput) | #13 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Content/Renderer/ContentRenderer.php#62 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Content/Renderer/ContentRenderer.php(62) ]] | MediaWiki\Content\ContentHandler->getParserOutput(MediaWiki\Content\JavaScriptContent, MediaWiki\Content\Renderer\ContentParseParams) | #14 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Revision/RenderedRevision.php#246 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Revision/RenderedRevision.php(246) ]] | MediaWiki\Content\Renderer\ContentRenderer->getParserOutput(MediaWiki\Content\JavaScriptContent, MediaWiki\Page\PageIdentityValue, MediaWiki\Revision\RevisionStoreRecord, MediaWiki\Parser\ParserOptions, array) | #15 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Revision/RenderedRevision.php#219 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Revision/RenderedRevision.php(219) ]] | MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached(MediaWiki\Content\JavaScriptContent, array) | #16 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Revision/RevisionRenderer.php#226 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Revision/RevisionRenderer.php(226) ]] | MediaWiki\Revision\RenderedRevision->getSlotParserOutput(string, array) | #17 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Revision/RevisionRenderer.php#159 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Revision/RevisionRenderer.php(159) ]] | MediaWiki\Revision\RevisionRenderer->combineSlotOutput(MediaWiki\Revision\RenderedRevision, MediaWiki\Parser\ParserOptions, array) | #18 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Revision/RenderedRevision.php#182 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Revision/RenderedRevision.php(182) ]] | MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}(MediaWiki\Revision\RenderedRevision, array) | #19 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Page/ParserOutputAccess.php#593 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Page/ParserOutputAccess.php(593) ]] | MediaWiki\Revision\RenderedRevision->getRevisionParserOutput() | #20 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Page/ParserOutputAccess.php#508 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Page/ParserOutputAccess.php(508) ]] | MediaWiki\Page\ParserOutputAccess->renderRevision(MediaWiki\Page\WikiPage, MediaWiki\Parser\ParserOptions, MediaWiki\Revision\RevisionStoreRecord, array, null) | #21 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Content/ContentHandler.php#1341 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Content/ContentHandler.php(1341) ]] | MediaWiki\Page\ParserOutputAccess->getParserOutput(MediaWiki\Page\WikiPage, MediaWiki\Parser\ParserOptions, MediaWiki\Revision\RevisionStoreRecord, array) | #22 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CirrusSearch/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/BuildDocument/ParserOutputPageProperties.php#99 | /srv/mediawiki/php-1.47.0-wmf.2/extensions/CirrusSearch/includes/BuildDocument/ParserOutputPageProperties.php(99) ]] | MediaWiki\Content\ContentHandler->getParserOutputForIndexing(MediaWiki\Page\WikiPage, null, MediaWiki\Revision\RevisionStoreRecord) | #23 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/libs/ObjectCache/WANObjectCache.php#1830 | /srv/mediawiki/php-1.47.0-wmf.2/includes/libs/ObjectCache/WANObjectCache.php(1830) ]] | CirrusSearch\BuildDocument\ParserOutputPageProperties->CirrusSearch\BuildDocument\{closure}(bool, int, array, null, array) | #24 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/libs/ObjectCache/WANObjectCache.php#1640 | /srv/mediawiki/php-1.47.0-wmf.2/includes/libs/ObjectCache/WANObjectCache.php(1640) ]] | Wikimedia\ObjectCache\WANObjectCache->fetchOrRegenerate(string, int, Closure, array, array) | #25 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CirrusSearch/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/BuildDocument/ParserOutputPageProperties.php#90 | /srv/mediawiki/php-1.47.0-wmf.2/extensions/CirrusSearch/includes/BuildDocument/ParserOutputPageProperties.php(90) ]] | Wikimedia\ObjectCache\WANObjectCache->getWithSetCallback(string, int, Closure) | #26 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CirrusSearch/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/BuildDocument/ParserOutputPageProperties.php#49 | /srv/mediawiki/php-1.47.0-wmf.2/extensions/CirrusSearch/includes/BuildDocument/ParserOutputPageProperties.php(49) ]] | CirrusSearch\BuildDocument\ParserOutputPageProperties->finalizeReal(Elastica\Document, MediaWiki\Page\WikiPage, CirrusSearch\CirrusSearch, MediaWiki\Revision\RevisionStoreRecord) | #27 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CirrusSearch/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/BuildDocument/BuildDocument.php#203 | /srv/mediawiki/php-1.47.0-wmf.2/extensions/CirrusSearch/includes/BuildDocument/BuildDocument.php(203) ]] | CirrusSearch\BuildDocument\ParserOutputPageProperties->finalize(Elastica\Document, MediaWiki\Title\Title, MediaWiki\Revision\RevisionStoreRecord) | #28 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CirrusSearch/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Api/QueryBuildDocument.php#139 | /srv/mediawiki/php-1.47.0-wmf.2/extensions/CirrusSearch/includes/Api/QueryBuildDocument.php(139) ]] | CirrusSearch\BuildDocument\BuildDocument->finalize(Elastica\Document, bool, MediaWiki\Revision\RevisionStoreRecord) | #29 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CirrusSearch/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Api/QueryBuildDocument.php#48 | /srv/mediawiki/php-1.47.0-wmf.2/extensions/CirrusSearch/includes/Api/QueryBuildDocument.php(48) ]] | CirrusSearch\Api\QueryBuildDocument->doExecute(CirrusSearch\CirrusSearch) | #30 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/PoolCounter/PoolCounterWorkViaCallback.php#68 | /srv/mediawiki/php-1.47.0-wmf.2/includes/PoolCounter/PoolCounterWorkViaCallback.php(68) ]] | CirrusSearch\Api\QueryBuildDocument->CirrusSearch\Api\{closure}() | #31 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/PoolCounter/PoolCounterWork.php#159 | /srv/mediawiki/php-1.47.0-wmf.2/includes/PoolCounter/PoolCounterWork.php(159) ]] | MediaWiki\PoolCounter\PoolCounterWorkViaCallback->doWork() | #32 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CirrusSearch/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Api/QueryBuildDocument.php#55 | /srv/mediawiki/php-1.47.0-wmf.2/extensions/CirrusSearch/includes/Api/QueryBuildDocument.php(55) ]] | MediaWiki\PoolCounter\PoolCounterWork->execute() | #33 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Api/ApiQuery.php#735 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Api/ApiQuery.php(735) ]] | CirrusSearch\Api\QueryBuildDocument->execute() | #34 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Api/ApiMain.php#2045 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Api/ApiMain.php(2045) ]] | MediaWiki\Api\ApiQuery->execute() | #35 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Api/ApiMain.php#949 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Api/ApiMain.php(949) ]] | MediaWiki\Api\ApiMain->executeAction() | #36 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Api/ApiMain.php#920 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Api/ApiMain.php(920) ]] | MediaWiki\Api\ApiMain->executeActionWithErrorHandling() | #37 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/Api/ApiEntryPoint.php#138 | /srv/mediawiki/php-1.47.0-wmf.2/includes/Api/ApiEntryPoint.php(138) ]] | MediaWiki\Api\ApiMain->execute() | #38 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/includes/MediaWikiEntryPoint.php#180 | /srv/mediawiki/php-1.47.0-wmf.2/includes/MediaWikiEntryPoint.php(180) ]] | MediaWiki\Api\ApiEntryPoint->execute() | #39 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/refs/heads/wmf/1.47.0-wmf.2/api.php#30 | /srv/mediawiki/php-1.47.0-wmf.2/api.php(30) ]] | MediaWiki\MediaWikiEntryPoint->run() | #40 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+blame/refs/heads/master/w/api.php#3 | /srv/mediawiki/w/api.php(3) ]] | require(string) | #41 | {main} | ==== Impact ==== Certain pages on banwikisource and sourceswiki cannot be search-indexed nor rendered (`https://ban.wikisource.org/w/index.php?curid=33833` exhibits the same error). ==== Notes ====
  • T425866: Cannot use U+180E (MONGOLIAN VOWEL SEPARATOR) in page title
    • Task
    In Mongolian script, `U+180E (MONGOLIAN VOWEL SEPARATOR)` is used within a word, which is not a word boundary. Converting them to space is not correct. According to English Wikipedia, > A separated final form of vowels a or e (᠎ᠠ ‑a/‑e) is common, and can appear at the end of a word stem, or suffix. This form requires a final-shaped preceding letter, and a word-internal gap in between. This gap can be transliterated with a hyphen. ... The presence or lack of a separated a or e can also indicate differences in meaning between different words (compare ᠬᠠᠷ᠎ᠠ qar‑a 'black' with ᠬᠠᠷᠠ qara 'to look'). **Steps to replicate the issue** (include links if applicable): * Go to ᠬᠠᠷ᠎ᠠ in English Wiktionary * It redirects to [[ https://en.wiktionary.org/wiki/%E1%A0%AC%E1%A0%A0%E1%A0%B7_%E1%A0%A0 | ᠬᠠᠷ_ᠠ ]] (note the space) Also, * Create a page with U+180E in title * The character in title will be converted to _ (space)
  • T425599: [[MediaWiki:Logentry-pagecheckout-checkin/en]] edit error
    • Task
    Given the previous meanings of "check in" (make available) and "check out" (lock for editing) in the Page Checkout extension, I think this should say: ``` $1 {{GENDER:$2|unlocked}} page $3 that was locked by user $4 ``` (Sorry for leaving this issue unlabelled. I can't find a label for the Page Checkout extension.) ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=logentry-pagecheckout-checkin&group=ext-pagecheckout&language=ia
  • T423753: Extra space after the namespace-title separator
    • Task
    **Steps to replicate the issue** (include links if applicable): * Go to a talk page on fawiki [[https://fa.wikipedia.org/wiki/%D8%A8%D8%AD%D8%AB_%D8%A7%D9%84%DA%AF%D9%88:%D8%AC%D8%B9%D8%A8%D9%87_%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA_%D9%87%D9%86%D8%B1%D9%85%D9%86%D8%AF_%D9%85%D9%88%D8%B3%DB%8C%D9%82%DB%8C|fa:بحث الگو:جعبه اطلاعات هنرمند موسیقی]] * Go to a similar talk page on enwiki such as [[https://en.wikipedia.org/wiki/Template_talk:Infobox_musical_artist|en:Template talk:Infobox musical artist]] **What happens?**: On English Wikipedia, the : between `Template talk` and `Infobox musical artist` has no trailing space. On Persian Wikipedia, it does. **What should have happened instead?**: Layout should be consistent for both wikis **Other information** (browser name/version, screenshots, etc.): The space is added by CSS in [[https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/a1c3379d1fdc5e9fc186885ac10834eaeff12924/modules/init.styles/dt.init.pageframe.less#14|/modules/init.styles/dt.init.pageframe.less]] of #discussiontools but it is unclear why it is not applied the same in different wikis. Moreover, the space is not really helpful to the Persian readers and should not be applied in the first place.
  • T423735: Adding Southern Uzbek (uzs) to Translatewiki
    • Task
    Requested at https://translatewiki.net/wiki/Support/Archive/2026/04#Adding_Southern_Uzbek_to_Translatewiki Autonym: اۉزبېکچه [x] Add to language-data ([[ https://github.com/wikimedia/language-data/pull/506 | patch ]]) -- [x] Run `src/util/ulsdata2json.php` before adding -- [x] Run `src/util/ulsdata2json.php` after adding [x] Add to translatewiki configuration([[https://gerrit.wikimedia.org/r/c/translatewiki/+/1311544|patch]]) [x] Deploy configuration to translatewiki [x] Add a Messages*.php file with `$rtl = true;` (if needed)([[https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1326389|patch]]) [ ] Deploy the Messages*.php file with `$rtl = true;` to translatewiki [x] Add an entry to LocalNames/LocalNamesEn.php in the CLDR extension (if needed)([[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/cldr/+/1327204|patch]]) [ ] Add jquery.ime keyboard (if needed) -- [ ] Add keyboard documentation [x] Update jquery.uls and jquery.ime in the ULS extension([[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UniversalLanguageSelector/+/1320297|patch]]) [ ] Deploy ULS to translatewiki [x] Create the translatewiki language portal [x] Make sure that the category for the language is not marked as disabled [x] Update the translatewiki language portal to indicate that the language is enabled [x] Add the requester (and possibly other relevant users) to the translators list on the portal [x] Enter the autonym in the Wikimedia Portals project [ ] Test language search in UniversalLanguageSelector and fix the search index (if needed) [ ] Enable machine translation and test that it works (if needed) See documentation on how to add a language to translatewiki: https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages#translatewiki
  • T423665: Add Sindhi (sd-deva) to translatewiki.net
    • Task
    Requested at https://translatewiki.net/wiki/Support#Request_to_Add_Sindhi_(Devangari)_on_translatewiki Autonym: सिंधी (देवनागरी), Source: Government of India's CIIL Sindhi Devanagari Primer: https://ciil.gov.in/primers/Sindhi_(Devanagari)_Primer.pdf ISO 639-3 code: sd-deva [x] Add to language-data ([[ https://github.com/wikimedia/language-data/pull/501 | patch ]]) -- [x] Run `src/util/ulsdata2json.php` before adding -- [x] Run `src/util/ulsdata2json.php` after adding [x] Add to translatewiki configuration ([[ https://gerrit.wikimedia.org/r/c/translatewiki/+/1287997 | patch ]]) [x] Deploy configuration to translatewiki [x] Add an entry to LocalNames/LocalNamesEn.php in the CLDR extension (if needed) [x] Add jquery.ime keyboard (if needed) -- [] Add keyboard documentation [x] Update jquery.uls and jquery.ime in the ULS extension([[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UniversalLanguageSelector/+/1320297|patch]]) [x] Deploy ULS to translatewiki [x] Create the translatewiki language portal [x] Make sure that the category for the language is not marked as disabled [x] Update the translatewiki language portal to indicate that the language is enabled [x] Add the requester (and possibly other relevant users) to the translators list on the portal [x] Enter the autonym in the Wikimedia Portals project [] Test language search in UniversalLanguageSelector and fix the search index (if needed) See documentation on how to add a language to translatewiki: https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages#translatewiki
  • T423029: Broken i18n messages whatlinkshere-whatlinkshere-filter
    • Task
    **Steps to replicate the issue** (include links if applicable): * Go to https://en.wikipedia.org/wiki/Special:WhatLinksHere/Main_Page * Use `$( '#mw-content-text > div.mw-htmlform-ooui-wrapper.oo-ui-layout.oo-ui-panelLayout.oo-ui-panelLayout-padded.oo-ui-panelLayout-framed > form > fieldset > div > div > div:nth-child(3) > fieldset > legend > span.oo-ui-labelElement-label' )` on the console to find it. **What happens?**: `<span class="oo-ui-labelElement-label">⧼whatlinkshere-whatlinkshere-filter⧽</span>` **What should have happened instead?**: Have a proper label. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.): The legend is hidden with CSS so it's not immediately obvious that it is broken. Could have been broken for years... could be from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/876385 or even earlier.
  • T422836: Make the "Experimental edit check. For testing purposes only." message localizable
    • Task
    Related to T422835. The "Experimental edit check. For testing purposes only." message in #editcheck is not localizable. When it is (accidentally) displayed to real users, they might be confused even more. Especially if an English-only message appears in a RTL wiki (like arwiki), as it does now. Can we make this message localizable?
  • T422789: No bdi isolation for temporary account names
    • Task
    ==== What is the problem? On Special:Block for temporary accounts, the temp usernames aren't consistently displayed in RTL languages. The probably need a `<bdi>` tag. {F75397667} ==== Environment **Wiki(s):** https://test.wikipedia.org MediaWiki 1.46.0-wmf.23 (964f1ae) 13:32, 8 April 2026. CheckUser 2.5 (c322d21) 17:48, 7 April 2026.
  • T422007: Proposal: Edit toolbar icons for Arabic Wikipedia VisualEditor
    • Task
    Currently, the VisualEditor toolbar in the Arabic Wikipedia uses Latin letters for text styling icons (e.g., "B" for Bold, "I" for Italic, or "A" for text size). This is inconsistent with the Arabic script and can be counter-intuitive for users who edit primarily in Arabic. I have designed Arabic script versions of{F74721157} these icons (e.g., using "ب" for Bold/عريض) to improve the user experience for the Arabic-speaking community. The proposed icons can be viewed here: [ https://commons.wikimedia.org/wiki/Category:Arabic_Wikipedia_OOUI_icons ]. I have also attached a screenshot for further clarification, along with a CSS snippet in my account for testing purposes. [ https://ar.wikipedia.org/wiki/%D9%85%D8%B3%D8%AA%D8%AE%D8%AF%D9%85:RiadS99/common.css ]
  • T421906: [[MediaWiki:Pagecheckout-ui-workflows-inspector-activity-page-checkin-property-user-help/en]] probable incorrect text
    • Task
    The text of this message is: “For whom page will be checked out”. But the word “checkin” in the tile suggests that the text should be: “For whom page will be checked in”. This is corroborated by the overall context of the message and by the fact that the message with the same title with “-checkin-” replaced by “-checkout-” is identical to this one. Looks like they shouldn't be identical. In addition, both of these messages would read better with a definite article: “For whom the page will be checked in/out”. (These messages are related to the PageCheckout extension. I'm sorry, I could not find an appropriate label, so someone else will have to label this issue.) ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=pagecheckout-ui-workflows-inspector-activity-page-checkin-property-user-help&group=ext-pagecheckout&language=ia
  • T420614: CJK date display format is not correctly localized.
    • Task
    **Steps to replicate the issue:** Set the locale to Chinese, Japanese, or Korean. View any wikidata attribute of date content , such as [[https://www.wikidata.org/wiki/Q52#P10768 | P10768 of Q52]] **What happens and what should have happened instead?:** Actual displayed value: `D M YYYY` Expected display value: `YYYY年M月D日` (Chinese and Japanese) `YYYY년 M월 D일` (Korean) Actual displayed value: `M月 YYYY` (Chinese and Japanese) `M월 YYYY` (Korean) Expected display value: `YYYY年M月` (Chinese and Japanese) `YYYY년 M월` (Korean)
  • T420560: Image metadata gets wrong encoding if non-ASCII
    • Task
    **Steps to replicate the issue** (include links if applicable): * See current [[https://commons.wikimedia.org/wiki/File:Gent-Zenit_(14).jpg#metadata | File:Gent-Zenit_(14).jpg#metadata]] or perform [[https://commons.wikimedia.org/w/api.php?action=query&format=json&formatversion=2&prop=imageinfo&iiprop=metadata&iilimit=max&&titles=File:Gent-Zenit_(14).jpg | API query ]] **What happens?**: The Cyrillic parts of metadata get jammed, for instance CityDest becomes Ãåíò instead of Гент and further on. **What should have happened instead?**: Гент should remain Гент, not Ãåíò and further on. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): Wikimedia Commons Adobe Photoshop Lightroom 5.7 (Windows) as metadata producer for that particular part of metadata for that particular image **Other information** (browser name/version, screenshots, etc.): Tried to fix the issue over https://www.metadata2go.com/edit-metadata but after uploading the "fixed" version to Commons Cyrillic parts became ???? looking. The issue first reported [[https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%A4%D0%BE%D1%80%D1%83%D0%BC/%D0%A2%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9#%D0%9A%D0%BE%D0%B4%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0 | at Russian tech-forum]], later reported at [[https://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#Cyrillic_image_metadata_gets_broken | Commons:Graphics village pump]] As of now it is not known what software - if any - could be used to fix such issue manually and keep the right result after uploading.
  • T419012: Temporary account icon not flipped in RTL for Vector 2010 in personal tools menu
    • Task
    ==== What is the problem? Looking at the temporary account icon/avatar on Vector 2022 in the personal tools menu, I see the left half of it shaded, the opposite side to when looking at it in LTR. LTR: {F72503541} RTL: {F72503190} This is not the case in Vector Legacy. LTR: {F72503570} RTL: {F72503192} So far, I haven't seen this happening in other places where the temporary account icon appears, but it seems possible. ==== Environment **Wiki(s):** https://en.wikipedia.beta.wmcloud.org MediaWiki 1.46.0-alpha (544c7ed) 07:34, 4 March 2026.
  • T419011: Temporary account names not displayed correctly in RTL in personal tools menu
    • Task
    ==== What is the problem? How the personal tools menu and grey bar looks like in Farsi on Vector 2022: {F72502783} And in Vector Legacy: {F72502785} This probably also affects other skins. ==== Environment **Wiki(s):** https://en.wikipedia.beta.wmcloud.org MediaWiki 1.46.0-alpha (544c7ed) 07:34, 4 March 2026.
  • T417782: Add (or fix) pre-reform Russian support to {{#time: j xg
    • Task
    On November 2025, using this parser function with language code "ru-old" was result to month name rendered in pre-1917 Russian spelling (iюля, not июля). https://ru.wikipedia.org/w/index.php?diff=150192414 here is a diff, in November 2025 ruwiki user says it works. But now this is broken and "ru-old" code returns month name in modern Russian. Also, the correct international code for this spelling is ru-petr1708 , so this code should be supported too (now it's completely unsupported and returns English monthname). Correct old Russian monthnames in genitive grammatical case is: января, февраля, марта, апрѣля, маія, іюня, іюля, августа, сентября, октября, ноября, декабря.
  • T417727: Deprecate and remove wfPercent()
    • Task
    wfPercent() has been in MediaWiki since 2005 (rSVN10163 / be977a75d7b3fd55), and I think it makes sense to deprecate and remove it for several reasons. It is **hardly ever used**, with only one current use within [[https://www.mediawiki.org/wiki/Stable_interface_policy#Definition_of_the_stable_interface|Wikimedia maintained code]]: in ParserTestPrinter, since rSVN10164 (68871fa25dbe1aa3). The other known uses are in: - #MediaWiki-extensions-Editcount , since rSVN10165 (7b39583594235c51) - ~~[[https://www.mediawiki.org/wiki/Manual:DeleteImageMemcached.php|deleteImageMemcached.php]], since rSVN10963 (8949a076eb6eeb3d)~~ (file deleted in eb11a00a1e15bec1) - ~~[[https://www.mediawiki.org/wiki/Manual:Profileinfo.php|profileinfo.php]], since rSVN29759 (972b0afa76d11d6e)~~ (file deleted in 0da1ecfd89ec87af) - [[https://www.mediawiki.org/wiki/Extension:EditCountNeue|EditCountNeue extension]] It is **not internationalized**. In user-visible output such as that generated by the extensions, users likely expect the percent sign to be used as is customary in their language (after or before the number, with or without a space, or even a different form of the symbol, as in Persian). This is in addition to issues with number formatting in general. Its **valid use cases are not documented**. Different use cases may support or justify different rounding methods. As an example, a setup utility might always round down the completion percentage, to not show 100% until completely done, or might scale values in (0%, 100%) to [0.5%, 99.5%] before rounding to nearest, ties to odd, to indicate progress earlier. They may also justify different sets of parameters in the API, with separate parameters for numerator and denominator of a fraction being one alternative choice. The few remaining uses are **trivial to replace** while maintaining existing levels of functionality. All known callers use the defaults of `acc: 2, round: true`. If the percent sign is added separately, round() would likely suffice. There is a rounding difference: [[https://www.php.net/manual/en/function.sprintf.php|sprintf()]] with %f rounds the exact value, including any floating-point error, ties to even, while [[https://www.php.net/manual/en/function.round.php|round()]] pre-rounds to 15 significant digits (according to a [[https://wiki.php.net/rfc/rounding|2008 RFC]]) and rounds ties away from zero by default. However, it probably doesn't matter in these instances.
  • T416737: AccountVanishRequests not using local internationalization log summary
    • Task
    * After an account is automatically approved for vanishing, AccountVanishRequests forces the English log summary "This user vanish request has been automatically approved" across wikis. * This happens even when we have the [[ https://translatewiki.net/w/i.php?title=Special%3ATranslate&showMessage=globalvanishrequest-autoapprove-public-note&group=ext-centralauth-user&language=ur&filter=&optional=1&action=translate | log summary translated on translatewiki]] **What should have happened instead?**: The log summary should appear in the local language wiki. Ideally because the message is translated on translatewiki or that MediaWiki:Globalvanishrequest-autoapprove-public-note exists locally with the string. Links: [[ https://ar.wikipedia.org/wiki/%D8%AE%D8%A7%D8%B5:%D8%B3%D8%AC%D9%84/AccountVanishRequests | on Arabic Wikipedia ]]
  • T415897: [[Wikimedia:Wikipedia-android-strings-patroller diff tooltip one/fr]] translation issue
    • Task
    More context is needed: the English string is of ambiguous meaning. "Damage predicts if an edit causes damage" is tautological. ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=wikipedia-android-strings-patroller_diff_tooltip_one&group=out-wikimedia-mobile-wikipedia-android-strings&language=fr
  • T415576: Fix inconsistency in Table of Contents localization
    • Task
    In Parsoid, the table of contents is localized (and language-converted) during post processing. The SectionMetadata of the canonical Parsoid output has ascii digits and un-language-converted text. In the legacy parser, the table of contents has digits localized immediately upon creation, and the language conversion is done on the contents just before the Parser exists. So effectively, the SectionMetadata is always fully localized. Special pages use the legacy parser convention as well (fully localized SectionMetadata). It would be more convenient, especially as the legacy parser is deprecated, to move toward the Parsoid convention of localizing the table of contents during post processing, or at least marking the SectionMetadata in some way to indicate whether or not localization has been performed. This is complicated somewhat by the fact that language converter state is stored implicitly and globally: we need to language-convert the text in the legacy parser immediately after parsing the main article body in order to (re)use the implicit global language converter state, in particular any article specific rules that apply to section titles. Parsoid parses language converter rules but does not evaluate them until postprocessing, so in order to appropriately use the implicit global language converter state it needs to localize the TOC at this time as well. Special pages generally use MW interface messages for table of contents section labels, which are generated specifically for a given variant and do not need to be language-converted. Special pages *do* need to localize the numbers in the section labels however.
  • T415087: itwiki: Special:AccountRecovery has incomplete/awkward Italian localisation (form + confirmation email)
    • Task
    On Italian Wikipedia, the Special:AccountRecovery form shows localisation issues in both the web form (Speciale:AccountRecovery) and the confirmation email that is sent after submission. **Steps to replicate the issue** (include links if applicable): * Visit https://it.wikipedia.org/wiki/Speciale:AccountRecovery * Observe the UI strings in the form * Fill and submit the form * Observe the confirmation email content **What happens?**: * The email confirmation is mostly english, but the expiry sentence contains italian: “The link will expire in 15 minuti.” * Some labels are either poorly translated or not translated at all **What should have happened instead?**: Either show the confirmation email entirely in italian or english.
  • T414825: Unnecessary numbers are shown after some timestamps
    • Task
    Some human timestamp messages in Hebrew are now showing unnecessary numbers after the words. For example, "1 day ago" is "לפני יום אחד (1)", so it says both the word "one" and the number "1". "Two months" ago is "לפני חודשיים (2)", where "חודשיים" already means "two months" and the number "2" is redundant. The possible reason for the problem is this update in cldr: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/cldr/+/392a30ca2e7ede32b10b698b423e4896bb103501%5E%21/#F47 It should be fixed upstream because I'm quite sure that it's wrong for all software. Until that happens, it would be great to fix it locally in MediaWiki. I'd do it myself, but I've never tried doing it for this kind of data, so I may need assistance.
  • T414806: [BUG] close-all-tabs-confirmation-number needs proper plural support
    • Task
    The message close-all-tabs-confirmation-number is currently `Close all $1 tabs?` Given that this is iOS, I'm not sure that plural can be used here. In many languages, the translation of "tabs" will be different according to the number.
  • T414272: Wikibase-rc-wikibase-edit-title doesn't show localized value for {{WBREPONAME}} in Wachlist
    • Task
    **Steps to replicate the issue** (include links if applicable): * Go to Special:Watchlist on fawiki * Notice the legends in the "list of abbreviations" box (see screenshot below) {F71496609} **What happens?**: The word "Wikidata" is shown in English **What should have happened instead?**: The localized version, "ویکی‌داده" should be shown. **Other information** (browser name/version, screenshots, etc.): The message that defines this is `wikibase-rc-wikibase-edit-title` and in [[https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/ddaf8af7295ffa80cb2ff26649afdf5af9a7b367/client/i18n/fa.json|./client/i18n/fa.json]] it is defined as "ویرایش در {{WBREPONAME}}". On [[https://fa.wikipedia.org/wiki/%D9%85%D8%AF%DB%8C%D8%A7%D9%88%DB%8C%DA%A9%DB%8C:Wikibase-rc-wikibase-edit-title|fa:MediaWiki:Wikibase-rc-wikibase-edit-title]] it does show in localized form. It is only in the Watchlist that it doesn't. This bug smells like T395973 which was found to be a parser related issue and ultimately addressed by @cscott
  • T414212: Lay out featured languages using flexbox
    • Task
    [[https://meta.wikimedia.org/w/index.php?title=Www.wikipedia.org_template/temp&diff=3768908|Back in 2012]], a two-column layout was added for the top 10 languages on devices with 240px < width ≤ 480px, using a `float:left` hack. (This was expanded to three columns in 2017 in rWPORe12a299a164723e428efaf95c33ffa52ab52c829.) It’s understandable that `float:left` was used at the time, since [[https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/display-inside#css.properties.display.flex|no browsers other than Internet Explorer used to support flexbox]] yet (and IE also used to support it in v8+ only, and with vendor prefixing). Since 2015, all browsers have supported flexbox without vendor prefixing (the last one to come to the party was Safari), so there’s no reason not to switch to that. It has several benefits: * Better right-to-left support. If the user requests the site in a right-to-left language such as Hebrew, the `<html>` element gets a `dir="rtl"` attribute, but the hardcoded `float:left` means that the first language appears at the top left, not at the top right as the directionality would request. A flexbox uses the natural text directionality, so the first language will automatically at the top left in LTR languages and at the top right in RTL languages. * Simplify CSS. Currently there is another rule for width ≤ 240px, which switches to a one-column mode. A flexbox layout would automatically switch to one-column mode if there isn’t enough space, so we could get rid of a breakpoint. * Bring back two-column mode. On a 241px wide screen, three columns are too many. A flexbox would automatically switch from three-column mode to two-column mode depending on the screen width, before switching to one-column mode. If someone uses a decade-old browser that doesn’t support flexbox yet (and is able to access our sites somehow), it gracefully degrades to a single-column layout, which should be fine. Current layout: | 480px | 242px | 236px | | ----------- | ----------- | ----------- | | {F71481909} | {F71481911} | {F71481910} |
  • T413327: Bidirectional text in edit window causes text to be rendered outside of the editor area
    • Task
    **Steps to replicate the issue** (include links if applicable): Open https://en.wikipedia.org/w/index.php?title=Lake_Parishan&action=edit&oldid=1316188978, scroll to the bottom **What happens?**: Depending on the skin, with and without CodeMirror: {F71173326} {F71173329} {F71173356} **What should have happened instead?**: The first letter of the two paragraphs ("T") should have been rendered fully inside the edit window. **Other information** (browser name/version, screenshots, etc.): Screenshots are from a recent Firefox version.
  • T413103: Translation issue about message Wikimedia:Lexica-frontend-session.detail.glossQuotes
    • Task
    Can this message please be documented in the qqq language file. I have no idea what a "gloss quote" is. ---- Message URL: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=lexica-frontend-session.detail.glossQuotes&group=lexica-frontend&language=nl
  • T412851: Fallback languages' namespace names should automatically be namespace aliases for the languages using them as fallback
    • Task
    **Steps to replicate the issue** (include links if applicable): As seen in {T409892}: * Have a language that has a non-English `$fallback` language defined in its MessagesXxx.php file, but doesn't have the namespace names defined * Create a wiki in that language, and make various edits. Notably, add some images and categories, and post some talk page messages. * Then add namespace definitions for that language. **What happens?**: * Before the language has namespace names defined, it will use the namespace names from the fallback language (in T409892, that was Indonesian) * When namespace names are added for the language in question, the old links that use the namespace names from the fallback language stop working. **What should have happened instead?**: * The namespace names from all fallback languages should automatically be included as namespace aliases, so that links will continue working. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.):
  • T412839: [[MediaWiki:Wikibaselexeme-grammatical-features-input-placeholder/lb]] translation issue
    • Task
    The message currently reads "For example: normative, comparative, past tense..." and if I understood correctly, it is supposed to give examples for grammatical features. But is "normative" really a grammatical feature? I have my doubts. Shouldn't this word be replaced by something that is more easily recognized as a grammatical feature? ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=wikibaselexeme-grammatical-features-input-placeholder&group=ext-wikibaselexeme-user&language=lb
  • T412584: Cat-a-lot: RTL support issues on Persian Wikipedia (And other RTL wikis)
    • Task
    After [[ https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-Cat-a-lot.js/translating#Persian | translating ]] and testing `Gadget-Cat-a-lot.js` on Persian Wikipedia, I have identified several RTL compatibility issues that significantly affect the user interface layout and usability in RTL wikis such as Persian, Arabic, and Hebrew Wikipedias. While the gadget correctly detects RTL using `is_rtl = $( 'body' ).hasClass( 'rtl' )`, this detection is not consistently applied to CSS properties that require directional adjustments. ## Issue #1: **Problem:** Hard-coded `float: right` causes UI elements to float to the right side even in RTL layouts, where they should float to the left side for proper visual alignment. Impact: Help link appears on wrong side of the interface **Line 229** - Help link: ```javascript style: 'float:right', ``` **Line 410** - Lock control: ```javascript .css({ 'margin-left': '.7em', 'font-size': '.9em; float:right' }) ``` **Line 2145** - Counter display: ```javascript .css( { 'float': 'right', fontSize: '75%' } ) ``` ### Recommended Fix: ```javascript // Option 1: style: is_rtl ? 'float:left' : 'float:right' // Option 2: style: 'float:inline-end' ``` --- ## Issue #2: **Problem:** Properties like `margin-left`, `padding-left` do not flip in RTL layouts, causing incorrect spacing and visual misalignment. Impact: Text and controls have wrong spacing in RTL Line 222 - Label styling: ```javascript .css( { fontWeight: 'bold', marginLeft: '.7em' } ) ``` Line 410 - Lock control margin: ```javascript .css({ 'margin-left': '.7em', 'font-size': '.9em; float:right' }) ``` Line 419 - Category input padding: ```javascript .css('padding-left', '0.5em') ``` **Line 445** - Mode dropdown margin: ```javascript .css('margin-left', '0.5em') ``` **Line 449** - Target category padding: ```javascript .css('padding-left', '0.5em') ``` ### Recommended Fix: ```javascript // Option 1: .css(is_rtl ? { marginRight: '.7em' } : { marginLeft: '.7em' }) // Option 2: .css({ 'margin-inline-start': '.7em' }) .css({ 'padding-inline-start': '0.5em' }) ``` --- ## Issue #3: **Problem:** Hard-coded `left` and `right` positioning properties do not adapt to RTL layouts, causing the dialog container to appear in the wrong position or extend beyond viewport boundaries. **Lines 528-533** - Container initial positioning: ```javascript $container.css({ top: pos.top, left: pos.left, // Should be 'right' in RTL right: 0, // Should be 'left' in RTL bottom: 0, position: 'fixed', 'max-height': '100vh' }); ``` **Lines 2256-2259** - Boundary correction: ```javascript $container.css({ right: 0, // Should be 'left' in RTL bottom: 0 }); ``` ### Recommended Fix: ```javascript const leftProp = is_rtl ? 'right' : 'left'; const rightProp = is_rtl ? 'left' : 'right'; $container.css({ top: pos.top, [leftProp]: pos.left, [rightProp]: 0, bottom: 0, position: 'fixed', 'max-height': '100vh' }); $container.css( is_rtl ? { left: 0, bottom: 0 } : { right: 0, bottom: 0 } ); ```
  • T411561: Words in wrong order on lines with RTL page titles temporarily on Special:Watchlist
    • Task
    **Steps to replicate the issue**: * Add this page to your watchlist, temporarily: https://en.wikipedia.org/w/index.php?title=%D8%B9%D9%8A%D8%AF_%D8%A7%D9%84%D9%81%D8%B7%D8%B1&redirect=no * Visit https://en.wikipedia.org/w/index.php?title=Special:EditWatchlist&namespace=0&offset=0|Wi&limit=500 (this should show the end of the listing, if yours is long) **What happens?**: * `90 عيد الفطر (talk|history) days left in your watchlist` {F70826028} **What should have happened instead?**: * `عيد الفطر (talk|history) 90 days left in your watchlist` Originally reported at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Bug_with_RTL_titles_in_watchlist
  • T410830: CommunityConfiguration feature names do not support localization
    • Task
    **Steps to replicate the issue** (include links if applicable): * Enable a CommunityConfig feature, such as how Extension:AbuseFilter [[https://gerrit.wikimedia.org/g/mediawiki/extensions/AbuseFilter/+/e45f241cda261849edcc9f34b6345f27d753bcc9/extension.json#358|does it with BlockedDomain]] * Set your wiki to have a different default language than English * Try to localize the phrase "BlockedDomain" **What happens?**: There is no way to localize it. You can localize the name of CommunityConfiguration special page, but not the name of the specific feature. For instane, if your wiki contnet language is French, then `[[Special:CommunityConfiguration/BlockedDomain]]` becomes `[[Spécial:Configuration_communautaire/BlockedDomain]]` and there is no way for you to localize the `BlockedDomain` part, in the same manner that you can localize the namespace ("Spécial") and the Special Page name ("Configuration_communautaire"). **What should have happened instead?**: It should be allowed for wikis to localize the name of community config features through an alias. This helps with the readability and understandability of the URLs, especially in wikis whose content language is not a Latin-based language (think Arabic, Japanese, etc.) In the case of the BlockedDomain use case, this will require changes both to #mediawiki-extensions-communityconfiguration and #abusefilter codebases.
  • T410287: Implement plural support in all recovery code messages that may refer to one or more recovery codes
    • Task
    While we have a few i18n messages that exclusively refer to 1 recovery code (for example, when you need to "enter a recovery code"), we have many messages that may be hard coded to use the plural version. We have `$wgOATHRecoveryCodesCount`, defaulting to `10`, but this could be set to 1 by a sysadmin... We should make sure all references to "recovery codes" have proper plural support when there may be 1 or more, depending on site config.
  • T410074: Split translations in the CheckUser repository into groups
    • Task
    ## Summary In the CheckUser repo, separate out the translations related to temp accounts, UIC, SI, and potentially other user interfaces. Goal: make it easier for translators to focus on a specific group of the most needed translations and get it to 100%. ##Background - Currently, with about 400 messages in the repo, messages for different UIs are mixed. It's challenging for translators to make sure that 100% of the most relevant and needed ones are done. For example, after the temp accounts deployment on eswiki, the onboarding dialog wasn't translated, and community members needed to check each message in the large repo to see which ones should be prioritized. - As a side-effect, this will also provide the translations with a few separate rewards for reaching each milestone: 100% translations for UIC, 100% translations for SI, etc. ##User story > Do: > - Explain who the user is, what they want to achieve and why (e.g. As a Steward, I want to automatically see all temp account IPs, in order to effectively mitigate on-wiki abuse) As a translator, I want to be able to focus on translating the UI for Special:Investigate, SI, UIC, temp accounts etc. ## Technical notes > Do: > - Provide detailed technical notes > - Delete this section if it is not relevant to the task ## Acceptance criteria > Identify how we will know the task is done. Make these checkboxes specific, so that QA can meaningfully review completion. - [ ] Component code updated - [ ] Relevant component code is tested - [ ] Documentation updated
  • T409892: Broken namespaces in the Buginese Wikipedia
    • Task
    **Steps to replicate the issue** (include links if applicable): * Load https://bug.wikipedia.org/w/index.php?title=Atong&oldid=192058 * * **What happens?**: The image and category are shown as plain wikitext red links. **What should have happened instead?**: The image should be shown as an image and the category should be shown as a category, like they used to be: https://web.archive.org/web/20250217185605/http://bug.wikipedia.org/wiki/Atong **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.): This is presumably triggered by the changes in T389916 - Buginese falls back to Indonesian, so MediaWiki used Indonesian for the namespace names. Namespace translations were added for Buginese, now the Indonesian ones don't work.
  • T409797: Some lego messages in the Activity screen in the Wikipedia Android app
    • Task
    Some messages in the Activity screen in the Wikipedia Android app are "lego": They are concatenated in runtime in a way that is grammatically incorrect in some languages. More specifically, they show the number separately from the text. This assumes that the number is in the beginning of the sentence, as in English, but this is wrong in many languages. To make things even more complicated, in some languages, there is different order for different numbers: for example, in Arabic, 1 comes after the word, 2 is embedded into the word, so the number itself shouldn't be mentioned at all, and most other numbers come before the word. It's understandable that designers want to show a nice-looking card withe numbers, icons, and charts, but in this case, the text should be just generic and separated from the numbers, and it shouldn't try to form sentences. So instead of saying "{{PLURAL|edit this month|edits this month}}", in a way that matches the number, it can simply say "edits this month", and not use PLURAL at all. As far as I can tell, if the design shows the number distinctly from the text, it looks OK in English, and in all languages. The problematic messages that I could find are: * activity_tab_impact_edits_this_month * activity_tab_impact_edits_last_month * activity_tab_impact_total_edits * activity_tab_impact_thanks * activity_tab_impact_recent_activity_edits * activity_tab_impact_recent_activity_views However, there may be more that I missed. I recommend removing PLURAL support from all of them and coming up with generic labels that can work with any number.
  • T409416: Detect non-English file titles and prompt user to specify their language in UploadWizard
    • Task
    **Feature summary** (what you would like to be able to do and where): It would be great if functionality was added to detect the language of the file-title (when one has entered text into the title input box and then left the focus/clicked on another input box) as already done on other sites where language detection seems to work fairly quickly. It would not need to detect the language and just check whether the title is English. I strongly oppose facilitating and encouraging non-English titles that would degrade understandably/accessibility and usefulness of Commons by letting the user specify the language without language detection. Then, if it detected the title is not English, it would show a box asking the user to specify the language, similar to the language box for file captions on Wikidata. By the way, if it detected gibberish / some undescriptive IDs or numbers like Fig1345643, it could also display a info/warning note that the file title should be useful/descriptive. The upload should not be made more complicated and time-intensive/laborious so I suggest that for an upload of multiple files at once all non-English titles are automatically detected and the input-box for the titles-language is shown at the top where the user needs to specify it just once (in just a second or so as it has autocomplete) and it's then set for all the files detected and marked as having non-English titles in the files the user is uploading. That filename language could be set via structured data and/or the linked categories. **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): Having the file-title language specified could for example aid in or facilitate the creation of captions (e.g. at least for those files that are used in English Wikipedia or some other Wikipedia not of the same language as the title representing broader relevance). In categories like [[ https://commons.wikimedia.org/wiki/Category:Microscopic_images_relating_to_biology | Category:Microscopic images relating to biology ]] the image itself isn't always (even usually) self-explanatory so if I can't read the title, I don't know what that file shows. One idea for the future – and it could be decades from now – would be to display the caption of the file in your language instead or above the original file title if 1. the title is not in your language and 2. a file caption in your language exists. There may also be other ways this could be addressed for better accessibility / understandability / localization / usefulness. Created a bot task request to set categories of [[ https://commons.wikimedia.org/wiki/Category:Files_by_language_of_non-English_file_title | Category:Files by language of non-English file title]] at the Commons bot work requests page [[https://commons.wikimedia.org/wiki/Commons:Bots/Work_requests#Populating_Category:Files_by_language_of_non-English_file_title | here]]. For future uploads, it would be best if this was addressed at the time of upload, at the source. **Benefits** (why should this be implemented?): The earlier this is done, the easier it would be to at some point have quite complete and reliable metadata about filetitle language which again could be used to make Commons more multilingual in the sense of better understandable to Commons and Websearch users across the world. See use-cases for further and more info on benefits.
  • T408336: getHumanTimestamp is not aware of date change past midnight
    • Task
    **Steps to replicate the issue** (include links if applicable): With timezone set to UTC: ```php $t1 = new MWTimestamp('20251025235900'); $t2 = new MWTimestamp('20251027000000'); $lang->getHumanTimestamp($t1, $t2); ``` **What happens?**: `"Yesterday at 23:59"` **What should have happened instead?**: `"Saturday at 23:59"` **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.):
  • T408151: Change some or all accesskey messages in core to capital letters
    • Task
    `accesskey-*` messages in core are all written as lowercase letters: `e`, `l`, `s`, etc. See the whole list at https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/languages/i18n/nontranslatable/en.json As far as I can see, in Firefox, these keys work as Alt+Shift+//letter//, and in Chrome, they work as both Alt+//letter// and Alt+Shift+//letter//. So in Firefox, it's always with Shift anyway and in Chrome, it's optionally with Shift. In the English Wikipedia, MediaWiki:Accesskey-pt-watchlist was changed from `l` to `L`. I agree that this is more readable, because `L` is clearly `L` and not `I` in all fonts. This made me think that at least this message should be changed in core, too, because it's equally useful on all wikis and not just the English Wikipedia. And perhaps all of them should be changed to capital letters? These refer specifically to labels of keyboard keys, and as far as I know, most keyboards show uppercase Latin letters and not lowercase ones? The only ones that could be problematic in this regard are `I`, which could be confused with `1` or `l` and `O`, which could be confused with `0`, so maybe they can stay lowercase. Any other thoughts? It's probably easy to do, but perhaps I'm missing something. I am a relatively minor user of those shortcuts: I often use Alt+Shift+D to delete and Alt+Shift+E to edit, but I don't use the rest
  • T407693: Santali map labels are rendered as boxes
    • Task
    **Steps to replicate the issue** (include links if applicable): * Open https://maps.wikimedia.org/?uselang=sat#6/19.456/78.091 * * **What happens?**: Labels in Santali are rendered as boxes Screenshot: {F66759488} **What should have happened instead?**: Labels in Santali should be legible **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.): Probably needs a font such as Noto Sans Ol Chiki
  • T407653: Messages such as acct_creation_throttle_hit and wikimedia-acct_creation_throttle_hit are hard to translate
    • Task
    ==== Motivation These two related messages are hard to translate: [[https://translatewiki.net/wiki/MediaWiki:Acct_creation_throttle_hit/en|acct_creation_throttle_hit]] and [[https://translatewiki.net/wiki/MediaWiki:Wikimedia-acct_creation_throttle_hit/en|wikimedia-acct_creation_throttle_hit]]. The reason is that they use the word "last" and append the output of the `formatDuration()` function in the Language class, which is something like "8 seconds", "1 day", "3 years", etc. This works in English because the word "last" is the same, no matter what time is used, but in many languages the word "last" would be different, and the words for the time would be different, too. ==== Acceptance criteria [] Update message [[https://translatewiki.net/wiki/MediaWiki:Acct_creation_throttle_hit/en|acct_creation_throttle_hit]] to: ``` Account creation is temporarily restricted because visitors from this IP address have exceeded the number of account creations currently allowed. Please try again later. Limits on account creation: * 1 account every 10 minutes * 6 accounts every 24 hours ``` [] Update message [[https://translatewiki.net/wiki/MediaWiki:Wikimedia-acct_creation_throttle_hit/en|wikimedia-acct_creation_throttle_hit]] to: ``` Account creation is temporarily restricted because visitors from this IP address have exceeded the number of account creations currently allowed. Please try again later. Limits on account creation: * 1 account every 10 minutes * 6 accounts every 24 hours If you are at an event where contributing to Wikimedia projects is the focus, please see [[https://meta.wikimedia.org/wiki/Mass_account_creation#Requesting_temporary_lift_of_IP_cap|Requesting temporary lift of IP cap]] to help resolve this issue. ```
  • T406997: Localize extension namespaces for Pashto
    • Task
    Please localize these namespaces for Pashto (language code `ps`) - MediaWiki core -- MediaWiki = مېډياويکي -- MediaWiki_talk: د مېډياويکي خبرې اترې - Extension:TimedMediaHandler -- TimedText = مهال‌ليک -- TimedText_talk = د مهال‌ليک خبرې اترې - Extension:Scribunto -- Module = چلنوال -- Module_talk = د چلنوال خبرې اترې - Extension:CampaignEvents -- Event = پېښه -- Event_talk= د پېښې خبرې اترې
  • T405682: Host and automate Wikidata language code cleanup bot in Wikimedia cloud
    • Task
    **Background** [[https://gitlab.wikimedia.org/amire80/scriptology/-/tree/main/cleanup-wikidata-language-code | This Python script]] automates the cleanup of deprecated language codes (e.g., kr) from Wikidata items. It deletes or moves labels, descriptions, and aliases based on comparisons with fallback and related languages. The script uses the Pywikibot framework to process each item and logs cases it skips due to data inconsistencies or ambiguity to a CSV file for manual review. A previous attempt to run this script (as described in T394877) was unsuccessful: it took ~6 hours to update ~2,000 items out of ~500,000 items for the kr language code. At that speed, completing the full set would take ~1,400 hours (~2 months). To find a more sustainable approach, it was advised to improve the script’s efficiency (currently it performs multiple edits per item) and host it in Wikimedia Cloud Services. There is another task in progress to improve the cleanup process: T403097 **Tasks** [] Host the [[ https://gitlab.wikimedia.org/amire80/scriptology/-/tree/main/cleanup-wikidata-language-code. | bot script ]] in [[ https://wikitech.wikimedia.org/wiki/Help:Cloud_Services_introduction | Wikimedia’s Cloud Services infrastructure ]]. [] Request bot permissions on Wikidata. [] Improve the existing bot script for efficiency (currently it updates the same entries multiple times). [] Set up a cron job to allow the bot to run automatically. [] Ensure proper hosting and monitoring of the bot.
  • T404534: WikiLambda messages from ZLabelsBlock.vue don't seem to be used elsewhere
    • Task
    The file resources/ext.wikilambda.edit/components/main-types/ZLabelsBlock.vue was removed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/926432. It used some messages that don't seem to be used anywhere now: # wikilambda-metadata-labels-table-label # wikilambda-metadata-language-column # wikilambda-metadata-label-column # wikilambda-metadata-aka-column # wikilambda-editor-removeitem # wikilambda-metadata-fewer-languages # wikilambda-metadata-all-languages # wikilambda-metadata-hide-languages # wikilambda-metadata-show-languages If there are indeed not used anywhere, they should be deleted from en.json.
  • T404120: Improve documentation of the REST API messages
    • Task
    According to [[ https://www.mediawiki.org/wiki/Help:System_message | the conventions about writing system messages ]], all messages must have clear and relevant documentation in qqq.json. It is helpful to translators, and it is also useful to other developers who need to understand how messages are used. At the moment, many of the REST API messages have practically no qqq documentation. Many of them just repeat the English text of the message, which is completely useless. REST API messages should probably be documented similarly to the action API messages. For the action API help messages, translatewiki has several templates that describe what kind of message it is: action, error, example, parameter, etc. You can see a list of those templates at https://translatewiki.net/wiki/Category:MediaWiki_API_Message_Documentation_Templates . Because these messages are somewhat repetitive, the templates are often enough, but if any more information is needed about a particular message, it can be just written as additional text in qqq. The REST API should probably use a similar system. I know very little about the REST API, so I cannot offer it myself. I'll be happy to work with the REST API developers to come up with a grouping pattern and with writing the necessary templates.
  • T403891: MediaWiki:Wikieditor-toolbar-help-content-signaturetimestamp-syntax cannot be edited as it gets substituted with personal signature
    • Task
    MediaWiki:Wikieditor-toolbar-help-content-signaturetimestamp-syntax can't be edited because it contains code that is expanded when saved. You need to replace this message with what is done in MediaWiki:Discussiontools-signature-prefix for the Discussiontools extension. steps to reproduce: 1. open MediaWiki:Wikieditor-toolbar-help-content-signaturetimestamp-syntax on any wiki 2. click to Create button 3. click to Save Button Instead `--~~~~` will be saved you signature It is assumed that the code that will be substituted during saving will not be used in the system message
  • T403858: nonsensical GENDER in [[MediaWiki:Simple-tasks-notif-message-with-due-date/en]]
    • Task
    Since $1 is the task description, using it for GENDER makes no sense. (Sorry, but I cannot find an adequate project tag for this issue. This message is part of the [Simple Tasks extension](https://www.mediawiki.org/wiki/Extension:SimpleTasks).) ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=simple-tasks-notif-message-with-due-date&group=ext-simpletasks&language=ia
  • T402288: [[Wikimedia:Iabot-registeredplaceholder/en]] documentation needed
    • Task
    It is unclear if the example input "-3 months" needs to be translated, or must be left untranslated. Either way, this should be documented. If it must be left untranslated, then a <code> tag should be probably be used instead of quotes. ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=iabot-registeredplaceholder&group=internetarchivebot&language=nl
  • T402286: [[Wikimedia:Iabot-autoacquireheader/en]] grammar mistake
    • Task
    "All of the criteria" is plural, so "is met" should be "are met". (one criterion, two criteria) ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=iabot-autoacquireheader&group=internetarchivebot&language=nl
  • T401943: i18n: [clearyourcache] Incorrect message
    • Task
    **Steps to replicate the issue** (include links if applicable): * Lookup [clearyourcache] in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/languages/i18n/en.json | / core / refs/heads/master / . / languages / i18n / en.json ]] or in [[ https://global-search.toolforge.org/?q=*&regex=1&namespaces=8&title=Clearyourcache | a Global Search]] **What happens?**: * They're giving the incorrect keyboard shortcuts. `clearyourcache` returns: * on en-wiki: > **Note:** After saving, you have to bypass your browser's cache to see the changes. **Google Chrome, Firefox, Microsoft Edge and Safari**: Hold down the {{key press|Shift}} key and click the ‘‘Reload’’ toolbar button. For details and instructions about other browsers, see [[Wikipedia:Bypass your cache]]. * on commons: ``` ``` * on mediawiki: ``` ``` * in core: > "clearyourcache": "**Note:** After publishing, you may have to bypass your browser's cache to see the changes.\n* **Firefox / Safari:** Hold Shift while clicking Reload, or press either //Ctrl-F5// or //Ctrl-R// (//⌘-R// on a Mac)\n* **Google Chrome: **Press //Ctrl-Shift-R //(//⌘-Shift-R// on a Mac)\n*** Edge: **Hold //Ctrl// while clicking Refresh, or press //Ctrl-F5//.", ```"clearyourcache": "<strong>Note:</strong> After publishing, you may have to bypass your browser's cache to see the changes.\n* <strong>Firefox / Safari:</strong> Hold <em>Shift</em> while clicking <em>Reload</em>, or press either <em>Ctrl-F5</em> or <em>Ctrl-R</em> (<em>⌘-R</em> on a Mac)\n* <strong>Google Chrome:</strong> Press <em>Ctrl-Shift-R</em> (<em>⌘-Shift-R</em> on a Mac)\n* <strong>Edge:</strong> Hold <em>Ctrl</em> while clicking <em>Refresh</em>, or press <em>Ctrl-F5</em>.",``` {F65751480} **What should have happened instead?**: * Correct keyboard shortcut for Empty cache and Hard refresh/reload (Safari calls it: Reload page from origin) keyboard shortcut is: (I confirmed all the shortcuts personally, even Edge for macOS!) # Chrome → Windows `Ctrl-Shift-R` or `Shift-F5` [[ https://support.google.com/chrome/answer/157179?hl=en&co=GENIE.Platform%3DDesktop#zippy=%2Ctab-window-shortcuts%2Cgoogle-chrome-feature-shortcuts%2Caddress-bar-shortcuts%2Cwebpage-shortcuts:~:text=Reload%20the%20current%20page%2C%20ignoring,F5%20or%20Ctrl%20%2B%20Shift%20%2B%20r | ref ]] → macOS `⌘Command-⇧Shift-R` or `⌘Command-⇧Shift` and click Refresh [[ https://support.google.com/chrome/answer/157179?hl=en&co=GENIE.Platform%3DDesktop#zippy=%2Ctab-window-shortcuts%2Cgoogle-chrome-feature-shortcuts%2Caddress-bar-shortcuts%2Cwebpage-shortcuts:~:text=Reload%20your%20current,%E2%8C%98%20%2B%20Shift%20%2B%20r | ref ]] # Safari → (Safari not supported on Windows) → macOS `⌘Command-⌥Option-R` # Firefox → Windows `Ctrl-Shift-R` or `Ctrl-F5` [[ URL | name ]] → macOS `⌘Command-⇧Shift-R` # Edge → Windows `Ctrl-Shift-R` or `Ctrl-F5` → macOS `⌘Command-Shift-R` It should be sorted in order of browser usage: [[ https://en.wikipedia.org/wiki/Usage_share_of_web_browsers | Usage share of web browsers ]] {F65751400} **So the correct `clearyourcache` is:** ```"clearyourcache": "<strong>Note:</strong> After publishing, you may have to bypass your browser's cache to see the changes.\n* <strong>Google Chrome / Firefox / Edge:</strong> Press <em>Ctrl-Shift-R</em> (<em>⌘Command-Shift-R</em> on a Mac)\n* <strong>Safari:</strong> Hold <em>`⌘Command-⌥Option-R`</em>.",``` > "clearyourcache": "**Note:** After publishing, you may have to bypass your browser's cache to see the changes.\n* **Google Chrome / Firefox / Edge: **Press `Ctrl-Shift-R` (`⌘Command-Shift-R` on a Mac)\n* **Safari: **Hold `⌘Command-⌥Option-R`.", **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): macOS 15.5 Chrome Version 139.0.7258.66 (Official Build) (arm64) for macOS Safari Version 18.5 (20621.2.5.11.8) for macOS Edge 139.0.3405.86 for macOS Firefox **Other information** (browser name/version, screenshots, etc.): @Jdforrester-WMF: maybe you'll be interested as [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/85f717aab290f0fb160f12f3680d119e0ce5ba71%5E%21/languages/i18n/en.json | you made the last commit ]] on even saying `This message is already very long;` Maybe this can shorten it more?
  • T401476: AlphaSwap: An LLM-based proper name transliteration tool for Wikidata items
    • Task
    Currently, Wikidata includes a lot of items around people. Most of these items do not have labels in multiple languages and scripts. Using rule-based transliteration systems such as the Universal Script Converter Extension of MediaWiki does not usually solve the problem as it does not cover all the languages and as there are a lot of complex ways of doing transliterations that cannot be supported by rules. With the new hype of LLMs, we believe that this problem can be solved. In this project, we create a transliteration tool for proper names based on a language model hosted on Hugging Face and fine-tuned using a Wikidata-based SPARQL-generated dataset.
  • T401385: Rename language code "ro-md" from "Moldavian" to "Moldovan Romanian"
    • Task
    Hello, language code "ro-md" currently displays "Moldavian". This makes little sense, considering 1. "Moldavian" is an outdated spelling of "Moldovan", which fell into disuse after Moldova's independence, so in any case it should be replaced by the modern spelling; 2. We already have "mo" for "Moldovan" anyway, so this current arrangement produces two duplicates with different spelling, when both codes serve different purposes. Just like for instance "en-ca" displays "Canadian English", I suggest this language code display "Moldovan Romanian". Please do not hestitate to write for any doubts or further explanations needed.
  • T401055: Mistake in declination of months in Russian in mobile application
    • Task
    ru: В мобильном приложении Википедии, в игре «Что произошло в этот день», в заголовках страниц с вопросами есть проблема с правильным падежом на русском языке. Сейчас отображается, например, «3 август», «3 июль», тогда как должно быть «3 августа», «3 июля» и т. д. en: In the Wikipedia mobile app, in the game "What happened on this day", there is an issue with the correct grammatical case in Russian in the question page headers. Currently, it shows dates like "3 август" or "3 июль", whereas it should be "3 августа", "3 июля", and so on. screenshot: https://i.ibb.co/G4BX5MGH/photo-2025-08-03-06-45-28.jpg
  • T400578: Improve the process for initializing a message bundle
    • Task
    From my experience with testing Message bundles, one of the biggest inconveniences was creating the bundle page, setting its content model, and naming it. The content model has to be "Translatable message bundle". As far as I can see, there is no way to create a page that has this content model by default. Any page that is created as wikitext can be changed to "Translatable message bundle", although if the page is blank or if the JSON syntax is invalid, changing the content model will fail with the error "Invalid message bundle: Error while parsing the JSON: Syntax error". It's good that this validation exists, but it would be even better if editors could create it as JSON from the start and then use the JSON editor's own validation. Furthermore, there is the issue of naming the page. The best naming practice I can think of at the moment, with the current configuration, is to put the message bundle in the Module namespace and to append a standardized suffix. I've been using "/i18n" till now, but it can be something else. However, if a page is //created// in the Module namespace, its initial content model is "Scribunto module", so the page cannot even be published because valid JSON is not valid Lua, and the Lua editor doesn't allow publishing pages with Lua syntax errors. The workaround I've been using till now is to create the page in my user space, change its content model, and then move it to the Module namespace. This workaround is quite cumbersome, however, The solutions I can think of are: # Automatically set the "Translatable message bundle" content model on new pages in the Module namespace if they have a certain suffix (can be "/i18n" or something else). # Create a new namespace for message bundles and set new pages in it to "Translatable message bundle" by default. I'm open to other suggestions.
  • T400058: Split most used messages to separate i18n file
    • Task
    The "most used" or "most important" list of messages is useful for languages that start their journey in the Wikimedia world. It is also used by the Language committee as one of the criteria for checking that a language is ready for "graduating" from the Incubator. It includes messages, mostly from core MediaWiki and also from some skins and extensions, which are most frequently seen by users, for the most central wiki reading and editing tasks: page editing, logging in, categories, talk pages, language switching, etc. Before 2015, it was generated by gathering statistics. However, some of those statistics were bringing up messages that are frequently loaded for technical reasons, but aren't actually seen by a lot of users. In addition, they were shown in a random order, which is not great for translators. So since 2015, that list was curated manually, mostly by @amire80, @jhsoby, and @Nemo_bis. The translatewiki message group for it uses a special format—a plain list of message keys, which duplicates the keys that already appear in json files. This makes maintenance somewhat inconvenient, because message keys sometimes get changed or deleted, and this has to be done in more than one place. It is proposed to move away from this text file format and store the most important messages as JSON files mapped to message groups. The actual steps to doing it will be discussed in the comments to this task. A proposed transition plan by @Amire80 (other suggestions are welcome): [ ] Create a group of the most important messages within core. The name is flexible: "Main", "Most important", etc. [ ] Create similar groups in the other extensions that are currently included in "Most important". (I've already discussed this with @Lydia_Pintscher about Wikibase, for example, and she supported it. I'm not sure that she remembers because it was three or four years ago.) [ ] Create an aggregate group that includes all the "Most used" groups in core and extensions. [ ] Delete the "Most important" group from translatewiki.
  • T399554: Prepare a UV project for localization on translatewiki.net
    • Task
    Since translatewiki.net is a common practice for translating gadgets and extensions for mediawiki, it is necessary that the gadget meets the required preparation: * https://translatewiki.net/wiki/Translating:New_project * https://translatewiki.net/wiki/Setup_of_a_new_project * https://translatewiki.net/wiki/Translating:Localisation_for_developers Current strings: https://gitlab.wikimedia.org/repos/10nm/ultraviolet/-/tree/dev/src/localization == Roadmap [] Convert files for localization to one of the supported formats [] ... [] Create a Phabricator task for #translatewiki.net team
  • T399553: Allow to setup a path to JSON config and Preference page
    • Task
    Now installing the gadget is only possible with a single path to the configuration and settings page: * `{NS_PROJECT}:Ultraviolet/configuration.json` * `{NS_PROJECT}:Ultraviolet/Preferences` Since different language projects have completely different schemes for creating pages for gadgets, and some may not have one at all, the inability to configure the path to settings and configuration does not allow adaptive deployment of a gadget in a local project. In my opinion, the path to the configuration should be specified in the variable that is defined when calling the gadget. And the path to the settings is already inside the configuration itself.
  • T399445: Move language nrm to nrf
    • Task
    Wikimedia misuses the `nrm` code ([[https://en.wikipedia.org/wiki/Narom_language|Narom]], spoken in Malaysia) to mean [[https://en.wikipedia.org/wiki/Norman_language|Norman]] (spoken in France and the Channel Islands). While not a perfect match, the language code `nrf` (for Guernésiais & Jèrriais) is a better match, and we should move the existing translations into `nrm` to `nrf`. Related tasks: * {T25216} * {T337125}
  • T399285: Set canonical special page names as primary aliases in Chinese
    • Task
    In the commit 9352436fe1fa7df0be030324e6ae54d7b4460a17, MediaWiki core has been changed to use the canonical (i.e. English) special page aliases as the primary Chinese special page aliases, when site language is set to "zh" rather than "zh-*". This task is aimed to tracking relevant changes in other repositories. Some Chinese translation improvements might be introduced in the patches. Extensions which defined their own special page aliases: - [X] AbuseFilter - [X] AccountInfo - [] (pending) AchievementBadges - [X] Adiutor - [] (pending) AdManager - [X] AdminLinks - [X] Analytics - [X] ApiFeatureUsage - [X] ApprovedRevs - [X] ArticleFeedbackv5 - [X] ArticlePlaceholder - [X] ArticleRatings - [] Athena - [X] BatchUserRights - [X] BetaFeatures - [] BibManager - [X] BlockInactive - [X] BlogPage - [] (pending) BlueSpiceAbout - [] BlueSpiceBookshelf - [] BlueSpiceCategoryManager - [] BlueSpiceConfigManager - [] BlueSpiceDashboards - [] BlueSpiceDistributionConnector - [] BlueSpiceExpiry - [] BlueSpiceExtendedFilelist - [] BlueSpiceExtendedSearch - [] BlueSpiceExtendedStatistics - [] BlueSpiceFlaggedRevsConnector - [X] BlueSpiceFoundation - [] BlueSpiceGroupManager - [] BlueSpiceInstanceStatus - [] BlueSpiceInterWikiLinks - [] BlueSpiceMatomoConnector - [] BlueSpiceNamespaceCSS - [] BlueSpiceNamespaceManager - [] BlueSpicePageAccess - [] BlueSpicePageAssignments - [] BlueSpicePageTemplates - [] BlueSpicePermissionManager - [] BlueSpicePrivacy - [] BlueSpiceRating - [] BlueSpiceReaders - [] BlueSpiceReminder - [] BlueSpiceRSSFeeder - [] BlueSpiceSocial - [] BlueSpiceSocialBlog - [] BlueSpiceSocialProfile - [] BlueSpiceSocialTags - [] BlueSpiceSocialTopics - [] BlueSpiceSocialWikiPage - [] BlueSpiceTranslationTransfer - [] BlueSpiceUniversalExport - [] BlueSpiceUserManager - [] BlueSpiceWikiExplorer - [] BlueSpiceWikiFarm - [X] BulkBlock - [X] CampaignEvents - [X] Cargo - [] CategoryExplorer - [X] CategoryTree - [X] CentralAuth - [X] CentralNotice - [] (pending) Challenge - [X] ChangeAuthor - [X] CheckUser - [X] CIForms - [] CiteDrawer - [X] CiteThisPage - [] CloneDiff - [x] CloseWikis - [] CognitiveProcessDesigner - [] CollabPads - [] Collection - [X] Commentbox - [] Comments - [] CommunityConfiguration - [] CommunityRequests - [] ConfigManager - [X] ConfirmAccount - [X] ConfirmEdit - [] ContactManager - [X] ContactPage - [] ContentProvisioning - [] ContentStabilization - [] ContentTransfer - [X] ContentTranslation - [X] ContributionScores - [X] Contributors - [] CrawlableAllPages - [X] CreateAPage - [X] CreatedPagesList - [X] CreatePage - [X] CreatePageUw - [] (pending) CreateRedirect - [] DataTable2 - [X] DataTransfer - [X] DebugTemplates - [X] DeleteBatch - [X] Diagnosis - [X] DisableAccount - [X] Disambiguator - [X] DiscussionTools - [] DocBookExport - [] DonationInterface - [X] Drafts - [X] DumpsOnDemand - [X] Echo - [X] EditAccount - [X] Editcount - [X] EditNotify - [X] EditUser - [] EImage - [X] ElectronPdfService - [] EmailAuth - [] EmailAuthorization - [] EmailCapture - [] (pending) EmailNotifications - [] EnhancedStandardUIs - [] EnhancedUpload - [] EntitySchema - [] ExtensionDistributor - [] ExternalData - [] ExternalGuidance - [] FacetedCategory - [] FanBoxes - [] Favorites - [X] FeaturedFeeds - [] FileImporter - [] FileSystemImageServer - [] FlaggedRevs - [] FlexDiagrams - [] FlexiSkin - [X] Flow - [X] Form - [] Forms - [] FormWizard - [] FundraiserLandingPage - [] FundraisingEmailUnsubscribe - [X] Gadgets - [X] GlobalBlocking - [] (pending) GlobalContributions - [X] GlobalPreferences - [X] GlobalUsage - [] (pending) GlobalUserrights - [] GlobalWatchlist - [] GoogleAnalyticsTopPages - [] GoogleAuthenticator - [X] GoogleCustomWikiSearch - [] GoogleDocCreator - [] GoogleLogin - [] (pending) GoogleNewsSitemap - [] GraphQL - [X] GrowthExperiments - [] HitCounters - [] (pending) HostStats - [] IframePage - [] ImageRating - [] (pending) ImportFreeImages - [X] ImportUsers - [] Inbox - [] (pending) InviteSignup - [] IPInfo - [] JsonConfig - [] Kartographer - [] (pending) LandingCheck - [] (pending) LastUserLogin - [] LegalLogin - [] LinkedWiki - [] (pending) LinkFilter - [X] Linter - [] (pending) LiquidThreads - [] LiveChat - [] (pending) LogEntry - [] (pending) LookupUser - [] MagicLinkAuthentication - [] (pending) Maintenance - [] (pending) MaintenanceShell - [] (pending) MapSources - [] (pending) MassEditRegex - [] (pending) MassMessage - [X] Math - [] MathSearch - [] MediaSearch - [] MediaUploader - [] MediaWikiChat - [] MenuEditor - [] MergeArticles - [] MiniInvite - [] MintyDocs - [] MissedPages - [] (pending) MobileFrontend - [] (pending) MultiBoilerplate - [] MultiLanguageManager - [] MultiMail - [X] NearbyPages - [] (pending) NewestPages - [] Newsletter - [] NotifyMe - [X] Nuke - [] (pending) NukeDPL - [X] OATHAuth - [X] OAuth - [] OAuthAuthentication - [] (pending) OdbcDatabase - [] OOJSPlus - [] OpenBadges - [] ORES - [] OrphanedTalkPages - [X] PageAssessments - [] PageEncryption - [] PageExchange - [] PageForms - [] PageOwnership - [] PageProperties - [X] PageSchemas - [] (pending) PagesList - [] (pending) PageTriage - [] Patroller - [] PDFCreator - [] PersonalDashboard - [] Petition - [] PhabTaskGraph - [] PictureGame - [] PluggableAuth - [] Poll - [] (pending) PollNY - [] PreferencesList - [] PrivateDomains - [] PronunciationRecording - [x] ProofreadPage - [] PropertySuggester - [X] ProtectSite - [] (pending) Push - [] (pending) PushAll - [] QuizGame - [] (pending) RandomInCategory - [] ReadingLists - [] (pending) ReassignEdits - [] (pending) RefreshSpecial - [] RegexBlock - [X] ReplaceText - [] Report - [] S5SlideShow - [] SafeDelete - [] Sanctions - [] SearchStats - [] SecureAuth - [] SecureHTML - [X] SecurePoll - [] (pending) ShortUrl - [] SimilarEditors - [] SimpleBlogPage - [] (pending) SimpleChanges - [X] SiteMatrix - [] SiteMetrics - [] SiteSettings - [] SmiteSpam - [] SocialProfile - [] SoftRedirector - [] SpamDiffTool - [] SpamRegex - [] (pending) Special404 - [] SpecialNamespaces - [] SpellingDictionary - [] SportsTeams - [] Springboard - [] StructuredNavigation - [] SubpageNavigation - [] Sudo - [X] Survey - [] TemplateData - [X] TemplateSandbox - [] TestLanguageNameGrammar - [] (pending) Thanks - [] ThrottleOverride - [X] TimedMediaHandler - [] TimeMachine - [] TinyMCE - [] TopTenPages - [X] Translate - [] TuleapIntegration - [] TwoColConflict - [] UIFeedback - [] UnicodeConverter - [] UnifiedTaskOverview - [] UnlinkedWikibase - [] UnusedRedirects - [] UpdateMediaWiki - [] UploadWizard - [X] UrlShortener - [] UserExport - [] (pending) UserGroups - [X] UserMerge - [] (pending) UserOptionStats - [] (pending) UserPageViewTracker - [] UserStatus - [] UserVerification - [] VersionCompare - [] Video - [] (pending) VipsScaler - [] VisualData - [] VisualEditor - [] VoteNY - [] VueTest - [] Wanda - [] WandaScore - [] WatchAnalytics - [] (pending) WatchSubpages - [x] WebChat - [] WebToolsManager - [] (pending) WhoIsWatching - [] (pending) WhosOnline - [] Wikibase - [] WikibaseCirrusSearch - [] WikibaseLexeme - [] WikibaseQualityConstraints - [] WikibaseStatementUpdater - [] WikiForum - [X] wikihiero - [] WikiLambda - [] WikimediaApiPortalOAuth - [] WikimediaEvents - [] WikimediaIncubator - [] Wikispeech - [] WikispeechSpeechDataCollector - [] Wikistories - [] WikiToLDAP - [] Workflows - [] WSOAuth
  • T398775: Allow per-wiki configuration of section month titles
    • Task
    Currently the names of the topics that the script creates are hardcoded and there is no way to change them. This leads to the creation of strange titles. **Steps to replicate the issue** (include links if applicable): * Open https://ru.wikipedia.org/wiki/User:Iniquity with installed User:10nm/beta.js * Warn me **What happens?**: A very strange title appears: xg Y, where month is in the wrong case. Ruwiki has a different practice of naming titles. {F63206085} **What should have happened instead?**: The header must be formed according to the rules specified in the local configuration file.
  • T398758: [[MediaWiki:Timedmedia-in-job-queue]] is untranslatable due to concatenation
    • Task
    The message uses concatenation to build complete sentence. This is a practice discouraged by the MediaWiki guidelines, and unfortunately in this case it goes beyond just theory: it adds a message that has text in nominative case, whilst for the correct uk sentence one would need to write the time period in genitive. ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=timedmedia-in-job-queue&group=ext-timedmediahandler-user&language=uk
  • T398608: Hint under suggested pages is not localized for namespace Module
    • Task
    **Steps to replicate the issue** (include links if applicable): * Go to https://uk.wikipedia.org (for example) * Type in `Module:` (or `Модуль:`) in the search box * The suggested modules in the drop-down frame will have their hint (wikidata description) shown in English instead of Ukrainian (or any other local language) {F62819860 size=full} **What should have happened instead?**: * The hint should be localized, as it is for `Template:` or `Category:` {F62819886 size=full}
  • T398443: The message temp-user-banner-description is used as lego
    • Task
    The message temp-user-banner-description is used as "lego": it is concatenated in run time with colon-separator and the account name. It would be much better to put the account name into the message as a parameter, and to let the translators choose the punctuation. Currently, translating this is quite inconvenient to some languages. In fact, it's not so great even in English: "You are using a temporary account: ~2025-41753". It would make more sense to me without the colon and with "the" instead of "a", like this: "You are using the temporary account ~2025-41753". There are a few similar messages in other contexts, and they should all be consistent.
  • T398403: Right page tabs out of alignment for Kashmiri and Eastern Pwo on MacOS Firefox and Chrome
    • Task
    ==== What is the problem? Viewing a page in Kashmiri (`ks`) or Eastern Pwo (`kjp`) on MacOS in Firefox or Chrome, I am finding the "Edit" and "Edit source" tabs to be out of alignment with the rest of the tabs in that menu. I do not have MacOS locally, but I have reproduced on both Browserstack and Saucelabs. I have not reproduced on Safari, nor on Firefox or Chrome on another OS. ==== Steps to reproduce problem Example pages: * https://test.wikipedia.org/wiki/Template:!!?uselang=ks * https://test.wikipedia.org/wiki/Template:!!?uselang=kjp ==== Environment **Browser:** For Kashmiri I have reproduced the bug on: - Browserstack: Monterey Firefox 139 - Browserstack: Ventura Chrome 138 - Browserstack: Sonoma Chrome 138 - Saucelabs: Monterey Firefox 139 For Eastern Pwo: - Browserstack: Sonoma Firefox 140 - Saucelabs: Monterey Firefox 139 **Wiki(s):** https://test.wikipedia.org Vector 1.0.0 (9a92de3) 18:33, 30 June 2025. ==== Screenshots Kashmiri MacOS Monterey, Firefox 139: {F62775847} Kashmiri MacOS Sonoma, Chrome 138, showing both the source and visual editor tabs: {F62776148} Eastern Pwo, MacOS Sonoma, Firefox 140: {F62775850}
  • T396690: Enable RTL rendering of charts
    • Task
    **Feature summary** (what you would like to be able to do and where): In RTL languages like Persian and Arabic, it is typical for the X axis of a chart to flow from right to left. The #charts extension should enable this too. **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): Creating graphs that are displayed on RTL wikis **Benefits** (why should this be implemented?): Rendering graphs in a way that is familiar to readers of RTL languages **Example** [[https://commons.wikimedia.org/wiki/Data:Fawiki_FAC.chart|This chart]] on Commons is rendered LTR
  • T396258: Learn more button URL for the "Publishing only allowed to experienced users" message is hardcoded to an English Wikipedia page
    • Task
    While researching for T396142 on Finnish Wikipedia, we noted that the **Learn more button** under the **"Publishing only allowed to experienced users" message** (see [[ https://commons.wikimedia.org/wiki/File:Cx-limits-user-expertise-duplicated.png | this photo ]] for context) links to a project page on English Wikipedia (`https://en.wikipedia.org/wiki/Wikipedia:Content_translation_tool`). First I tried to find if this URL could be localized on translatewiki.net but since I couldn't find anything I checked the code and found that the URL is [[ https://github.com/wikimedia/mediawiki-extensions-ContentTranslation/blob/aa8d80c8b83fc2897aba3623f00998482d4a40e5/modules/mw.cx.UserPermissionChecker.js#L65 | hardcoded ]] on `mw.cx.UserPermissionChecker.js` ([[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/ContentTranslation/+/refs/heads/master/modules/mw.cx.UserPermissionChecker.js | gerrit ]]) on line 65. Since this feature of limiting newcomers from publishing translated articles into main namespace is in use on multiple projects we should have the possibility to localize the URL of the button.
  • T396231: Inconsistent namespace display names between HTML and JavaScript in NamespaceInputWidget
    • Task
    **Steps to replicate the issue** (include links if applicable): * Navigate to https://zh.wikipedia.org/wiki/Special:%E6%9C%80%E6%96%B0%E9%A1%B5%E9%9D%A2 (possibly replicable on other wikis as well but not tried) * For instance, NS5 is displayed as "Wikipedia讨论" {F61809457} * Turn JavaScript off, and open the same page again * Now NS5 is displayed as alias "维基百科讨论" {F61813346} **What should have happened instead?**: * The namespace names in HTML and JavaScript should be consistent. * They should both display in the UI variant language instead of site language. * They should both respect `MediaWiki:Conversion-ns{ns_id}/{lang_tag}` system messages. (display `维基百科讨论` instead of `Wikipedia讨论`) **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): 146aca8 (but this issue has been present for quite some time) **Other information** (browser name/version, screenshots, etc.): Before this consistency was introduced it's likely to show both localized aliases.
  • T395586: grouppage-temporary-account-viewer should be in plural
    • Task
    The message `grouppage-temporary-account-viewer` ([[ https://translatewiki.net/w/i.php?title=Special%3ATranslations&message=MediaWiki%3AGrouppage-temporary-account-viewer | translatewiki]]) should be in prural instead of the current singular form ("{{ns:project}}:Temporary account IP viewer"). It defines the title of the project page describing the user group on every project and they tend to be always in plural.
  • T395437: [[Wikimedia:Wikipedia-android-strings-recommended reading list notification title/uk]] translation issue
    • Task
    Ambiguous frequency variable. The words //daily / weekly / monthly// can be adverbs or adjectives depending on context, and other languages might have different word forms in different cases. (This is the case for Ukrainian, and translator has to jump over hoops to make the sentences work without a way to change the word forms). ---- **Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=wikipedia-android-strings-recommended_reading_list_notification_title&group=out-wikimedia-mobile-wikipedia-android-strings&language=uk
  • T395283: Can't inflect the code expiration time in the EmailAuth email text
    • Task
    The expiration time function in `emailauth-email-body-warning` ([[ https://translatewiki.net/w/i.php?title=Special%3ATranslate&showMessage=emailauth-email-body-warning&group=ext-emailauth | translatewiki ]]) disallows the correct inflection of the expiration time (currently 1 day) in the context of the sentence. I'd like to be able to translate the time noun(s) used in the sentence (days, hours, minutes etc.) just for that context. This issue applies to the Finnish localization and likely to some other languages too. To avoid needing to inflect the time, I set the Finnish tranlation time to say "The expiration time of the code is: $1" which sounds a bit unnatural in an email but it's better than a version with incorrect grammar.
  • T394877: Remove data tagged as `kr` from Wikidata
    • Task
    This task is about removing data tagged as `kr` from Wikidata: deleting it or moving it to `knc`. Part of T356144. For this task, use of @Amire80's script Wikidata language code cleanup is needed: https://gitlab.wikimedia.org/amire80/scriptology/-/tree/main/cleanup-wikidata-language-code. This Python script automates the cleanup of deprecated language codes (e.g. `kr`) from Wikidata items. It deletes or moves labels, descriptions, and aliases based on comparisons with fallback and related languages. The script uses the Pywikibot framework to process each item and logs cases it skips due to data inconsistencies or ambiguity to a CSV file for manual review.
1
2
Next
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits