**Steps to replicate the issue** (include links if applicable):
* Special:Block a test account using the following settings:
* partial (not sitewide)
* tick "account creation"
**What happens?**:
* block log message is vague: `09:47, 16 April 2025 Novem Linguae (talk contribs block) blocked NovemBot (talk contribs) **from specified non-editing actions** with an expiration time of 5 minutes (account creation disabled, autoblock disabled) (unblock | change block)`
**What should have happened instead?**:
* block log message is more specific. i am not actually sure what the new block log message should be. it depends on how we decide to fix this.
* ~~is it a bug to allow partial blocks without specifying anything? if so maybe we need to disallow this entirely~~
* do we just need a more specific message? well, this is complicated by the fact that changing `specified non-editing actions` to something like `account creation` is then redundant with the last part of the log message (`account creation disabled`)
* `09:47, 16 April 2025 Novem Linguae (talk contribs block) blocked NovemBot (talk contribs) **from account creation** with an expiration time of 5 minutes (account creation disabled, autoblock disabled) (unblock | change block)`
* for this specific case, do we just drop this part of the block log message entirely?
* `09:47, 16 April 2025 Novem Linguae (talk contribs block) **partially** blocked NovemBot (talk contribs) ** with an expiration time of 5 minutes (account creation disabled, autoblock disabled) (unblock | change block)`
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
* the i18n message key is `logentry-non-editing-block-block`
* {T208806} (from 2018) suggests that this message key used to be for the partial block non-page, non-namespace actions (Uploading files (including overwriting files), Moving pages and files, Creating new pages and uploading new files, and Sending thanks), but nowadays those are explicitly stated in the log entry
* discussion that prompted this ticket: https://en.wikipedia.org/wiki/User_talk:RoySmith#CU_followup
> If you are interested in working on this task, you can create a subtask for the language wiki (see the checklist in the task description below) that you plan to work on and assign the task to yourself.
==== Description ====
Namespaces are a core feature of all Wikimedia projects. They separate different types of content, for example, main articles, user pages, and discussions and are essential for the organization and functionality of a wiki. MediaWiki comes with built-in core namespaces (e.g., Talk, User, File), but these need to be localized per language in files like `MessagesXX.php`. Without this, contributors may see fallback or English namespace names, which leads to a bad user experience.
==== 🛠️ What needs to be done ====
For the languages listed below, a Wikipedia does exist, but the corresponding `MessagesXX.php` file in MediaWiki is missing the `$namespaceNames` array.
This task is to:
* Collaborate with active community members, preferably administrators, to gather correct localized namespace names for each language.
* Submit a patch to the MediaWiki core repository by adding `$namespaceNames` to the corresponding file, based on gathered input.
==== 🧭 How to proceed ====
* Visit the Wikipedia for the language in question.
* Find an active administrator or interface editor:
** Go to [[ https://xx.wikipedia.org/wiki/Special:ActiveUsers | Special:ActiveUsers ]] (replace xx with the language code)
** Or check the [[ https://xx.wikipedia.org/wiki/Special:ListUsers/sysop | Administrators ]] page (replace xx with the language code).
* Leave a talk page message politely asking for help identifying local namespace names.
** [[ https://incubator.wikimedia.org/wiki/Talk:Wp/kai | Example message]]
** [[ https://translatewiki.net/wiki/Translating:MediaWiki#Translating_namespace_names | Translating namespace names documentation ]]
* Submit the change to [[ https://gerrit.wikimedia.org/r/admin/repos/mediawiki/core,general | MediaWiki core ]], using the `$namespaceNames` format as seen in other `MessagesXX.php` files.
==== ✅ Checklist ====
(**9 languages** for which Wikipedia exists, but `$namespaceNames` are missing in MediaWiki Core even in fallback language message files)
| **Filename in MediaWiki core** | **Status** |
| MessagesFf.php | Request for namespace translations ongoing on [[ https://ff.wikipedia.org/wiki/User_talk:Adamu_mc | ff wiki ]] See T394870.
| MessagesIk.php | Couldn't find an active translator to reach out to. See [[ https://translatewiki.net/wiki/Portal:Ik | here ]].
| MessagesDz.php | Request for namespace translations initiated at [[ https://translatewiki.net/wiki/User_talk:Tenzin#Namespace_translations | User_talk:Tenzin ]] (User was last active in 2009)
| MessagesSt.php | Request for namespace translations initiated at [[ https://translatewiki.net/wiki/User_talk:Coldfact#Namespace_translations | User_talk:Coldfact ]] (User was last active in September 2022) and [[ https://st.wikipedia.org/w/index.php?title=User_talk%3ASANKOMOTA#Namespace_translations | User_talk:SANKOMOTA ]] (User was last active in May 2025)
| MessagesNy.php | Request for namespace translations initiated at [[ https://translatewiki.net/wiki/User_talk:Icem4k#Namespace_translations | User_talk:Icem4k ]]. User was last active in June, 2024.
| MessagesBo.php | Request for namespace translations initiated at [[ https://translatewiki.net/wiki/User_talk:Dhondup#Namespace_translations | User_talk:Dhondup ]]. User was last active in April, 2021.
| MessagesIu.php | Couldn't find an active translator to reach out to. See [[ https://translatewiki.net/wiki/Portal:Iu | here ]].
| MessagesEe.php | Request for namespace translations initiated at [[ https://translatewiki.net/wiki/User_talk:Amuzujoe#Namespace_translations | User_talk:Amuzujoe ]]. User was last active in January, 2023.
| MessagesTum.php | Request for namespace translations initiated at [[ https://translatewiki.net/wiki/User_talk:Tumbuka_Arch | User_talk:Tumbuka_Arch ]]. User was last active in November, 2024.
==== 📚 Resources ====
* [[ https://translatewiki.net/wiki/Translating:MediaWiki#Translating_namespace_names | Translating namespace names documentation ]]
* [[ https://www.mediawiki.org/wiki/Manual:Namespace | Manual:Namespace ]]
* [[ https://www.mediawiki.org/wiki/Extension_default_namespaces | Extension default namespaces ]]
* [[ https://www.mediawiki.org/wiki/Manual:Using_custom_namespaces | Manual:Using_custom_namespaces ]]
* [[ https://wikitech.wikimedia.org/wiki/Wikimedia_site_requests#Adding_or_changing_a_custom_namespace_alias | Adding or changing a custom namespace alias ]]
**Steps to replicate the issue** (include links if applicable):
When I tried to reject a pending changes edit, I believe it stated "Cannot reject these changes because someone already accepted some (or all) of the edits.". However, the changes were rejected by someone else.
Someone at WP:VP/T suggested to file a report on PHAB as it is likely affecting other wikis (fixed on enwiki by QoH).
**What should have happened instead?**:
I suggest a message change to "some or all of the edits have already received a review" or something along that line.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): 1.44.0-wmf.23 (70d5344)
**Other information** (browser name/version, screenshots, etc.): Chrome on Windows if that matters
I've noticed that the messages `wikilambda-functioncall` and `wikilambda-reference` are not documented clearly: their qqq just says "Label for the word function call." and "Label for the word reference.". I'd expect qqq to say also in which context these labels are used.
I tried finding where they are used, and they appear not to be used anywhere in the extension. If I run `git grep -P "wikilambda-functioncall[^-]" -- ":(exclude)*.json"` and `git grep -P "wikilambda-reference" -- ":(exclude)*.json"`, I find no results. (There are several "wikilambda-functioncall-*" messages, and they are used, but if I exclude them from the grep using `[^-]`, I find nothing.)
They seem to have disappeared from files other than JSON in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/931311/3/resources/ext.wikilambda.edit/Constants.js . (Several other "labels" there used to appear in en.json, but aren't there now.)
If these two messages are actually used as messages, they should [[ https://www.mediawiki.org/wiki/Help:System_message#Making_messages_findable | greppable ]] and documented more clearly in qqq. If they are not actually used, they should be deleted from i18n/*json and extension.json.
== Problem
The links in the footer on Wikimedia wikis, such as "Privacy policy", "Code of conduct", "Cookie statement" etc. use `Special:MyLanguage` to link to pages on foundation.wikimedia.org, which is good – in theory.
However, the way Special:MyLanguage works is that it chooses the redirect target based on the user's interface language on the target wiki. I don't know if there's data on this, but I'd bet the amount of people who actually have an account on foundationwiki and have actually changed their interface language (or any preference at all) is so small as to be insignificant. So everyone who hasn't done that and clicks one of those links, gets the default "mylanugage", i.e. the content language of the target wiki, which unsurprisingly is English. So even if you click one of these links on a non-English wiki, and the target page **does** have a translation into that language, you will end up at the English page unless you're one of those statistical outliers that have changed their user language on foundationwiki.
== Proposed solution
For the relevant links, append `?uselang={{USERLANGUAGE}}` [1] to the links, so that the user is directed to the translation in their language if it exists. A bonus feature is that the rest of the MediaWiki interface on foundationwiki will be in the same language the user arrived from when visiting this link.
[1] It is not documented in [[mw:Help:Magic words]], but I did some testing, and `{{USERLANGUAGE}}` seems to work even when `$wgParserEnableUserLanguage` is false, **when you use it in interface messages**. The alternative is to use `{{CONTENTLANGUAGE}}`, but USERLANGUAGE is probably better.
== Caveats
Currently, these links use internal links, but in order to append a URL query like `?uselang=`, you would have to use an external link instead. That should be fine, but that actually working is something to be cautious of.
Gadgets and other tools use the `{{GENDER:}}` information to inform its users about which pronouns are preferred. An example of this in action is the [[ https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups | navigation popups ]] if I set my preferences to use feminine terms where possible:
{F58893644}
(Note: I do not use she/her pronouns)
However, if the relevant preference is set to "unspecified", the gadget will not display any pronouns. This is understandable, as many users are not aware of this preference option existing, and the default option is "unspecified".
These configuration semantics are less helpful for folks who //explicitly// want to be referred to in a gender neutral way (i.e. use they/them pronouns), as there is currently no way to make the popups gadget display they/them for me.
I propose adding a fourth option which allows folks (especially non-binary people) to opt-in to gender neutral pronouns, and would function the same way "unspecified" does, but would allow tools and gadget to adjust their display accordingly (such as by displaying they/them right below my username)
From GitHub https://github.com/wikimedia/language-data/issues/412 via Rekw-WMTW
> This is Reke, the secretary general of Wikimedia Taiwan. As the title, I wish someone please change the autonym of Amis language from "Pangcah" to "Amis".
>
> The reasons for this request are:
>
> Amis is the official name of Amis people, especially Taiwanese government units only use this name.
> Amis Wikipedia community wish us to do. Prof. Tsay Chung-han, a core member of the community, told Wikimedia Taiwan that he have tried to find someone help them fix the word several times.
> According to the staff of Center for Aboriginal Studies, National Chengchi University (ALCD NCCU), the word "Pangcah" is a derogatory term, a bit close to "savage".
> I'm not very familiar with program editing. However, according to my reading of the documentation, the codes need to be change should be the line 38 of langdb.yaml, and the line 229 of language-data.json. If there are other related codes, please help me to fix at the same time.
**Description**
The goal of this task is to develop a stand-alone library that preprocesses i18n message tokens—formatted as `{{COMMAND:$value1|$value2|...}}`—to provide a consistent, reusable solution for Wikimedia projects and external consumers. Ultimately, this effort supports the broader goal (as outlined in T227447) of librarizing i18n-related PHP classes to simplify maintenance and improve reusability.
**Next Steps:**
[] **Wait** until Wikimedia/Leximorph is librarized (T390289).
[] Prepare codebase for initial code review.
[] Conduct initial code review.
[] Publish library on Packagist.
[] Announce initial release.
== Background
Scope addition from {T386621} with feedback from @Aaharoni-WMF and @Huji
1. Avoid using term “mirror”: […] slightly uncomfortable about using the term "mirror" for text fields. The verb "mirror" is good for describing what is done to graphics, such as icons that are horizontally flipped. Setting the direction of a text field, however, is not quite the same—its text direction changes, but it is not fully mirrored visually. If everyone else is certain that it will be convenient for designers who use these instructions, then feel free to keep using "mirror". But if you don't mind, consider changing "mirror" to something "define an opposite text direction" when talking about text fields.
1.1. Instead of mirroring, we could use "directional mirroring".
2. "Do mirror: [...] Alignment of text in RTL languages": Does this line make it clear to designers and developers who will use it that in HTML and CSS, direction (ltr/rtl) is distinct from alignment (left/right)? Setting direction also sets default alignment, but not the other way around: setting alignment does not define the correct direction. And occasionally they have to be defined explicitly and separately (e.g., ltr direction, but right alignment and vice versa).
3. "URLs and email addresses": it's better to write something like "Technical names that are always written in left to right scripts, such as email addresses". With "technical names" to be clearer defined: API tokens (alphanumeric), credit card numbers (if they contain space between groups of four digits, they can be incorrectly displayed in RTL), timestamps (especially when including colon or other similar characters), and TOTP tokens (which in my opinion should be both LTR and left-aligned). Email addresses are probably the most common example by far, but there are other kinds of small pieces of code. In the MediaWiki world in particular, these can be API action and parameter names (in the API sandbox), parser functions, and configuration variables. In particular, the names of the latter two begin with # and $, and these characters "jump" to the wrong side of the word if explicit direction is not set.
4. "Currency symbols" unclear: Should these be mentioned at all, because their usage may be different with every currency. If they are mentioned, there should be an example.
5. "URL and email addresses" section: both Hebrew screenshot have wrong labels. "Email" must be "דואר אלקטרוני" and "Website" must be "אתר".
6. "URL and email addresses" section: the "Don't" screenshot has an email address written in random Hebrew letters. This is irrelevant: it's better to write the same email address as in the "Do" screenshot, but aligned to the right. It will be a better demonstration of the undesirable behavior because email addresses are never written in non-Latin letters anyway.
7. More examples in different languages
> Finally, I get that Arabic and Hebrew are two of the most commonly used RTL languages, but I suggest we also include an example in Persian and Urdu, as other commonly used RTL language. FCOL, the number of people whose primary language is Persian or Urdu is nearly 10-fold that of Hebrew.
**Feature summary** (what you would like to be able to do and where):
Create a CI for PHP and JavaScript code, each, which tries to identify any variable whose value would be a username or IP address, and which is being used in a line of code that produces text output, then checks to see if `<bdi>` tags are being added appropriately.
**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):
Issues like T386700, T252568, T181955 and many more pop up here and there. If we had a CI check like that, even if the check wasn't able to find every case, it could still help avoid these bugs.
**Benefits** (why should this be implemented?):
Many developers come from a background with a native language that is an LTR language, and may not be familiar with bidi issues, or may not think of them as frequently as they should.
Attempts to address this upstream have failed. I can't find it but I'm pretty sure we had a proposal for some `User` class methods to auto-generate the bidi HTML tags but there were side effects and they were not implemented. We are stuck with bidi having to be implemented at the time of use of usernames and IP addresses in code.
Messages used in Community Configuration forms, such as Special:CommunityConfiguration/HelpPanel, are unsearchable because the message keys are built dynamically.
For example, take the `communityconfiguration-helppanel-gehelppanelreadingmodenamespaces-label` message: not only can I [[https://codesearch.wmcloud.org/deployed/?q=communityconfiguration-helppanel-gehelppanelreadingmodenamespaces-label&files=&excludeFiles=i18n%5C%2F.%2Bjson&repos= | not find it as-is]], but I also [[ https://codesearch.wmcloud.org/deployed/?q=gehelppanelreadingmodenamespaces&files=&excludeFiles=i18n%5C%2F.%2Bjson&repos= | can't find ]] the `gehelppanelreadingmodenamespaces` part (which seems sufficiently unique), and [[https://codesearch.wmcloud.org/deployed/?q=readingmodenamespaces&files=&excludeFiles=i18n%5C%2F.%2Bjson&repos= | not even ]] the `readingmodenamespaces` part which seems the minimum I can search for without getting unrelated results.
These messages seem to be generated based on the config schema (for the help panel, this would be [[https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/82a5e1882d998e45873adf41f7fbb7828a0d7ef6/includes/Config/Schemas/HelpPanelSchema.php | HelpPanelSchema]]), by taking the field name and applying normalization such as lowercasing the whole string (see MessagesProcessor).
Instead, in accordance with [[https://www.mediawiki.org/wiki/Help:System_message#Using_messages | Help:System_message#Using_messages]] and [[https://www.mediawiki.org/wiki/Manual:Coding_conventions#Dynamic_identifiers | Manual:Coding_conventions#Dynamic_identifiers]], message keys should be listed in full in the config itself. This way that they can be searched by humans, and hopefully automated tools will be able to report unused messages in the future (see T224429).
**Feature summary** (what you would like to be able to do and where):
Thank you very much for creating a very handy script to work with vandalism and patrol edits. But it only works on the English Wikipedia or I couldn't find a way to enable it in another project. Is there a way to make it more global and allow projects to configure it?
**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):
I want to add a script to the workflow in Russian Wikipedia.
**Benefits** (why should this be implemented?):
Making it easier to work with vandalism across Wikimedia.
I've been told, that some users think they've been sent an email the moment this message pops up and not after the registration process is finished.
It might be good to add "after you click Submit" or slightly rephrase the message in some other way.
----
**Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=growthexperiments-confirmemail-emailwarning&group=ext-growthexperiments-confirmemail&language=uk
Current form and copy:
{F58910555}
----
**New copy:**
TBD, some ideas:
- After you create your account, please look for an email from us to verify your address.
- After you create your account, check your inbox for a verification email.
- After signing up, look for our email to verify your email address.
----
**Acceptance Criteria:**
- Update copy
**Steps to replicate the issue**:
* https://en.wikipedia.org/w/api.php?action=query&format=json&variant=zh-tw&prop=info|pageprops&ppprop=displaytitle&titles=IPhone&formatversion=2&inprop=varianttitles
* varianttitles[en]: IPhone
* pageprops[displaytitle]: iPhone
**What happens?**:
The Action API varianttitles result didn't respect pageprops[displaytitle] and gave inconsistent result.
**What should have happened instead?**:
The Action API varianttitles result should respect pageprops[displaytitle].
**Software version**:
* MediaWiki: 1.44.0-wmf.16 (fbbe3b2) 2025-02-10 Monday 21:23
* PHP: 7.4.33 (fpm-fcgi)
**Additional information**:
* https://www.mediawiki.org/wiki/API:Info
**Steps to replicate the issue**:
* https://zh.wikipedia.org/zh-tw/高级加密标准
* Used conversion group on Wikipedia-zh: IT ( https://zh.wikipedia.org/wiki/Module:CGroup/IT )
* display title in zh-tw: 進階加密標準
* https://zh.wikipedia.org/w/api.php?action=query&format=json&variant=zh-tw&prop=info&titles=高级加密标准&formatversion=2&inprop=varianttitles
* display from Action API: 高級加密標準
**What happens?**:
The Action API varianttitles result does not reflect the actual display title in page view language.
**What should have happened instead?**:
The Action API varianttitles result should follow the actual display title in page view language.
**Software version**:
* MediaWiki: 1.44.0-wmf.16 (fbbe3b2) 2025-02-10 Monday 21:23
* PHP: 7.4.33 (fpm-fcgi)
**Additional information**:
* https://www.mediawiki.org/wiki/API:Info
Currently, MediaWiki:Tooltip-n-help message which is used in `title=""` of tooltip for `Help` link uses the following text:
```
The place to find out
```
This message is pretty much indecipherable and I would imagine most languages would have trouble translating it. Russian version, for example, translates it as `The place where the help is located` which is redundant for such a link. English Wikipedia, for example, uses `Guidance on how to use and edit {{SITENAME}}` instead.
Given that default target of this link is https://www.mediawiki.org/wiki/Help:Contents, this is a much easier to understand and translate than English version. The only problem is that many languages use cases, so using `{{SITENAME}}` is too complicated. Therefore, I suggest updating the message to a simpler version:
```
Guides on how to use and edit this website
```
Of course, local wikis can always continue to use their own preferred version instead.
----
**Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=tooltip-n-help&group=core&language=en
**Steps to replicate the issue** (include links if applicable):
* Go to https://meta.wikimedia.org/wiki/User:Amire80/mb_test_002?uselang=he
**What happens?**:
The content of the page is English, but it's displayed with RTL direction.
**What should have happened instead?**:
Since the content of the page is English, it must be displayed with LTR direction.
AFAIK, the content language of such pages is determined by the `sourceLanguage` key of the JSON content, and if it's absent, then the site's content language is assumed (but @abi_ can correct me if I'm wrong).
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
Currently deployed on Meta.
**Other information** (browser name/version, screenshots, etc.):
I am testing the message bundles feature of the Translate extension, so I'm only tagging #RTL and #mediawiki-extensions-translate. It's quite possible that other kinds of JSON pages are affected by this issue, too, but I haven't tested them.
**Steps to replicate the issue** (include links if applicable):
* i open -> [[ https://www.mediawiki.org/wiki/Special:Version ]]
* i see the sections Installed software and Entry point URLs
* each left column link points to a translated page (/fr) in my case
* skip now to sections Installed skins and extensions
**What happens?**:
* we see that starting from line "Cologne Blue" that links are hard coded to the /en page although translated pages exist
**What should have happened instead?**:
* I expected to be moved to the **corresponding translated page** either of skin or of extension
* that means a Special:MyLanguage/ is missing in front of (all Mediawiki) following link declarations
* never mind wether the translated page does not exist since fallback will be on the EN page
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.): Desktop + Vector skin.
* related topic [[https://www.mediawiki.org/wiki/Project:Support_desk#Special:Version_why_not_using_Special:MyLanguage_for_skins_and_extensions_?|#Special:Version_why_not_using_Special:MyLanguage_for_skins_and_extensions_?]] and informations given by Sam Wilson (only a few extensions have correct page links) ->
> The links for skins and extensions are taken from the skin.json and extension.json files, so the changes would need to be made there.
## Summary
Currently, for RTL scripts, on Special:Contributions, temporary account usernames are displayed inconsistently (headings vs the field value: RTL/LTR), and also in different ways between different scripts.
EDIT: Hebrew and Yiddish may be treated as LTR here - for the help icon, the LTR option is used.
## Background
[[https://fa.wiktionary.org/w/index.php?title=%D9%88%DB%8C%DA%98%D9%87%3A%D9%85%D8%B4%D8%A7%D8%B1%DA%A9%D8%AA%E2%80%8C%D9%87%D8%A7&target=~2025-17718&uselang=ar&safemode=1|fawiktionary, uselang=ar (Arabic)]]:
{F58371593 width=400}
[[https://fa.wiktionary.org/w/index.php?title=%D9%88%DB%8C%DA%98%D9%87%3A%D9%85%D8%B4%D8%A7%D8%B1%DA%A9%D8%AA%E2%80%8C%D9%87%D8%A7&target=~2025-17718&uselang=fa&safemode=1|fawiktionary, uselang=fa (Persian)]]:
{F58371612 width=400}
[[https://fa.wiktionary.org/w/index.php?title=%D9%88%DB%8C%DA%98%D9%87%3A%D9%85%D8%B4%D8%A7%D8%B1%DA%A9%D8%AA%E2%80%8C%D9%87%D8%A7&target=~2025-17718&uselang=he&safemode=1|fawiktionary, uselang=he (Hebrew)]]:
{F58371604 width=400}
[[https://fa.wiktionary.org/w/index.php?title=%D9%88%DB%8C%DA%98%D9%87%3A%D9%85%D8%B4%D8%A7%D8%B1%DA%A9%D8%AA%E2%80%8C%D9%87%D8%A7&target=~2025-17718&uselang=yi&safemode=1|fawiktionary, uselang=yi (Yiddish)]]:
{F58371590 width=400}
## 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
The Wikibase Client message `wikibase-client-data-bridge-blocked-on-repo-body` is based on the core message `blockedtext`. The latter was update in core, so the Wikibase Client message should be updated, too.
**Steps to replicate the issue** (include links if applicable):
* Start an translation of an article that has a template that does not exist in the target languge
* Click on the paragraph that the template is in
* Content Translate gives you the message MediaWiki:Cx-tools-linter-template-block-message, which says: "This template has been skipped, but you can add new content to capture the missing information."
Example: https://is.wikipedia.org/w/index.php?title=Metal_Gear&oldid=1898436 - The template "Infobox video game series" did not exist in the target language and was added regardless. There is no local template linking to the target template.
**What happens?**:
Content Translate does Not skip/remove the template, despite claiming to do that.
**What should have happened instead?**:
Content Translate should have kept to it's word and skipped/removed the template, instead of lying to the user. Obviously, I do not like being lied to.
Or, if the intention was not to claim to remove the template, then do not say that it was skipped.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): WMF
**Other information** (browser name/version, screenshots, etc.): Firefox 133.0.3
It looks like plural rules in MediaWiki haven't been updated from upstream CLDR since 2014 ({8dc3631093e1ace34ded60e603f8fdaf5656667d}). We should update them, and we should also have a procedure for updating them regularly in the future.
Some issues to notice:
[ ] Rule update for some languages may be correct, but it may require updating translations (it had to be done in Russian once, for example).
[ ] Some rules may have become wrong, so they all have to be checked with people who know the languages. In such cases, we'll have to make a local patch in plurals-mediawiki.xml and to report an upstream bug. (I know that it has to be done for Hebrew, but some other languages may need this, too.)
[ ] A procedure for updating has to be documented, so that it will be possible to practice it regularly.
[ ] //add other stuff if needed//
I noticed this because of an issue with T384155.
Previous update: T64861
Hello,
Is there a way to resize the edit checking box so that it fits between the lines, screenshot : {F58402073}
The rectangle seems too large. I apologize for the unclear explanation. Regards
T373746 describes some bugs where inputs on the edit function page do not display in the proper direction. Visit this [[ https://www.wikifunctions.org/wiki/Z13667?action=edit&uselang=he | function edit page ]] to see the UI in Hebrew. Some of the inputs are meant to capture English text, but are rendered right-to-left since they respect the UI direction. Punctuation is sometimes placed improperly (e.g. "n!" is shown as "!n" and text is aligned to the right:
{F58205236}
Part of this will be fixed by a patch connected to that bug task that sets the dir and lang attributes on the inputs, which will make the text within these inputs display properly. However, there are 2 remaining issues:
1. The text of chips within the ChipInput is still incorrect since the lang and dir are only set on the input element
2. The components still display their elements in RTL. Ideally, the entire component would be shown in the direction of the language that's meant to be captured. This is not as simple as setting a lang and dir on the component or a parent element since we do not serve bidirectional styles in MediaWiki.
To resolve this task, we should:
1. Consider if we should enable bidirectional styles in MediaWiki
2. If not, create a stop-gap solution to ensure that chips are displayed in the proper lang/dir (this might look like adding lang and dir props to ChipInput and applying them to each chip)
---
### Acceptance criteria
- [] Discuss how to approach these issues
- [] Document decisions and open new tasks for further work
**Steps to replicate the issue** (include links if applicable):
* Go to https://query.wikidata.org/ and select "ku" ("kurdî") or "ku-latn" ("kurdî (latînî)") from the language selector.
* Run a query which returns a date. [[ https://query.wikidata.org/#SELECT%20DISTINCT%20%3Fitem%20%3FitemLabel%20%3FitemDescription%20%3FdeathDate%0AWHERE%20%7B%0A%20%20SERVICE%20wikibase%3Amwapi%20%7B%0A%20%20%20%20bd%3AserviceParam%20wikibase%3Aendpoint%20%22ku.wikipedia.org%22%3B%0A%20%20%20%20wikibase%3Aapi%20%22Generator%22%3B%20%0A%20%20%20%20mwapi%3Agenerator%20%22categorymembers%22%3B%0A%20%20%20%20mwapi%3Agcmtitle%20%22Kategor%C3%AE%3AMirin%202024%22%3B%20%0A%20%20%20%20mwapi%3Agcmprop%20%22ids%7Ctitle%7Ctype%22%3B%0A%20%20%20%20mwapi%3Agcmlimit%20%22max%22.%0A%20%20%20%20%3Fmember%20wikibase%3AapiOutput%20mwapi%3Atitle.%0A%20%20%20%20%3Fns%20wikibase%3AapiOutput%20%22%40ns%22.%0A%20%20%20%20%3Fitem%20wikibase%3AapiOutputItem%20mwapi%3Aitem.%0A%20%20%7D%0A%20%20OPTIONAL%20%7B%20%0A%20%20%20%20%3Fitem%20wdt%3AP570%20%3FdeathDate.%20%20%23%20Retrieve%20raw%20death%20date%0A%20%20%7D%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20%0A%20%20%20%20bd%3AserviceParam%20wikibase%3Alanguage%20%22ku%2Ckmr%2Cku-latn%2Cen%22.%20%0A%20%20%7D%0A%7D%0A| Example query ]]
**What happens?**:
The displayed date is in Arabic letters.
**What should have happened instead?**:
The dates should be in Latin alphabet since both ku and ku-latn is based on Latin alphabet.
**Other information** (browser name/version, screenshots, etc.):
I tried this on both Firebox and Chrome.
The issue may be related to T324454
Special:AllMessages should display overridden message keys. Currently the appearance of messages with keys overridden by the MessageCacheFetchOverrides hook is very confusing.
For example: https://pt.wikinews.org/w/index.php?title=Especial:Todas_as_mensagens&filter=modified&lang=pt&limit=50&prefix=Mobile-frontend-license-links {F58150301} this currently displays that https://pt.wikinews.org/wiki/MediaWiki:Mobile-frontend-license-links is customized locally, yet the customized and original text is the same, and different from the text actually on the page: {F58150303} that's because the real message text is fetched from https://pt.wikinews.org/wiki/MediaWiki:Wikinews-mobile-license-links, but you have no way to learn that from that special page.
I wish to request a new method that we implement CLDR on MediaWiki, as it currently leaves a lot to be desired regarding adding and modifying content.
I started investigating this as I am working on translating strings to the language Toki Pona (`tok`). In preparation for the possible [[https://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Toki_Pona_2 |Toki Pona Wikipedia]] and for adding support for existing [[https://wikipesija.org/|Toki Pona wikis]], me and other contributors have been translating strings and have come across the fact that there are several missing and simply incorrect pieces of information relating to the language locale. For example, 'Bulgarian' (`bg`) is translated as 'ma Pokasi' meaning 'Bulgaria' (the country); and the date formats have not been properly marked: 3 January 2025 is '3 tenpo mun #1 2024', however speakers would rather say 'sike #2025 la mun #1 la suno #3' or similar. In order to edit Toki Pona items, I contacted CLDR to create a [[https://cldr.unicode.org/index/survey-tool|Survey Tool]] account. However, the project only accepts updates for a short period of time, requires a lot of votes to pass and takes months to be released.
Below are a few other related tasks and discussions, where people had to endure with incorrect or missing information for a long time (some tasks are still even open), brought to my attention from the kind people at the Wikimedia community Discord server. This is not a problem just for the small languages but for all languages.
**Previous discussions**
* {T189511}
* {T231748}
* {T245927}
* {T256649}
This is an issue because as far as I am aware, contributors choose to stick to CLDR and not interfere with it locally, as one pointed out to edit CLDR directly rather than MediaWiki. With the difficulty of editing, however, this is not possible for most contributors. With the recent membership of the Wikimedia Foundation to Unicode, I suggest that it help contributors to add local strings upstream to the CLDR.
Stjn proposed a basic workflow which I will reiterate here as a proposal:
* Post information regarding the desired changes to Village Pump of relevant language Wikipedia (possibly other projects as well)
* Update local CLDR extension files if approved by contributors
* A WMF member raises the issue upstream and votes for it being fixed
This would be better as a method to more quickly update errors on our projects and more quickly update CLDR.
I hope to hear feedback on this idea.
Currently, the parser function has inconsistencies with major international standards, making its behavior unpredictable in various scenarios. This complicates the localization of dates. It is necessary to enable the functions to operate directly within date standards ISO/EDTF.
I tried to fix the text of this message in my translation (when $1=1 or 2 or 3 or more), but I'm not sure PLURAL works like that:
$1 article{{PLURAL:$1|1=, à savoir $2|2=s, à savoir $2 et $3|3=s, à savoir $2, $3 et $4|s, dont $2, $3 et $4}}.
Could you help me ?
----
**Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=wikipedia-ios-year-in-review-personalized-saved-subtitle-format&group=out-wikimedia-mobile-wikipedia-ios&language=fr
The [[ https://gerrit.wikimedia.org/r/admin/repos/mediawiki/extensions/Citoid,general | Citoid mediawiki extension ]] has a credit line (Powered by...") which will display either "Powered by Zotero" or "Powered by Wayback Machine."
"Powered by" is translatable, but "Zotero" and "Wayback Machine" are not.
These should be internationalised by adding new messages to qqq.json and en.json files in the i18n subdirectory and making the relevant changes to /ve/modules/ve.ui.CitoidInspector.js to pull in the messages.
You don't need to modify the other i18n files, but qqq.json is for notes/info; you might comment that although Zotero and Wayback Machine are both proper names and don't need to be translated in many Latin languages, they might need to be transliterated in some languages that use different character sets (i.e. Arabic, Russian, etc.)
See also [[ https://www.mediawiki.org/wiki/Manual:Developing_extensions#Localisation | Manual:Developing_extensions#Localisation ]] for more on how to make messages translatable.
In order to test it is working, you will need to [[ https://www.mediawiki.org/wiki/MediaWiki-Docker | set up mediawiki ]] and the [[ https://www.mediawiki.org/wiki/MediaWiki-Docker/Extension/Citoid#Clone_the_extension_and_configure | Citoid extension ]] using Docker.
You will also need to add citation templates and configure citoid in your local installation, following the directions [[ https://www.mediawiki.org/wiki/Citoid#Installation_2 | here ]].
First export from translatewiki with https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1101756
[v] Verify autonym correctness in language-data
[v] Add to Wikifunctions's language list in function-schemata
[v] Add to `includes/languages/data/Names.php` ([[ https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1102318 | patch ]])
[v] Add to RELEASE-NOTES ([[ https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1102318 | patch ]])
[ ] Add namespace translations ([[ https://incubator.wikimedia.org/wiki/Talk:Wp/fvr/Sa%C5%8Bgal_app%C3%A2k%CA%89%C5%8Bo | asked ]])
-- [ ] Add gender aliases if needed
-- [ ] Check that namespace translations don't conflict with language codes
[v] Add $linkTrail ([[ https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1102318 | patch ]])
[v] Remove from translatewiki after deploying the core change ([[ https://gerrit.wikimedia.org/r/c/translatewiki/+/1102385 | patch ]])
-- [v] `mw-config/LanguageSettings.php`
[v] Test language search in UniversalLanguageSelector and fix the search index (if needed)
The text of this message is "$1 created".
The french translation of "created" is depending of the gender of $1.
Could you give me the list of all values for $1 ?
Or, better, could you add a documentation to tell us what is $1 ?
----
**Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=cpd-shape-creation-message&group=ext-cognitiveprocessdesigner&language=fr
**Feature summary** (what you would like to be able to do and where):
The ISO standard suggests that I can represent date intervals in the following format `YYYY-MM-DD/DD`, `YYYY-MM/MM-DD`, `YYYY-MM/MM etc. It would be useful to be able to convert data from dates into readable intervals:
|2024-03-12/15|12-15 March 2024|
|2024-03-12/04-15|12 March - 15 April 2024|
|2024-03/04|March - April 2024|
**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):
At the moment, I am thinking about how to adapt normal display of dates in citations for all languages with minimal pain. For now, I can say that the only way is to convert to ISO format and then convert to the desired language. Intervals is a big part of citations.
**Benefits** (why should this be implemented?):
This will allow modules such as https://en.wikipedia.org/wiki/Module:Citation/CS1 to provide dates in the required language more efficiently.
This message (`Thanks received`) is used twice on Special:Homepage, once on the impact card itself, following a number, and once as a popup title. These two occurrences are different:
* on the card, it should be singular in Hungarian, and it should use PLURAL in most Indo-European languages (e.g. in German it should be `{{PLURAL:$1|Dankeschön|Dankeschöns}} erhalten`);
* on the popup, it should be plural in Hungarian, and the lack of PLURAL support is fine for hopefully all languages.
By the way, `growthexperiments-homepage-impact-scores-edit-count` (currently `Total edits`) also needs PLURAL support. (However, as far as I see it’s not used as a popup title, so it doesn’t need to be split.)
Or you want them to be titles? Then they should appear //above// the numbers, not //below// them, because the current layout suggests they’re parts of sentences.
----
**Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=growthexperiments-homepage-impact-scores-thanks-count&group=ext-growthexperiments-homepage&language=hu
Currently, when a user on mobile attempts to edit a protected page they don't have permission to edit, they're shown the message !!This page is protected to prevent vandalism.!! (`mobile-frontend-editor-disabled`)
{F57749868}
However, from the software's perspective, it doesn't know //why// the page has been protected (at least, not without parsing the protection log), only that it //is//. It therefore seems potentially a little misleading to always state that the reason for a page's protection is "to prevent vandalism", when the actual reason for the page being protected could be different from that (e.g. an edit war, addition of unsourced content, sockpuppetry, etc.). It's probably also worth noting that some projects use a very specific definition of 'vandalism' - e.g., the English Wikipedia [[https://en.wikipedia.org/wiki/Wikipedia:Vandalism|defines it]] as behaviour "deliberately intended to obstruct or defeat the project's purpose".
Doing some Phabricator-archaeology, I found that this was brought up briefly in T95305#1322596 in 2015. The current wording of this message appears to originate from 30917ee in December 2013; and its initial wording in July 2013 (from cb55047) appears to have been !!You are not allowed to edit this page.!!
**Steps to replicate the issue** (include links if applicable):
* Go to an item on wikidata.org without any sitelinks
* Go to the "Multilingual sites" section and click edit
* Type the letter "w" in the "wiki" field
**What happens?**:
Some wikis have the database name (e.g. "wikifunctionswiki") as the wiki name.
English:
{F57735855}
Japanese:
{F57735857}
**What should have happened instead?**:
All wikis in this section should have a proper translatable name (e.g. "Wikifunctions") as the wiki name.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
The missing messages are:
* wikibase-sitelinks-sitename-foundationwiki
* wikibase-sitelinks-sitename-outreachwiki
* wikibase-sitelinks-sitename-specieswiki
* wikibase-sitelinks-sitename-wikifunctionswiki
* wikibase-sitelinks-sitename-wikimaniawiki
The messages which do exist seem to be defined in https://gerrit.wikimedia.org/g/mediawiki/extensions/WikimediaMessages/+/master/i18n/wikimedia/en.json
//(Originally reported in https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt#Vorschau,_Bild,_falsche_Sprach-Version )//
**Steps to replicate the issue**:
* Create an article with a multi-language SVG as page image and define the language you want to display in the parameters (example: https://de.wikipedia.org/wiki/Ventil with image https://commons.wikimedia.org/wiki/File:Globe_valve_diagram.svg)
* Link to that page from another article
* Check the preview for that link
**What happens?**:
* The preview will ignore the language setting and render the image with English labels instead:
{F57733576}
**What should have happened instead?**:
* The preview should show the same language as the article
This text talks about "grammar and punctuation".
But this text is a description of the AI command "Fix grammar and spelling" (see https://translatewiki.net/wiki/MediaWiki:Aieditingassistant-ui-command-check-grammar/en).
"punctuation" and "spelling" cannot be translated with the same word in French : could you tell me which one is the good one ? (And maybe improve the appropriate message according to what the AI really does ?)
----
**Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=aieditingassistant-ui-description-check-grammar&group=ext-aieditingassistant&language=fr
The text we have to translate is ;
"The reason given is:
:<em>$1</em>."
The char ":" at the end of the first line and the same char at the beginning of the third line seem redondant.
----
**Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=globalblocking-blockedtext-autoblock-reason&group=ext-globalblocking-user&language=fr
The message vector-searchsuggest-containing is currently this:
`Search for pages containing <strong class="cdx-typeahead-search__search-footer__query">$1</strong>`
This is a lot of HTML markup, especially given the fact that this message is otherwise short and simple, and appears in one of the most notable places in the desktop interface.
This has real impact on the volunteer translators in translatewiki. I have just corrected mistakes in the translation of this message into **twelve** languages. In addition, multiple translators reached out to me personally and asked how to translate it. Usually, this is not supposed to happen much with simple messages, and translatewiki is supposed to be mostly "self-service". If it was just one person, it could be dismissed as one translator's inexperience, but when it's a dozen, the problem is clearly systemic.
Since the HTML is the same in all the languages anyway, it would be great to get the code to add it (it's Vue code, if I understand correctly). The message shouldn't include any code except $1, so that people would be able to put the word in the correct place in the sentence.
//(I've added a bunch of project tags that seem relevant. Please adjust as needed.)//
MediaWiki\Language\Language::listToText return:
`شئ، شئ، شئ ... وشئ`
instead of:
`شئ وشئ وشئ ...وشئ`
According to Arabic grammar and writing texbooks, we do not use the comma to link between words; we use waw al-'atif.
**Steps to replicate the issue** (include links if applicable):
* Find or create an item with a `zh-hant` label and an `en` label but no `zh-tw` label, e.g. https://test.wikidata.org/wiki/Q195860
* Set your Babel box `{{#babel:zh-tw|zh-hant|zh|en}}`
* Set the user interface to `zh-tw`
* Go to a standard MediaWiki page like "What links here", e.g. https://test.wikidata.org/wiki/Special:WhatLinksHere/Q195860?uselang=zh-tw
**What happens?**:
The links back to the item use the `en` label.
**What should have happened instead?**:
The links back to the item use the `zh-hant` label.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
It appears to use the values for each level in the Babel box in alphabetical order.
It doesn't take fallback languages or language variants into account, even when those codes are explicitly included.
This means we currently cannot rely on language fallback as a way to handle country variants.
**Steps to replicate the issue** (include links if applicable):
* Set the UI language to `de-formal`
* Run a query which uses `[AUTO_LANGUAGE]` to select labels (e.g. [[https://query.wikidata.org/#select%20%3Fitem%20%3FitemLabel%20%7B%0A%20%20values%20%3Fitem%20%7B%20wd%3AQ1%20wd%3AQ42%20%7D%0A%20%20service%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%22.%20%7D%0A%7D|this query]])
*
**What happens?**:
`[AUTO_LANGUAGE]` is replaced by the current UI language, without any fallbacks included.
In this case, `de-formal` is a UI-only language, so no labels are shown.
**What should have happened instead?**:
When replacing `[AUTO_LANGUAGE]` with the current UI language, fallback languages are included, so that the user sees the same labels that they would see on-wiki (e.g. [[https://www.wikidata.org/w/index.php?oldid=2270791846&uselang=de-formal|here]]).
In this case, it should fall back to `de`, `mul` and `en` (see [[https://www.wikidata.org/wiki/Special:MyLanguageFallbackChain?uselang=de-formal|Special:MyLanguageFallbackChain]])
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
Related ticket: T299525 - I don't think this is the same thing because you can manually insert fallbacks when providing specific language codes. The whole point of using `[AUTO_LANGUAGE]` is that we don't know what the language will be, therefore we can't include the right fallbacks ourselves.
The text to translate is « Invalid value "$2" for boolean parameter "$1". Got a $3 value instead. »
With this text, $3 seems to be a value (like $2).
But the documentation says "$3 - The actual type of the parameter value"
So $3 is a value or a type ?
Could you give examples of the content of $1, $2 and $3 ?
note : from another translation text, i suspect "Got a $3 value instead" is similar to "Value appears to be of type $3", easier to translate. Do you confirm ?
----
**Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=paramvalidator-badbool-type&group=wikimedia-paramvalidator&language=fr
`WikiReference::getDisplayName` literally just parses the canonical server name and returns the host. So, for example, on enwiki it returns `en.wikipedia.org`. `WikiMap::getWikiName`, which is basically just a shortcut for `getDisplayName`, does the same. Neither of them does what it claims to do, i.e. give you the name of a wiki. For Wikimedia projects, we have localised wiki names available in `project-localized-name-*` messages, defined in the WikimediaMessages extension.
It would be nice to bring this concept into core and update the definition of "wiki name". We could have a new `function getLocalisedName(): Message` method that tries to use the corresponding `project-localized-name-*` message, and falls back to the host if the message doesn't exist. The message format would be documented somewhere on mw.org. And the existing methods would then be deprecated/renamed depending on the remaining use cases.
As user of wikibases in a language other than English
I want to be able to correct grammatically correct language
So that mistakes are not made
Steps to reproduce
1. Go to the czech page for setting labels: https://www.wikidata.org/wiki/Special:SetLabel?uselang=cs
2. Observe that the title is "Nastavit štítek pro položka/vlastnost" and not "Nastavit štítek položce/vlastnosti"
3. Go to ??? and observe that the the displayed words "položka"/"vlastnost" are taken from
- "wikibase-entity-item": "položka",
- "wikibase-entity-property": "vlastnost",
A/C (Suggested, to be confirmed by PM)
[ ] Users can set a entity-type-specific message
[ ] The exisiting generic messages are used if not specific message is set (Following the approached used in [AutoCommentFormatter::getSummaryMessage()](https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/9873ebea5ec75605452db6201a0622b896cc5c0c/lib/includes/Formatters/AutoCommentFormatter.php#51)
Open Questions:
- How do we find out from where the item/property values are taken ?
- How should the UX be in setting the specific messages?
Notes:
- Messages were introduced in [FP: SpecialPages: Parameterize description](https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/608903) for T256119 FTR.
Original Description:
>The messages
>```
>"special-setaliases-parameterized": "Set $1 aliases",
>"special-setlabel-parameterized": "Set $1 label",
>"special-setdescription-parameterized": "Set $1 description",
>"special-setlabeldescriptionaliases-parameterized": "Set $1 label, description and aliases",.```
>are difficult to translate to other languages. The `$1` parameter is usually "Item/Property" taken from
>```
>"wikibase-entity-item": "Item",
>"wikibase-entity-property": "Property",
>```
>messages which are usually used in contexts like "what entity type."
>
>While literal substitution works for English, in other languages it may be necessary to somehow change the word for item/property (e.g., //Set __item's__ label//).
**Steps to replicate the issue** (include links if applicable):
* Go to any random article on Odia Wikipedia
* Edit using either Visual or Source Editor
* Try to use the internal/external link option and type an example e.g. "ମନୋଜ ଦାସଙ୍କ"
**What happens?**:
* In the above example only "ମନୋଜ ଦାସଙ୍କ" shows up
**What should have happened instead?**:
In Odia, ଟି ଟିର ର, ଙ୍କ, ଙ୍କର, ମାନଙ୍କ, ମାନଙ୍କର, କୁ, ଙ୍କୁ, ରୁ, ଟିରୁ, ଠା, ଠାରୁ, ମାନଙ୍କରୁ, ମାନଙ୍କଠାରୁ, ରେ, ଟିରେ, ଠାରେ, ମାନଙ୍କରେ, ମାନଙ୍କଠାରେ, ସ୍ଥ, ଠାର, ଇଆ and ଉଆ are noun suffixes. So, "People of Odisha" is "ଓଡ଼ିଶାର ଲୋକ" where "-ର" suffix is added to the root word "ଓଡ଼ିଶା". However, in either editors, the article ଓଡ଼ିଶା is not showed when one types "ଓଡ଼ିଶାର". Often one might want to link "ଓଡ଼ିଆ-ଭାଷୀ" with the article "ଓଡ଼ିଆ ଭାଷା" but one cannot select "ଓଡ଼ିଆ-ଭାଷୀ" in VisualEditor and it would show "ଓଡ଼ିଆ ଭାଷା", but has to manually type it.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
** Examples
*** 1
{F57645598} (search term ଓଡ଼ିଆଭାଷୀ shows ଓଡ଼ିଆ ଭାଷା as a result - this is a good search)
{F57645600} (However, search term ଓଡ଼ିଆଙ୍କ doesn't show the related and available article ଓଡ଼ିଆ)
*** 2
{F57645612} (search term ଭୁବନେଶ୍ୱରୀ shows multiple related words but search term ଭୁବନେଶ୍ୱରିଆ shows none, even though both words literally mean the same)
{F57645617}
T4085 added the USERLANGUAGE magic word, but it has only been enabled on Commons and Meta-Wiki. Multilingual wikis need to be able to display content based on the user language rather than the wiki language, so it should be enabled for all of them.
P70458 has a list of wikis by number of MediaWiki:Lang subpages (used for the `{{int:lang}}` hack).
While working on a series of Tracking categories on a few wikis in different languages - I noticed how glaring the inconsistencies in the grammatical framing and structure of the entries across the Special:TrackingCategories page on Wikimedia wikis.
Suggest making some updates to provide for greater consistency, increase use of links to related MediaWiki.org documentation where possible, and reduce possible confusion across languages.
- [] broken-file-category-desc: `The page contains a broken file link (a link to embed a file when the file does not exist).`
- [] duplicate-args-category-desc: `The page contains template calls that use duplicates of arguments, such as <code><nowiki>{{foo|bar=1|bar=2}}</nowiki></code> or <code><nowiki>{{foo|bar|1=baz}}</nowiki></code>.`
- [] expansion-depth-exceeded-category-desc: `The page exceeds the maximum expansion depth.`
- [] expensive-parserfunction-category-desc: `The page uses too many expensive parser functions (like <code>#ifexist</code>). See [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:$wgExpensiveParserFunctionLimit Manual:$wgExpensiveParserFunctionLimit].`
- [] hidden-category-category-desc: `The category contains <code><nowiki>__HIDDENCAT__</nowiki></code> in its page content, which prevents it from showing up in the category links box on pages by default.`
- [] index-category-desc: `The page has a <code><nowiki>__INDEX__</nowiki></code> on it (and is in a namespace where that flag is allowed), and hence is indexed by robots where it normally wouldn't be.`
- [] node-count-exceeded-category-desc: `The page exceeds the maximum node count.`
- [] noindex-category-desc: `The page is not indexed by robots because it has the magic word <code><nowiki>__NOINDEX__</nowiki></code> on it and is in a namespace where that flag is allowed.`
- [] nonnumeric-formatnum-desc: `The page contains a non-numeric argument to the formatnum parser function.`
- [] post-expand-template-argument-category-desc: `The page is bigger than <code>$wgMaxArticleSize</code> after expanding a template argument (something in triple braces, like <code>{{{Foo}}}</code>).`
- [] post-expand-template-inclusion-category-desc: `The page size is bigger than <code>$wgMaxArticleSize</code> after expanding all the templates, so some templates were not expanded.`
- [] restricted-displaytitle-ignored-desc: `The page has an ignored <code><nowiki>{{DISPLAYTITLE}}</nowiki></code> because it is not equivalent to the page's actual title.`
- [] template-equals-category-desc: `The page contains <code><nowiki>{{=}}</nowiki></code> but on this wiki that does not expand to <code>=</code>. This usage is deprecated; a future MediaWiki version will implement <code><nowiki>{{=}}</nowiki></code> as a parser function.`
- [] template-loop-category-desc: `The page contains a template loop, ie. a template which calls itself recursively.`
- [] unstrip-depth-category-desc: `The page exceeds the unstrip depth limit.`
- [] unstrip-size-category-desc: `The page exceeds the unstrip size limit.`
- [] bad-language-code-category-desc: `The page contains a <code><nowiki>{{#dir}}</nowiki></code> with an invalid language code.`
- [] double-px-category-desc: `The page contains an image whose size contains an extra <code>px</code> suffix, like <code>100pxpx</code>.`
- [] timeline-tracking-category-desc: `The page includes a <code><timeline></code> tag`
- [] wikihiero-usage-tracking-category-desc: `This category is automatically added to pages that use WikiHiero extension`
- [] cite-tracking-category-cite-error-desc: `Pages in this category have errors in the usage of references tags.`
- [] cite-tracking-category-ref-extends-desc: `Pages in this category use the "extends" attribute of the <ref> tag.`
- [] syntaxhighlight-error-category-desc: `There was an error when attempting to highlight code included on the page.`
- [] syntaxhighlight-enclose-category-desc: `The syntaxhighlighting on the page uses deprecated enclose syntax.`
- [] syntaxhighlight-source-category-desc: `The syntaxhighlighting on the page uses deprecated source tags.`
- [] categorytree-deprecation-category-desc: `The page uses deprecated categorytree parameters like <code>onlyroot</code>.`
- [] lst-invalid-section-category-desc: `The page uses a #lst or #lsth parser function that references a section that doesn't exist on the given page.`
- [] intersection-category-desc: `The page includes a <code><DynamicPageList></code> tag`
- [] templatestyles-stylesheet-error-category-desc: `The TemplateStyles stylesheet has an error.`
- [] templatestyles-page-error-category-desc: `There was an error when processing a <code><nowiki><templatestyles/></nowiki></code> tag on the page.`
- [] massmessage-list-category-desc: `The page is a delivery list for the [[Special:MassMessage|MassMessage]] extension.`
- [] commonsmetadata-trackingcategory-no-license-desc: `The file does not have any [{{MediaWiki:Commonsmetadata-doc-url}} machine-readable] license template.`
- [] commonsmetadata-trackingcategory-no-description-desc: `The file does not have a [{{MediaWiki:Commonsmetadata-doc-url}} machine-readable] information template, or its description field is not filled out.`
- [] commonsmetadata-trackingcategory-no-author-desc: `The file does not have a [{{MediaWiki:Commonsmetadata-doc-url}} machine-readable] information template, or its author field is not filled out.`
- [] commonsmetadata-trackingcategory-no-source-desc: `The file does not have a [{{MediaWiki:Commonsmetadata-doc-url}} machine-readable] information template, or its source field is not filled out.`
- [] commonsmetadata-trackingcategory-no-patent-desc: `The file does not have a [{{MediaWiki:Commonsmetadata-doc-url}} machine-readable] patent template.`
- [] math-tracking-category-error-desc: `Pages in this category have errors in the usage of math tags.`
- [] math-tracking-category-render-error-desc: `Pages in this category have rendering errors in the math tags.`
- [] math-tracking-category-mhchem-deprecation-desc: `Pages in this category use a deprecated format of the chem tags`
- [] math-tracking-category-texvc-deprecation-desc: `Pages in this category use a deprecated format of the math tags`
- [] babel-template-params-category-desc: `The page passes a name=value parameter to the #babel parser function. The behavior of these parameters [[phab:T327847|may change in the near future]].`
- [] scribunto-common-error-category-desc: `There was an error when processing the modules included on the page.`
- [] scribunto-module-with-errors-category-desc: `The module has an error in it.`
- [] jsonconfig-use-category-desc: `These pages use the <code>mw.ext.data.get</code> method provided by the [[:mw:Extension:JsonConfig|JsonConfig]] extension. The <code>mw.ext.data.get</code> method is considered expensive.`
- [] phonos-tracking-category-desc: `The page uses the [https://www.mediawiki.org/wiki/Extension:Phonos Phonos] extension.`
- [] phonos-error-category-desc: `There was an error while rendering Phonos.`
- [] graph-tracking-category-desc: `The page includes a <code><graph></code> tag.`
- [] graph-disabled-category-desc: `The page includes a <code><graph></code> tag, which is temporarily not available ([[phab:T334940|T334940]]).`
- [] magiclink-tracking-isbn-desc: `This page uses ISBN magic links. See [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Magic_links mediawiki.org] on how to migrate.`
- [] magiclink-tracking-rfc-desc: `This page uses RFC magic links. See [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Magic_links mediawiki.org] on how to migrate.`
- [] magiclink-tracking-pmid-desc: `This page uses PMID magic links. See [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Magic_links mediawiki.org] on how to migrate.`
[[MediaWiki:Redirectedfrom]] says by default:
```
(Redirected from $1)
```
The `$1` is the source page of the redirect, enclosed in double brackets, which is then parsed as Wikitext. So, for example, if the page //Books// redirects to //Book//, the value of $1 is `[[Books]]`.
Two steps would improve this syntax:
- Change the value of $1 to remove the automatic [[]] from it,
- Change the default message to be:
```
(Redirected from [[$1]])
```
This would then allow the message to be customised. For example, if it's too prominent, it might be reduced to:
```
([[$1|↪R]])
```
or something similar, which would tell editors it's a redirect, without cluttering up the page. (Note MediaWiki pages tend to be very cluttery).
Exactly what the message should be and where it should go is up to debate, but first, the syntax needs to be fixed so that it then can be debated and improved.
It looks like it would need to be something like:
```
<span class="plainlinks">[{{fullurl:$1|redirect=no}} $1]</span>
```
It is not possible to translate this string into some languages without the use of plural and the knowledge of how many edits it is counting. In addition, there may be layout issues where the number needs to be in the middle of the string or missing from it for it to be correct in other languages. The issues I list below have come up in translations into the Saami languages, but they are not unique to these languages.
**Numerical issues**
- 0 edits: If a user has 0 edits, I have to be able to say "Not even one edit" without the number 0. As the string is right now, this is not possible at all and the result would be "0 Not even one edit" because of it. Using {{PLURAL}} in specific ways when translating MediaWiki Core, it is possible to bypass this issue, so assumedly using the same here would solve this.
- 1 edit: This uses a different grammatical case than 2-6 and 7+ (for Inari and Skolt Saami etc.)
- 2-6 edits: Different case than for 1 edit and 7+ edits.
- 7+ edits: Yet another case.
**Layout issues**
The layout issue comes up with the number needing to be in between the //total// and //edits// in these languages (and Northern Saami, which uses a different plural system of 0, 1, 2+). It is unnatural to say //15 000 total edits// in this exact order in these languages. As a result, the Northern Saami translators had to resort to saying //15 000 edits (total)// (using the wrong grammatical case because of a lack of plural support), which sounds like Google Translate got to it instead of actual translators.
These issues affect more than just the languages I translate into. For example, even in English, if someone has 1 total edit, it shouldn't read //1 Total edits//.
As a MediaWiki power user, I expect that I can use [safe mode](https://www.mediawiki.org/wiki/Manual:Safemode) (`?safemode=1` in the URL, or user preference) to be protected from any potential malicious on-wiki content that’s under the control of the interface admins. However, [raw HTML messages](https://www.mediawiki.org/wiki/Manual:$wgRawHtmlMessages) are currently not affected by safe mode, so they can still let an interface admin attack a user who is using safe mode. I propose that in safe mode we should try to make raw HTML messages safe, e.g. by running them through the sanitizer, or by not using the on-wiki messages at all (and falling back to the JSON files). This should probably be implemented in `Message`, checking whether the message key is in `$wgRawHtmlMessages`.
Steps to reproduce on your local wiki (preferably don’t try this out on any public wiki):
- In `LocalSettings.php`, set `$wgRightsPage`, `$wgRightsUrl` and/or `$wgRightsText` to nonempty strings, so that a copyright message will be shown
- Load a page with `?uselang=qqx` to see which copyright message is being shown (default `copyright`, but may be e.g. `wikimedia-copyright` if WikimediaMessages is installed)
- Override that message in the MediaWiki namespace to include something like `<span onmouseover="alert('hi!')">Hover me for an alert!</span>`
- Load a page with `?safemode=1` and hover over that text in the copyright footer
Expected result: no effect. Actual result: alert is shown.
**Feature summary** (what you would like to be able to do and where):
The `$wgTranslationAliasesDirs` global is marked as `@unstable EXPERIMENTAL` at the moment.
The work should be finished and the feature should be marked as stable and the experimental note should be removed.
**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):
Migration to the new format. Not supporting experimental formats for long.
**Benefits** (why should this be implemented?):
translatewiki.net support for special page aliases?
Implement language converter for Sindhi (`sd`).
* Perso-Arabic script (`sd-Arab`) => Devanagari script (`sd-Deva`)
* Devanagari script (`sd-Deva`) => Perso-Arabic script (`sd-Arab`)
On request from Dr. Soni Wadhwa
From https://www.w3.org/International/questions/qa-bidi-controls.en.html
> Unicode control codes are not useful for bidi formatting when working with structural or paragraph-level markup.
>
> For inline content we recommend that, wherever possible, you use markup in HTML and XML, rather than the Unicode control characters.
One practical reason for it is those control characters will end up in user text copy paste of typical users who are unaware and clueless and it breaks string matching logic. e.g. T27277
And bidi control includes many different characters (LRI, RLI, FSI, LRE, RLE, LRO, RLO, PDI, PDF) which all should be avoided but one main place generates them in MediaWiki is
* https://gerrit.wikimedia.org/g/mediawiki/core/+/0b58fa96021b833e172fd44016751819c09e9588/includes/language/Language.php#2978
https://codesearch.wmcloud.org/deployed/?q=getDirMarkEntity
* https://gerrit.wikimedia.org/g/mediawiki/core/+/0b58fa96021b833e172fd44016751819c09e9588/includes/language/Language.php#2996
https://codesearch.wmcloud.org/deployed/?q=getDirMark
We should reduce uses of them and eventually if there aren't any plain text uses of the methods, make them deprecated and remove them from MediaWiki or at least adding to their documentation that most of the time they should be avoided.
To help developers not familiar with bidi, what is the propose of such things in MediaWiki at the first place anyway? Consider the following, that $title can be a username or a page title with
`abc $title (123)`
If $title = 'title'; this will be turned into,
`abc title (123)`
but if $title = '1شسی'; the very same code results in
`abc 1شسی (123)`
Note where 123 has went, between parts of the title string! It's still logically after the $title but it's displayed before it because bidi algorithm is mislead and to solve this on plain text one can put a LRM which results in,
`abc ۱شسی (123)`
Which has the hidden character but if one copies the title it will contain the character which is undesirable so a better solution can be use of <bdi> which results in,
`abc <bdi>1شسی</bdi> (123)`
{F57569141}
which is good but the placement of that 1 is changed so the better solution would be to add dir="ltr" (the LTR or RTL here should match site or user language direction depending on the context, for page title of mono language wikis, better to wiki's content direction, for usernames however not user of enforcing any direction and letting default direction to be used can be better):
`abc <bdi dir="ltr">1شسی</bdi> (123)`
{F57569152}
For example in the use https://gerrit.wikimedia.org/g/mediawiki/extensions/ProofreadPage/+/c30b1e384ab694161fa10665636eb3f2f4c4349a/includes/Special/SpecialProofreadPages.php#357 just wrapping $plink with `<bdi>` should be enough.
Generally to understand and review these changes keep this rule of thumb in mind that whenever a user generated content such as username, page title, summary and content is used in one line with text and messages that are part of software UI of MediaWiki, those user generated content should be wrapped with <bdi>. It's like XSS and SQL Injection but for bidi and the antidote is an appropiate wrapping with HTML <bdi> tag. (but this is just a simplification with leaving some details out)
Also related suggestions from W3C to use HTML tag and attribute over CSS styles from https://drafts.csswg.org/css-writing-modes-3/
> Because HTML UAs can turn off CSS styling, we recommend HTML authors to use the HTML dir attribute and <bdo> element to ensure correct bidirectional layout in the absence of a style sheet. Authors should not use direction in HTML documents.
> Because HTML UAs can turn off CSS styling, we recommend HTML authors to use the HTML dir attribute, <bdo> element, and appropriate distinction of text-level vs. grouping-level HTML element types to ensure correct bidirectional layout in the absence of a style sheet. Authors should not use unicode-bidi in HTML documents.
**Steps to replicate the issue** (include links if applicable):
* Pass a syntactically invalid BCP 47 language tag to `mw.language.bcp47()` in Javascript.
*
*
A variety of examples:
```
mw.language.bcp47("a")
mw.language.bcp47("0")
mw.language.bcp47("a0")
mw.language.bcp47("ä")
mw.language.bcp47("-")
mw.language.bcp47("en-x-q1234567890")
mw.language.bcp47("en-g")
mw.language.bcp47("latn-gb")
```
**What happens?**:
The function returns the input.
If the output is then passed to `toLocaleLowerCase()`, it causes an error:
```
"text".toLocaleLowerCase("en-g");
Uncaught RangeError: Invalid language tag: en-g
```
```
"text".toLocaleLowerCase("ä");
Uncaught RangeError: Incorrect locale information provided
```
**What should have happened instead?**:
The function should return a valid BCP 47 language tag.
At the very least, it should return `und` if the input can't be a valid tag. A smarter option would be to repeatedly drop the last section after a hyphen until the result is syntactically valid, and only return `und` if that fails.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
There is a function to check whether something is syntactically valid at https://gerrit.wikimedia.org/g/mediawiki/core/+/master/includes/language/LanguageCode.php
== Acceptance Criteria:
* User sees more specific validation error details in the extension, rather than generic error messages.
* Error messages are localized in the user's language.
== Notes:
Validation errors in the extension return an error code, in addition to the message.
We can also pass a locale option when rendering the chart in the service. Perhaps this can be of some help with the error messages, as well.
`userrights-groups-help` feels a little out of date in our expiring userrights world.
```
You may alter the groups this user is in:
A checked box means the user is in that group.
An unchecked box means the user is not in that group.
A * indicates that you cannot remove the group once you have added it, or vice versa.
A # indicates that you can only put back the expiration time of this group membership; you cannot bring it forward.
```
>A * indicates that you cannot remove the group once you have added it, or vice versa.
Specifically this... Yeah, I can't remove it, but I can add it originally with an expiration date, for example...
After posting a message on enwiki, I got shocked by the "Your edit was saved" (or "published", I don't recall, I was so shocked) confirmation popup…
Present perfect would be much more adequate: "Your edit was saved." → "Your edit has been saved."
See [[ https://codesearch.wmcloud.org/search/?q=was+%28saved%7Cpublished%29&files=%5C.json%24&excludeFiles=%5Cbtests%3F%5Cb&repos= | Code search ]]. For instance:
* [[ https://gerrit.wikimedia.org/g/mediawiki/core/+/c22e07fd1eb845f40d7912f8d70cb101f2955c58/languages/i18n/en.json#766 | in mediawiki/core ]]:
```
"postedit-confirmation-saved": "[[Special:Diff/$2|Your edit]] was saved.",
"postedit-confirmation-published": "[[Special:Diff/$2|Your edit]] was published.",
```
* [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/40f85d8852b9c407d15d407103203e64c5bca76b/i18n/en.json#95 | in extensions/DiscussionTools ]]:
```
"discussiontools-postedit-confirmation-published": "Your comment was published.",
"discussiontools-postedit-confirmation-topicadded": "Your topic was added.",
```
There are two languages whose names appear incorrectly in the Developer Portal's language selector:
[x] pt-br: This is Brazilian Portuguese. In appears as "Português (brasil)". The word "Brasil" is a name of a country, and it's supposed to begin with a capital letter.
[] sh-latn: This is Serbocroatian written in the Latin alphabet. It appears as "Srpski (latinica)". The word "Srpski" means "Serbian". The Serbian language has its own code, "sr". Even though Serbocroatian and Serbian are more or less the same, when people use the "sh" code, I'm pretty sure that their intention is that the label will be "Serbocroatian" and not "Serbian". So it should be written as "Srpskohrvatski (latinica)".
I couldn't easily find in the code where do names of languages come from, so I'm reporting a bug.
**Steps to replicate the issue** (include links if applicable):
* Go to https://query.wikidata.org/querybuilder/?uselang=fa
* Scroll down to the footer
**What happens?**:
Wikidata Team Link to report a problem is not rendered as linked text, but as a URL.
{F57521659}
**What should have happened instead?**:
The Wikidata Team link should be rendered as a link with the text "در ویکیداده" that links to https://www.wikidata.org/wiki/Wikidata:Report_a_technical_problem. As in Arabic, Hebrew and English.
{F57521661}
{F57521663}
{F57521665}
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
Firefox 130 on Ubuntu 22.04
The Jawi script is a modified Arabic script used in the Malay language (ms_Arab). It is an abjad-alphabet hybrid, whereby it uses the base abjad system from Arabic, but applies certain alphabetic rules such as using certain vowel letters. It also modifies or repurposes certain letters for different usages, or add new variants to existing letters.
One of the main features of Jawi is its usage of the letter Hamza, which serves as a form of a utility letter rather than simply as a glottal letter as in Arabic. The most notable change is the addition of a new variant of the letter, known in Malay as "hamzah tiga suku/همزة تيݢ سوکو," which can be literally translated as "three-quarter hamza." For the purpose of this task, I will refer to the letter simply as "Jawi Hamza."[1]
The Malay name refers to the letter's visual feature, whereby it takes the form of a standard stand-alone hamza, but alters its vertical position whereby its baseline sits between three-quarter to half the height of alef, depending on scripture style.[2] This letter appears rather common in the Malay dictionary, as it serves multiple purposes, including as a glottal letter (similar but in a different manner as to Arabic) and vowel letter separator. This character has been in use in Malay writing for centuries, and is still used to this day.
As common as this character is, it has not been included in the Unicode Standard. In September 2021, the Kazakh high hamza (`U+0674`) annotation has been amended to include "Jawi" aside "Kazakh." However, the issue is that the Kazakh high hamza and the Jawi hamza do not share the same visual appearance nor attributes.
First of all, as visible in Kazakh writing,[3] the Unicode standard,[4] and how the character is depicted in most fonts (see Times New Roman, Noto Sans Arabic, Segoe UI, SF Arabic, and IBM Plex Sans Arabic, among others),[5] the Kazakh high hamza is of a smaller size in comparison to the regular hamza, and more similar to the size of a hamza above and hamza below (`U+0654` & `U+0655`).
The glyph is also commonly depicted as being higher than the vertical height of the Jawi hamza, sometimes even as high as the hamza from hamza above.[5]
In the Unicode Standard, it is said that the character "forms digraphs," which is not what the Jawi hamza does. The Jawi hamza is not entirely dependent on any other letter, and could appear in front, between, or after any letter, without the need for any other letter before or after itself. It also does not merge with any other letter as how some fonts depict (although some old manuscripts may depict it as if it merges with some letters, it only seems so due to calligraphic style, whereby some letters are stacked on top of each other to save space or look visually cleaner).
**It must be noted that in Jawi, the Jawi hamza must be depicted the same size as a regular hamza, with its baseline positioned between three-quarters to half the height of an alef.**[2]
The motion to propose the character to the Unicode Technical Committee (UTC) started in August 2008 during the Internationalized Domain Name Forum, when linguists found the lack of the character in the Unicode Standard while discussing its inclusion to the Jawi coded character set standard. It was proposed in 2009 that the character be proposed to the UTC, however, it is unclear whether the proposal was ever sent.
After the "Jawi" annotation was added to `U+0674` in 2021, a proposal to add the Jawi hamza was submitted by Karim et al. in 2022, where they described the difference between the Jawi hamza and the Kazakh high hamza. However, the Script Ad Hoc group (SAH) said that font designers are expected to either employ a language tag or create a Jawi-specific font. (Anderson et al., 2022)
We believe that **this is an inappropriate solution**, if it could even be considered a solution. It is akin to "employing a language tag or creating a Jawi-specific font" to display the character "Ǎ" as the character "Ă" when writing in Romanian, simply because a breve and caron looks nearly identical, or using the character "²" to display "2" because the earlier is just the smaller version of the same shape. This solution would also mean that it would be impossible to display the Jawi hamza in a text-only word processor such as text messaging applications where they only use one font. It would be even more technically disastrous to quote Kazakh and Jawi in one sentence without changing fonts for the specific word. This defeats the very purpose that the Unicode Standard was created to begin with.
Current temporary solutions for digital applications include various techniques of altering its visual appearance. One way is by creating a custom font, using an unused character which is depicted to look like the Jawi hamza.[6] This does mean, however, that when copying the text or when the font does not load, the original character would be seen in its place. Another way is to create a font that displays the regular Arabic hamza as the Jawi hamza in certain positions or when forced by a zero-width character, or displays the Kazakh high hamza as the Jawi hamza (Airaha, 2023). In this case, the character would be seen as a regular hamza or Kazakh high hamza when viewed without its font. Another way this is handled when writing on websites is to use a span class for the regular Arabic hamza to alter its vertical position, which allows it to remain the same even if any font fails to load.[7] However, it still does not work if the text is copied to another word processor. There are various other ways this is handled, each employing different workarounds that would not be compatible with platforms that do not support any customised formatting, whether through font or other features.
Therefore, we believe that the Jawi hamza deserves its own character code in the Unicode Standard, separate and disunified from `U+0674` (the Kazakh high hamza) and independent from `U+0621` (the regular Arabic hamza).
**Note:**
# In English, the character has been referred to by multiple names. Khalid (2009) used "Jawi Letter Hamzah Three Quarter." Karim et al. (2022) used "Arabic Letter Three-Quarter High Hamza." However, we propose to use either "**Arabic Letter Jawi High Hamza**" or "**Arabic Letter Jawi Hamza**" as how the characters `U+06C5` and `U+06CC` use "Arabic Letter Kirghiz Oe" and "Arabic Letter Farsi Yeh" respectively.
# Refer to Figure 1
# Refer to Figure 2
# Refer to Figure 3
# Refer to Figures 4.1 & 4.2
# Refer to Figure 5
# Refer to Figure 6
**Figures:**
Figure 1 - Snippet from Ahmad (2015), which says "the hamza letter like above, must be written at the level of the middle or three-quarters of the height of the letter alef. Its size must be big."
{F57512789}
Figure 2 - Excerpts from Kazakh text showing the Kazakh high hamza in use. The top picture is from a Kazakh-language edition of the Best Chinese short stories of 1978, while the bottom is from a Kazakh edition article from People's Daily.
{F57512838}
Figure 3 - The Unicode 16.0 chart depicting `U+0674` as smaller than `U+0621`, making it impossible to be used for the purpose of the Jawi hamza. The red lines indicate the heights of `U+0674` and `U+0654` which are the same, whereas the blue lines indicate the height of `U+0621` which should be the height of the Jawi hamza.
{F57512841}
Figure 4.1 - Current state of Kazakh high hamza in most fonts, making it unusable for the purpose of the Jawi hamza.
{F57508822}
Figure 4.2 - How the Jawi hamza should look like in these fonts.
{F57508821}
Figure 5 - The implementation of the Jawi hamza on the web version of Utusan Melayu, a defunct section of the Utusan Malaysia newspaper. Notice the usage of an unused character (`U+FBB6`) in place of the Jawi hamza as seen in the source code.
{F57512791}
Figure 6 - The implementation of the Jawi hamza on Wikipedia, where the regular hamza is encased in a span box which has been specified to be positioned higher.
{F57512793}
Figure 7 - Dahaman & Ahmad (1988) explaining the usage of both the Jawi hamza and the regular hamza. This shows that both characters are not interchangeable and that there is a clear difference between them in function and purpose.
{F57512795}
Figure 8 - Kasim (2019), a Jawi text book, showing the five different types of hamza in Jawi. From right to left, the third is the Jawi hamza and the fourth is the regular hamza (alef is written for height reference). Notice that they are placed separately.
{F57512797}
Figure 9 - Kasim (2019), a Jawi text book, showing some of the unique usages of the Jawi hamza
{F57512799}
Figure 10 - Kasim (2019), a Jawi text book, instructing the student to transliterate two excerpts from Latin to Jawi. The exercise requires the differentiation between a regular hamza and a Jawi hamza as it uses both.
{F57512824}
Figure 11 - An excerpt from Tarmizi (2019), which is a news article on Utusan Malaysia, showing some of the recent usages of the letter on print media.
{F57512801}
Figure 12 - An old family tree, estimated to be from around the 18-19th century, of the Tok Masjid family. The name of the family itself in Jawi (توء مسجد) requires the usage of the Jawi hamza, but can only be written using the regular hamza as of now.
{F57512803}
**Reference:**
- Ahmad, A. (2015). //Kaedah Pembelajaran Jawi : Peringkat Asas [Jawi Learning Method : Basic Level]//. Kuala Lumpur (Malaysia): Perpustakaan Negara Malaysia. ISBN 9789679312607.
- Airaha, N. (2023). //ڤاسوان جاوي [Jawi Fonts]//. https://www.behance.net/gallery/175362647/Pasuan-Jawi
- Anderson, D. et al. (2022). //Recommendations to UTC #171 April 2022 on Script Proposals//. https://www.unicode.org/L2/L2022/22068-script-adhoc-rept.pdf
- Dahaman, I. & Ahmad, M. (1988). //Daftar Ejaan Rumi-Jawi [Rumi-Jawi Spelling Directory]//. Kuala Lumpur (Malaysia): Dewan Bahasa dan Pustaka. ISBN 9789836200273.
- Karim, A. A. K. et al. (2022). //Proposal to Encode ARABIC LETTER THREE QUARTER HIGH HAMZA for Jawi//. https://www.unicode.org/L2/L2022/22051-jawi-hamza.pdf
- Kasim, H. (2019). //بوکو تيکس جاءيس جاوي تاهون 4 [Year 4 Jawi JAIS Text Book]//. Seri Kembangan (Malaysia): Jabatan Agama Islam Selangor. ISBN 9789671650004.
- Khalid, N. H. (2009). //Report for Malaysia’s Internationalized Domain Name: Jawi Language Issues//. MYNIC Berhad. https://github.com/EmpAhmadK/jawi/blob/main/%D9%84%D8%A7%DA%A4%D9%88%D8%B1%D9%86%20%D8%A7%D8%A1%D9%8A%20%D8%AF%D9%8A%20%D8%B9%D9%8A%D9%86.pdf
- Tarmizi, Z. W. A. (2019). //برسندر باکت [Dependent on Talent]//. Utusan Malaysia.
- Unicode Consortium (2024). //The Unicode Standard, Version 16.0//. https://www.unicode.org/Public/16.0.0/charts/CodeCharts.pdf
What is meant by "expeditures"? This seems to be a typo in the original text in my opinion.
----
**Message URL**: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=tracker-5822de-Total_expeditures&group=wmcz-tracker-django&language=en-gb
**Issue**:
- **Brackets/Square Brackets**
{F57395571}
- **Directionality**
{F57395624}
**Anticipated**:
{F57395815}
**Optional highlights:
**{F57395651}
**Not important** (Just //Kaizen//):
{F57395744}
{F57395747}
XTools version: 3.20.1-55b74d0d
**Steps to replicate the issue** (include links if applicable):
* Open https://query.wikidata.org/
* Set the interface language to `zh-tw`
* Refresh the page to make sure everything is using the right language
* Open the examples dialog
**What happens?**:
The examples are displayed in English.
**What should have happened instead?**:
The examples should be displayed in Chinese (at least the first 15 on https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/queries/examples/zh are translated).
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
In the code, it first tries to fetch the subpage for the current language, and then falls back to the base page:
https://gerrit.wikimedia.org/g/wikidata/query/gui/+/master/wikibase/queryService/api/QuerySamples.js#39
Using "Special:Mylanguage/Wikidata:SPARQL_query_service/queries/examples" as the page and `uselang=zh-tw` seems to return the page in Chinese:
https://www.wikidata.org/wiki/Special:ApiSandbox#action=parse&format=json&uselang=zh-tw&page=Special:Mylanguage%2FWikidata:SPARQL%20query%20service%2Fqueries%2Fexamples&redirects=1&prop=text&wrapoutputclass=&disableeditsection=1&disabletoc=1&formatversion=2
I usually use Wikifunctions in Hebrew. When I publish a page with an internal link, e.g. `[[Z18784]]`, the following things happen:
# The target URL is https://www.wikifunctions.org/view/he/Z18784
# The link text shows the Hebrew label of the function.
Those two things persist even in the following conditions:
* I open the page anonymously. The UI language is English, but the target URL still has /view/he/, and the shown title is in Hebrew, even though the function has an English label.
* I change my UI language in the preferences. The rest of the UI language changes to what I selected, but this link's target URL still has /view/he/, and the shown title is in Hebrew, even though the function has an English label.
* Another user who has a different UI language opens the page.
It changes if I change my UI language and open the page with ?action=purge even without publishing a new version, so it's not necessarily the last //editor//'s language, but the last //purger//'s language.
Such behavior is generally undesirable. From the general point of view of functionality, the link should work in the page's content language or in the reader's UI language. Doing it in the language of the last user who published or purged the page makes no sense.
It is also a bit of a privacy problem—I make no secret of the fact that Hebrew is my language, but it's a personal user preference, and some users may want to keep that information private.
Possibly related:
* {T359772}
* {T372684}
See the screenshot:
{F57278034 size=full}
To get here, go to https://www.wikifunctions.org/view/he/Z18785 (it's supposed to be all in Hebrew), and click on פרטים (details) in the מימושים (Implementations) box.
"Duration", "CPU usage", and "Memory usage" are shown in units of ms and MiB. Because of the general RTL orientation of the page, the unit appears on the left side of the number, which is wrong. The correct options would be:
* To show it with units in English, but to force its container to `dir="ltr"` (or `dir="auto"`, which produces the same result in practice).
* To allow the translation as messages: "$1 ms", "$1 MiB". (They can be optional.)
Diffs on mobile are using messages such as [[https://translatewiki.net/wiki/MediaWiki:Group-sysop/en|MediaWiki:Group-sysop]] as an user rights indicator, which is in plural form. In Azerbaijani language, the plural form of user groups here does not sound right and should be replaced with singular form. After discussing this with some users on the translatewiki.net telegram group, they agreed with me. We have messages like [[ https://translatewiki.net/wiki/MediaWiki:Group-sysop-member/en | MediaWiki:Group-sysop-member ]], I think we can replace that with this messages.
{F57274358}
First of all, this isn't a recent regression as we didn't change the related styles yet. And I was going to put such change on hold as the browser support but just learnt it's actually broken and is what we need now,
**Steps to replicate the issue** (include links if applicable):
Open [this link](https://fa.wikipedia.org/w/index.php?title=ویکی%E2%80%8Cپدیا:قهوه%E2%80%8Cخانه/فنی&oldid=40039730#Dark_mode_for_logged-out_users_coming_soon!)
**What happens?**:
Default thumbnail (without left or right) doesn't respect the direction
{F57267272}
It doesn't even respect mw-content-ltr class as above message wiki code is `<div lang="en" dir="ltr" class="mw-content-ltr">` and even though the MediaWiki code has seemingly mw-content-ltr support, https://github.com/wikimedia/mediawiki/blob/99ef4cadf26f07c0ec43727b325494150073cb6b/resources/src/mediawiki.skinning/content.media-common.less#L10 as it doesn't have nested direction (.mw-content-ltr .mw-content-rtl) it doesn't actually work and adding that isn't easy because the other styles (left, right) should be updated with more specificity hacks.
**What should have happened instead?**:
It should consider direction around the content
And actually it already [works in the mobile view](https://fa.m.wikipedia.org/w/index.php?title=ویکی%E2%80%8Cپدیا:قهوه%E2%80%8Cخانه/فنی&oldid=40039730#Dark_mode_for_logged-out_users_coming_soon!) because it already has [a similar change](https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/1057898) I'm going to upload the fix for MediaWiki core.
{F57267344}
Even the fact the fix isn't covering all Grade A we support, it's already broken for all the browsers right now and the fix will actually makes it at least work on the newer browsers.
But there is a downside to this change, users who logged in and changed the language of the interface to use RTL interface in LTR interface and vice versa but use older browsers, this degrades the support for them but makes it for example work for a wider user base I believe who see MassMessage messages in the Village Pump so there is a trade off here which I believe it worths it but you can have a different view which makes the issue still valid but may the solution not.
The wiki code I'm using to test this locally in a RTL (`$wgLanguageCode = 'fa';`) wiki,
```
<div dir=ltr>
== Test ==
[[File:A.png|thumb]]
Abc
</div>
<div style="clear: both"></div>
<div class="mw-content-ltr" dir=ltr>
== Test ==
[[File:A.png|thumb]]
Abc
</div>
<div style="clear: both"></div>
<div dir=ltr>
== Test ==
[[File:A.png|thumb|left]]
Abc
</div>
<div style="clear: both"></div>
<div class="mw-content-ltr" dir=ltr>
== Test ==
[[File:A.png|thumb|left]]
Abc
</div>
<div style="clear: both"></div>
<div dir=ltr>
== Test ==
[[File:A.png|thumb|right]]
Abc
</div>
<div style="clear: both"></div>
<div class="mw-content-ltr" dir=ltr>
== Test ==
[[File:A.png|thumb|right]]
Abc
</div>
```
**Steps to replicate the issue** (include links if applicable):
* Search for a word which appears on a translatable page which has lots of translations
*
*
**What happens?**:
The search results are filled with translations of the same page, which makes it hard to find what you are looking for.
Examples:
https://www.wikidata.org/w/index.php?search=merge&ns12=1 has a link to Help:Merge and 19 translations of it. The second page of results has another 20 translations of it. The third page of results has another 18 translations and only two other pages.
https://www.wikidata.org/w/index.php?search=redirect&ns12=1 has a link to Help:Redirects, 18 translations of it and only one other page.
**What should have happened instead?**:
Translatable pages should be collapsed into a single result (the link could use `Special:MyLanguage/`) and/or translations in languages which are not the interface language (or one of its fallback languages) should be ranked much lower.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
**Steps to replicate the issue** (include links if applicable):
* Go to https://www.wikidata.org/wiki/Lexeme:L1883?uselang=he#F15
* Look at the text of the form.
**What happens?**:
The text of the form looks like "m’": the letter m on the left and the apostrophe on the right.
**What should have happened instead?**:
The text of the form must look like "’m": the apostrophe on the left and the letter m on the right.
**Other information** (browser name/version, screenshots, etc.):
The reason for this is that this is English text embedded into a Hebrew page. The lang attribute is marked correctly as "en" in `<span class="representation-widget_representation-value" lang="en">’m</span>`, but the dir attribute is needed, too.
* `nan-Latn-pehoeji` : `Bân-lâm-gú (Pe̍h-ōe-jī)` # Minnan (Pe̍h-ōe-jī)
* `nan-Latn-tailo` : `Bân-lâm-gú (Tâi-lô)` # Minnan (Tâi-lô)
As a user, it is difficult to find the right element to configure in CC, as the interface translation is not the same between the extension shown to users and the community configuration.
For instance, Growth suggested edits "Expand short articles" is translated as follows in French:
- in community configuration: [[https://translatewiki.net/wiki/MediaWiki:Growthexperiments-homepage-suggestededits-tasktype-label-expand/fr|Développer des articles courts]]
- in suggested edits extension: [[ https://translatewiki.net/wiki/MediaWiki:Communityconfiguration-growthsuggestededits-expand-label/fr | Enrichir des articles trop courts ]]
The overall concept is respected but it is not a perfect match. Ideally, the same title should be used on both.
**Steps to replicate the issue**:
In the browser console add the following:
* `mw.messages.set('foo', '[foo] <br/> [https://translatewiki.net/ link]');`
* `mw.message('foo').parse()`
**What happens?**:
It returns the string `[foo] <br/> [https://translatewiki.net/ link]`,
and there is a jQueryMsg warning: `mediawiki.jqueryMsg: foo: Parse error at position 0 in input: [foo] <br/> [https://translatewiki.net/ link]`
**What should have happened instead?**:
There should be no warning and the message should have been properly parsed as something like `[foo] <br/> <a href="https://translatewiki.net/" class="external">link</a>`
**Other information**:
* Thanks to @Kgraessle for noticing this bug, and thanks to @Urbanecm_WMF for figuring out the minimal reproducible example.
Visual Editor has a inline (<span>) style for language and directionality, under the "character formatting" menu, but this inserts <span> tags around the selected text and doesn't help when writing longer texts, for example when writing an English message (LTR) on a Hebrew Wikivoyage message board (RTL).
It would be nice to add a "language block" item under the "insert" menu, which would work like either the "code block" item works, or (better) like "blockquote" works. "Like code block" would pop up a separate editor dialog for the "english" text, while "like blockquote" would let you edit the english language text in-place, ideally using the same light-blue background that the inline/<span> language style uses in order to identify the paragraph as being different from the surrounding text.
The important thing is that the editor should actually switch directionality for this block, so that the text you write is properly justified (RTL/LTR).
**Steps to replicate the issue** (include links if applicable):
* Open an item on Wikidata using the Dutch language that has a MUL value, or add MUL to your babel user page template. For example: https://www.wikidata.org/wiki/Q2013?uselang=nl
* (Open all entered languages in the termbox and) search for "standaardwaarden voor alle talen" (MediaWiki:Wikibase-language-name-for-terms-mul/nl) on the page
**What happens?**:
Notice that the text is overflowing with the label.
{F56770713}
**What should have happened instead?**:
The termbox should handle cases where languages or labels in the same space contain long words, either by applying automatic hyphenation (which also applies useless hyphenation at moments) or extending the width of the first column. The latter might be a better choice with also the introduction of font sizes in Vector 2022.
This could also be solved with a soft hyphen in the translation but this is not a common practice and has several downsides.
The mobile version of the termbox uses flexbox so it doesn't have this issue, it does cause a long column width on the tablet view.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
T287701 gives the context but I'll give a short context also,
`mw-content-{ltr,rtl}` initially was helping users having e.g. English language as their interface, to surf in sites with content RTL content sites such as Persian Wikipedia, but now with the presence of CSS Logical https://drafts.csswg.org/css-logical/ and https://developer.mozilla.org/en-US/docs/Web/CSS/:dir it's almost provides no value.
Primarily use was bullets of one text direction to be shown in the opposite direction which is taken care in T369475 using CSS Logical
So now it's time to get rid of it altogether and as it's deprecation in T287701, starting with this https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1057857 which removes most of the uses.
And the next step, in mid ranged future, will be to use CSS Logical all around and remove CSS Janus from MediaWiki eventually but that needs edits in template styles which will take years.
Short, technical investigation of potential issues with the RTL behavior of subreferencing in read mode and in the visual editor.
== General Cite issues
Taking the source wikitext `One<ref>one</ref> Two<ref>two</ref>` on a RTL content language, the following strange effects appear:
* Source editor moves an angle bracket, and will also move slashes between tags for unknown reasons:
{F56815142}
* Copy-pasting the source out of the editor shows text with correct angle brackets, so the issue is caused by something in our editor presentation.
* Legacy parser seems to move the last ref to the other end of the line, but not others. This leads to a disconnect between citations and their statements:
{F56815150}
* $wgTranslateNumerals is not respected for the reflist, so the legacy parser outputs mismatched markers:
{F56815176}
* Parsoid doesn't respect `$wgTranslateNumerals` (because it's based on non-dynamic CSS), and has the same issues with references appearing away from their text:
{F56815209}
== Subref-specific issues
* It's unclear which direction the numbers should run in. Numerals run LTR but major, minor might read better when flipped. Currently looks like this, which also matches the direction of backlink strings:
{F56763600}
{F56815598}
* Subref separator should be customizable.
== Verified good
* Can use right and left arrows to traverse across footnote marker in article content, despite RTL/LTR text direction.
Many of the above issues are caused by mixed LTR and RTL content, and go away when using exclusively RTL content: `واحد<ref>واحد</ref> اثنين<ref>اثنين</ref>`
* Source editor shows angle brackets in the correct placement,
{F56815464}
* Refs are adjacent to the correct statements in VE, legacy parser output, and Parsoid output:
{F56815487}
* Behavior is similarly reasonable if the ref has LTR content, but article text is RTL: {F56815687}
== Summary
* Subrefs don't seem to present any new problems (major/minor number order is already visible in backlinks)
* Cite refs behave reasonably, unless the article content is actually LTR on an RTL wiki.
* `$wgTranslateNumerals = false` is not being respected at all by Parsoid, and only half-respected by the legacy parser. In production this must be worked-around with custom CSS rules.
== Questions
* What should be done when a main ref has a different `dir` attribute than the sub-ref linking it, do we need to add special support for that use case?
# Go to https://www.wikifunctions.org/view/dv/Z17703.
# The function name is not translated into Divehi (dv), so it appears with a language indicator, "en" in a gray circle.
# The indicator is supposed to appear in the beginning of the header. By the RTL logic, the beginning is the top right corner. Actually, it appears in the end of the header, on its leftmost end.
# The ZID is supposed to appear in the end of the header, but it appears in the beginning.
To resolve this, I suggest the following simple thing:
# Add `lang="en" dir="ltr"` to the language indicator (`class="ext-wikilambda-viewpage-header--bcp47-code"`)
# Add explicit `lang` and `dir` attributes to the function name (`class="ext-wikilambda-viewpage-header-title ext-wikilambda-viewpage-header-title--function-name"`). The language code is supposed to be known because it appears in the indicator, and the direction can be deduced from the language code.
# Add `lang="en" dir="ltr"` to the ZID (`class="ext-wikilambda-viewpage-header-zid"`).
The explicit `dir` attributes will bidi-isolate the elements and put them in the correct order, and will also ensure the correct display of each headers in terms of direction.
**Background:**
* Tools have lagely moved from http://tools.wmflabs.org/guc/ to http://guc.toolforge.org/
* The Intuition portal also moved from http://tools.wmflabs.org/intuition/ to https://intuition.toolforge.org/
* Finally, the `.toolforge.org` domain became its own "public suffic" in browsers via <https://publicsuffix.org/>. This was done for security reasons and is largely a Good Thing (TM).
The impact of this is that choosing a central language, even though it may try to set a cookie for all of `tools.wmflabs.org` and `*.toolforge.org`, in practice is has no effect and thus tools are left with no way to actually localise themselves unless they present their own UI for selecting language, saving cookies, reading cookies, and then passing the cookies to the Intuition library. Alternatively, they can use query parameters and require users to re-select their language every time they use a given tool.
**Objective:**
Make the portal work again. Using the tool <https://orphantalk.toolforge.org/> as examples to make work:
1. <https://orphantalk.toolforge.org/> -> "Change language" -> come back, the selected language should work.
2. Following a permalink like https://orphantalk.toolforge.org/?wiki=commonswiki&ns=1 should use your last-selected language.
This shoudl require no modifications to individual tools. Possibly we can require them to update to a newer version of the `intuition` PHP package, but no updates to the tool source code or the Intuition package API. This way we can ensure widespread adoption.
**Approach:**
The "Change language" link already tells the portal where it came from. What we can do is, pass on a URL query parameter like `userlang` to set the language for that page view, along with a (new) query parameter like "_intuition_savelang=1" that will save a cookie local to that tool's subdomain.
Both parameters would be transparently handled by the Intution library. Possibly we can also issue a redirect to the current url with these parameters stripped, to leave the user with a clean (and sharable) address.
We have precedence for reading and acting on the global request context, through the `userlang` parameter which does the same thing. We also already offer a way to turn this off via `new Krinkle\Intuition( [ 'param' => false ])` and `Intuition->setUseRequestParam(false)`. We can use this mechanism to change the "Change language" link, to signal to the central portal whether a tool supports this. I.e. if it doesn't, it can display a warning instead, pointing back to this task (or a Gerrit link showing an in-repo Markdown guide).
We may even want to show the warning by default for existing tools using a current or older version, since it already doesn't work today. I.e. navigating to the Intuition portal with `returntoquery` but without some new query parameter, would display the warning by default.
**Feature summary** I would like a version of `{{int:Wm-license-pd-author-self-text}}` which incorporates the author's name, analogous to `{{int:Wm-license-pd-author-with-author-text}}`. I suggest the name `{{int:int:Wm-license-pd-author-self-with-author-text}}` because it seems reasonable. The English text should be something along the lines of
> I, $1, the copyright holder of this work, release this work into the public domain. This applies worldwide.
**Use case(s) and benefits** This request was prompted by a [[ https://commons.wikimedia.org/wiki/Commons:Bots/Work_requests#Remove_extraneous_%22I%2C_%22_in_author_param_of_PD-self | discussion ]] on Commons of [[ https://commons.wikimedia.org/wiki/Template:PD-self | Template:PD-Self ]], which uses `{{int:Wm-license-pd-author-self-text}}` if no author parameter is provided and `{{int:Wm-license-pd-author-with-author-text|{{{author}}}}}` if the author's name is provided. Several contributors feel that it is confusing that the template is not in first person when an author name is provided, especially since the template //is// in first person when there is no author name.
This has also led to a large number of files which invoke the template as
```
{{PD-Self|author=I, [Author Name]}}
```
which in English results in
> This work has been released into the public domain by its author, I, [Author Name]. This applies worldwide.
and (for example) in Spanish results in
> Este trabajo ha sido liberado al dominio público por su autor, I, [Author Name]. Esto aplica para todo el mundo.
I would like to be able to address users' desire for consistent first-person verbiage in the template in a way that produces grammatical results, is robust to changes in the text, and is internationalized.
**Other notes** I hope this is the correct venue for this request. I'd also like to note that I have an account on Translatewiki and will be happy to translate this text into the languages I know.
#### Problem:
In Mediawiki, we represent timezones based on location, such as "America/Los Angeles" for Pacific Standard Time. The problem is that these timezone locations are only partially translatable. The continent is translatable, but any country or city information is not. This creates a user problem for those who are not familiar with English city/country names and Latin script. Examples of when users select timezone are in Special > Preferences > Appearances > Time Offset and when users see information about an event time via Event Registration workflows (in the event registration header, in the 'more details' modal, in EventDetails, etc). We should find a way of fixing this, so that the full timezone information can be translated. Otherwise, we are providing a subpar experience for many people, as they may have difficulty adjusting their preferred timezone in Preferences and/or understanding the timezone of an event that they would like to join.
#### Proposed solution:
* Make timezone location translatable
#### Visual examples:
Example of timezone in Preferences:
{F57729704}
Example of timezone in event registration:
{F57729684}
The Label component has an optional flag that can be placed next to the label. In English, it takes the form "Label text (optional)". To achieve this format, we've added a space in the Vue component after the label text, and set the `cdx-label-optional-flag` message in MediaWiki core to "(optional)".
As @Tacsipacsi pointed out in [[ https://gerrit.wikimedia.org/r/c/design/codex/+/1051451 | this patch ]], that space isn't appropriate in every language, e.g. Chinese. We should change the message to include the space, and to include the label text as a parameter for easier translation. In English, the message text would be:
```
"$1 (optional)"
```
Then, we'd need to update the prop in the Field and Label components to account for this, remove the space in the Label template, and update the code that gets the translated string for the optional label.
This would be a breaking change for those already using the `optionalFlag` prop. We have 2 options:
1. Wait until Codex 2.0 to make this change
2. Make the optional flag a non-customizable string. We debated, when making the i18n changes, whether the optional flag needs to be customizable, and ended up making it so. If we change it to being static, we can use the `optionalFlag` prop only to turn on the optional flag for now, remove it with Codex 2.0, and use the new format within the Label component.
---
### Acceptance criteria
- [] Determine how to make this change
- [] Update the optionalFlag prop in Field and Label
- [] Update the Label template
- [] Update the Label logic to get the translated string
- [] Update the message in MediaWiki core
We've hardcoded messages and formatting specific to the sub-referencing feature. These all need to become proper i18n messages, and some of the formatting such as the numbering separator needs to become localizable.
See the backlink separator solutions, which we might want to remain consistent with.
The "Function explorer" panel on an implementation page such as https://www.wikifunctions.org/view/en/Z12592 - it shows information only about this particular function, right?
When I translated the message with its title, I translated "Function" in the plural, because an "explorer" is often a thing that shows multiple things.
I wasn't the only one: https://translatewiki.net/w/i.php?title=Special:Translations&message=MediaWiki%3AWikilambda-function-explorer-title%2Fhe
Perhaps it could have a better title? I updated this message's qqq documentation to say that it's just one function, but it should probably be changed completely. It's not very good in English to begin with.
Perhaps it could be something like "Function overview" or "Function structure"?
Or maybe this title could be discarded completely, and the panel could be unified with the "About" panel above it.
Or at least...better? Usable? Slightly less horrible?
There are many, many issues with the country selector, which allows users to select their home country and/or current country (and in the case of the US, state for both as well) to be displayed on their social profile page:
1) the list of countries is stored as an i18n msg (`userprofile-country-list`) but this msg is intentionally ignored on TWN, meaning that it's not i18n-able, and thus e.g. Finnish users will see "United States" instead of "Yhdysvallat"
2) the list of countries is outdated as hell, probably dating back to 2006 or so; e.g "Serbia and Montenegro" hasn't been a country since 2006, rather they're two separate countries these days; the [[https://en.wikipedia.org/wiki/Dissolution_of_the_Netherlands_Antilles|Netherland Antilles were dissolved in late 2010]]; etc.
3) the country value (e.g. "Serbia and Montenegro", "United States", "Netherland Antilles") is stored as-is in the DB (`up_location_country` and `up_hometown_country` fields in the `user_profile` table) instead of a nice [[https://en.wikipedia.org/wiki/ISO_3166|ISO 3166]] code or somesuch
As a tangentially related issue, the US state selector is indeed very US-specific (and for most non-US countries, "region" or "administrative subdivision" etc. is a rather irrelevant thing anyway) and it has one hard-coded English string (`State`). Also, the date format used for the user's birthday field (`mm/dd/yyyy` or `mm/dd`) is very American as well. (The latter is mostly just a display issue anyway since a more international value is saved to the DB. Also not really related to countries or states but more of a generic i18n issue, but I happened to notice it anyway while having the file open.) This relates to the file `/extensions/SocialProfile/UserProfile/resources/js/UpdateProfile.js`, which is a part of the `ext.userProfile.updateProfile` RL module.
Gerrit change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1046604 reverted a previous change in this message: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1038906 . (This was probably done unintentionally.)
The message communityconfiguration-mentorship-info-text, as it is now, has several issues with style and consistency:
* [[ https://en.wikipedia.org/wiki/Comma_splice | Comma splice ]].
* Usage of an internal English title of a special page instead of a translated and human-readable name.
* Inconsistency in the first sentences.
**Feature summary**:
Similar to existence of `skin-invert` and their use in `[[File:Example.png|class=skin-invert]]` syntax to invert color of a picture on night mode, it will be nice if there was some class for image that could mirror a picture using the brand new `class=` syntax in the images.
**Use case(s)**:
If such a thing existed in Persian Wikipedia we could mirror the icon used in this message box https://fa.wikipedia.org/w/index.php?title=الگو:منابع_نامعتبر&oldid=36224979 by just adding `class=mw-mirrored` which currently we have to upload a mirrored icon to make it work.
**Benefits**:
Wikihiero has such a thing called, mw-mirrored and https://github.com/wikimedia/mediawiki-extensions-wikihiero/blob/2df7f7e/modules/ext.wikihiero/content.css#L23-L25 so maybe we can just move that class from the extension to MediaWiki so it can be used for broader use.
In Android something similar is called autoMirrored, https://developer.android.com/reference/android/graphics/drawable/VectorDrawable which mirrors an icon in languages that have RTL scripts.
There is a slight difference between autoMirrored and mirror as that auto-prefix refers to mirror to happen only in RTL context and without that prefix it means to always happen, I'm personally not sure which one suits more but I can just moving the one in the extension to the core which is enough for the mentioned use should be good.
When the localization of core MediaWiki into a language on translatewiki.net passes a certain threshold (currently set to 13%), the translations begin to be exported to the core source code repo. However, to actually make it work, some more steps are needed. Most notably, this means adding the language to Names.php in core, removing it from translatewiki configuration, and possibly writing some more configuration with languages with particular fonts, etc.
The actual adding is most often done by myself (@Amire80) or by @jhsoby, and occasionally by other people.
The process is documented at https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages . Although it's really not complicated, it's nevertheless longish and manual, and this error-prone and a bit time-consuming.
Given that other than the language name ("autonym") and some advanced configuration, the process is mostly predictable, it can be at least partly automated. I wrote an initial simple script that does the main steps, and it can probably be improved further. This should make the process more automatic, quick, and doable by more people.
This checklist shows the progress of implementing the features, and it's roughly the same as the boilerplate in https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages :
[ ] Verify autonym correctness in language-data
[ ] Add to Wikifunctions's language list in function-schemata (optional in the initial version, given that Wikifunctions is a bit complex and stil new)
[ ] Add to `includes/languages/data/Names.php`
[ ] Add to RELEASE-NOTES
[ ] Set fallback if needed
-- [ ] In core (`languages/messages/Messages*.php`)
-- [ ] In jquery.i18n (`src/jquery.i18n.fallbacks.js`)
-- [ ] Remove fallback gender aliases if needed
[ ] Set rtl if needed
-- [ ] In core (`languages/messages/Messages*.php`)
-- [ ] In MobileFrontend (`src/mobile.languages.structured/rtlLanguages.js`)
[ ] Add namespace translations
-- [ ] Add gender aliases if needed
-- [ ] Check that namespace translations don't conflict with language codes
[ ] Add $linkTrail
[ ] Add date formats (if needed)
[ ] Add digit conversion (if needed)
[ ] Define wider line-height in `resources/src/mediawiki.skinning/i18n-headings.less` (if needed)
[ ] Remove the language from Wikibase and WikibaseLexeme (if needed)
[ ] Remove from translatewiki after deploying the core change
-- [ ] `mw-config/LanguageSettings.php`
-- [ ] `mw-config/FallbackSettings.php`
[ ] Test language search in UniversalLanguageSelector and fix the search index (if needed)
There are two languages whose name in MediaWiki is similar to "Kurdi": one with the code `ku` and the other with the code `ckb`.
`ckb` is all in the Arabic script. According to ISO 639, it's Sorani Kurdish (کوردی سۆرانی), but its name in MediaWiki is just "کوردی", which is pronounced "Kurdi" and means just "Kurdish".
`ku` is written in the Latin alphabet by default, and most of the content in the Wikipedia in this language is written in the Latin alphabet, but it also has script conversion to Arabic. When it's written in Latin, it's called "kurdî" or "kurdî (latînî)", and when it's written in Arabic, it's called "کوردی (عەرەبی)", which means "Kurdish (Arabic)". The first word here is the same as the name of ckb. If I understand correctly, this language is actually Kurmanji, which has its own code `kmr`, while `ku` is a macro code for all Kurdish varieties. According to Ethnologue, the name of this language in itself is "Kurdî-Kurmancî" or "Kurmancî".
There is also the language with the code `sdh`. There is no full-fledged Wikipedia in it, but only an [[ https://incubator.wikimedia.org/wiki/Wp/sdh | Incubator ]]. It is, however, already supported in MediaWiki, and it has the name "کوردی خوارگ"—the first word here is "Kurdi", and the second is unique to this language, so there is no ambiguity with it.
This is my understanding of facts till now. If I am incorrect about anything, please correct me.
Now, I'd like to make a careful suggestion: can `ku` and `ckb` be renamed from just "Kurdi" (in different alphabets) to a name that makes them clearly unambiguos? The most sensible thing to me is to call `ckb` "کوردی سۆرانی" and to call `ku` "Kurdî-Kurmancî" or maybe "Kurdî Kurmancî", whatever is more correct in terms of this language's standard punctuation. I think that this is sensible because it clearly shows that both of them are Kurdish, but includes another word that helps people distinguish them clearly, without possible confusion. This will also make the consistent with the name of `sdh`, which begins with the word "Kurdi" and continues with a unique name.
(We should probably also change the code of `ku` to `kmr`, but for technical reasons, it's much more complicated, so it will have to be discussed separately.)
However, I don't actually know these languages. I am only raising this because I am trying to maintain the lists of languages in MediaWiki in good order, and to help users of Wikipedia and other sites that run on MediaWiki use them conveniently. Two languages with very similar names may make this inconvenient, so I'm suggesting to make them less ambiguous.
I would love to hear the opinions of the Kurdish-speaking wiki editors about this.
Thank you!
The MVP of T345386 will enable use of `mw.msg` as a provided i18n function inside Codex components. This task covers extending our `useI18n` composable to work outside of MediaWiki and support client-side switching.
---
### Considerations
We want to provide a good developer experience for users outside of MediaWiki who need to translate their applications (and any Codex components used in their applications) into other languages.
* It should be possible to build a single-language application using Codex components in a language other than English (no switching, just an alternate default language)
* It should be possible for Codex components to change their language in response to reactive data (client-side switching based on user preference, route changes, etc).
* Codex currently does not provide its own translation strings, so any internationalized app using Codex would need to translate both app-level content (page titles, navigation, etc) as well as Codex component messages. It would be good if one solution could work for both types of messages
** If a developer is using a popular 3rd-party internationalization library like `vue-i18n` for their application content, it would be great if Codex components could integrate with that
### Possible approaches
#### Codex i18n Plugin
If we want to support more robust i18n behavior within Codex without maintaining our own set of translated strings for all component messages, Codex could expose a plugin that wraps up the basic translation system defined in T345386 with some additional logic.
```lang=js
import { createApp } from 'vue';
import { cdxI18n } from '@wikimedia/codex';
const i18n = cdxI18n( {
// pass in configuration,
// message data, etc
} );
const app = createApp( ... );
app.use( i18n );
```
This plugin could use Vue's provide/inject API to provide a couple of things to Codex components:
* A message retrieval function more or less equivalent to the original CdxI18nFunction from T345386 (this would be what gets used on wiki)
* A reactive object containing message data in key/value pairs for a given language (for off-wiki usage)
* A function to update message data with a new set of key/value pairs (could be used in conjunction with Vue-Router in off-wiki usage to allow basic client-side reactive message updates).
#### `vue-i18n` Integration
Instead of (or in addition to) the above, we may want to update (or confirm) that the solution from T345386 is compatible with the popular Vue i18n library (https://kazupon.github.io/vue-i18n/). Perhaps we could even set up Codex components to use Vue i18n internally if another translation method is not provided (this is also something that could potentially be handled via a custom plugin).
This solution may entail adding `vue-i18n` as an optional, externalized dependency of Codex (would not be used within MediaWiki, but could be installed alongside by external users).
#### Build in translation data into Codex itself
Finally (and as a more long-term solution), we could consider adding a set of message strings in different languages to the Codex codebase. We'd probably want to add the library to TranslateWiki to leverage community translation efforts. This would save users of Codex from having to "bring their own strings" for Codex component messages, but we'd still need this solution to integrate with any other translation tools that may be in use in their applications (either within MW or outside of it).
### Acceptance criteria
- [] `useI18n` works with a custom provided i18n function
- [] Client-side switching works
- [] Build a Sandbox page demonstrating this with some basic 2-language switching
T368443 will change the API of some component string props that were previously used both to set up a string used in the template and to implicitly turn on certain behaviors. For example, the previous behavior of the Message component's `dismissButtonLabel` prop was to not only set an `aria-label` for the dismiss label, but to enable the dismiss button itself. In T368443, a new boolean prop `allowDismiss` was added to turn on the dismiss button, but the old API of setting or not setting `dismissButtonLabel` will still work.
This task covers a breaking change to remove these workarounds. For the example above, the default value of `dismissButtonLabel` would be set to the English fallback ('Close') and the component code would no longer use `dismissButtonLabel` being set or not as a proxy for enabling/disabling the dismiss button. The `allowDismiss` prop would be required to turn it on.
The following props are affected:
| Component | Prop | Breaking change |
| --- | --- | --- |
| Dialog | closeButtonLabel | Set `closeButtonLabel` default to English fallback, remove logic to enable/disable close button via `closeButtonLabel` |
| Field, Label | optionalFlag | Set `optionalFlag` default to English fallback, remove logic to enable/disable optional flag via `optionalFlag` |
| Message | dismissButtonLabel | Set `dismissButtonLabel` default to English fallback, remove logic to enable/disable dismiss button via `dismissButtonLabel` |
| SearchInput | buttonLabel | Set `buttonLabel` default to English fallback, remove logic to enable/disable search button via `buttonLabel` |
| TypeaheadSearch | buttonLabel | Set `buttonLabel` default to English fallback, remove logic to enable/disable search button via `buttonLabel` |
Additionally, in T390776 we added deprecation warnings for the old prop usage - the prop validators should be removed when the old prop usage is no longer supported.
### Known usage
| Project | Code | Notes |
|---|---|---|
| Adiutor | articleTagging [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/articleTagging.vue#4) | |
| | requestPageMove [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/requestPageMove.vue#4) | |
| | requestPageProtection [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/requestPageProtection.vue#4) | |
| | createSpeedyDeletion [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/createSpeedyDeletion.vue#4), [Message](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/createSpeedyDeletion.vue#16) | |
| | createSpeedyDeletionOptions [Message](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/createSpeedyDeletionOptions.vue#20) | |
| | deletionPropose [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/deletionPropose.vue#4) | |
| | deletionProposeOptions [Message](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/deletionProposeOptions.vue#20) | |
| | reportRevision [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/reportRevision.vue#4) | |
| | reportRevisionOptions [Message](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/reportRevisionOptions.vue#21) | |
| | requestPageMoveOptions [Message](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/requestPageMoveOptions.vue#20) | |
| | requestPageProtectionOptions [Message](https://gerrit.wikimedia.org/g/mediawiki/extensions/Adiutor/+/9a59b65eb544c1a5506a208402e94e6dd023ab87/resources/ext.adiutor/components/requestPageProtectionOptions.vue#21) | |
| CommunityConfiguration | EditorMessage [Message](https://gerrit.wikimedia.org/g/mediawiki/extensions/CommunityConfiguration/+/e3a9405e737fa5cd8943d14262ede1c2baae77c1/resources/ext.communityConfiguration.Editor.common/components/EditorMessage.vue#3) | |
| ContentTranslation | UnreviewedTranslationDialog [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/ContentTranslation/+/30f940db8770c0e717890234ffc2259ffb9fb85c/app/src/components/SXTranslationConfirmer/UnreviewedTranslationDialog.vue#43) | |
| FileImporter | HelpBanner [Message](https://gerrit.wikimedia.org/g/mediawiki/extensions/FileImporter/+/9182440f3213170d906c0a914472ffbc67070e31/modules/components/HelpBanner.vue#8) | |
| GrowthExperiments | PostEditDialogDemo [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/a5f6e332cf6a0dd1d1fd8daa92ec17fdc5ae1764/documentation/frontend/component-demos/post-edit-dialog/PostEditDialogDemo.vue#11) | |
| | TopicSelectionDemo [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/a5f6e332cf6a0dd1d1fd8daa92ec17fdc5ae1764/documentation/frontend/component-demos/topic-selection-dialog/TopicSelectionDemo.vue#10) | |
| | TopicSelectionDialog [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/a5f6e332cf6a0dd1d1fd8daa92ec17fdc5ae1764/documentation/frontend/component-demos/topic-selection-dialog/TopicSelectionDialog.vue#5) | |
| | PersonalizedPraiseSettings.vue [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/a5f6e332cf6a0dd1d1fd8daa92ec17fdc5ae1764/modules/ext.growthExperiments.MentorDashboard/components/PersonalizedPraise/PersonalizedPraiseSettings.vue#16) | |
| MediaSearch | UserNotice [Message](https://gerrit.wikimedia.org/g/mediawiki/extensions/MediaSearch/+/cf15e516c0a11da92e4aaeb802f85074a65343f5/resources/components/UserNotice.vue#4) | |
| ReportIncident | EmailAlertDialog [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/ReportIncident/+/3231d5ef65071526a16da388dee6cd3968748a96/resources/ext.reportIncident/components/EmailAlertDialog.vue#6) | |
| | ReportIncidentDialog [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/ReportIncident/+/3231d5ef65071526a16da388dee6cd3968748a96/resources/ext.reportIncident/components/ReportIncidentDialog.vue#5) | |
| | ReportImmediateHarmStep [Field](https://gerrit.wikimedia.org/g/mediawiki/extensions/ReportIncident/+/3231d5ef65071526a16da388dee6cd3968748a96/resources/ext.reportIncident/components/ReportImmediateHarmStep.vue#35) | |
| | ReportIncidentDialogStep2 [Field](https://gerrit.wikimedia.org/g/mediawiki/extensions/ReportIncident/+/3231d5ef65071526a16da388dee6cd3968748a96/resources/ext.reportIncident/components/ReportIncidentDialogStep2.vue#58) | |
| Wikilambda | ZObjectStringRenderer [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/WikiLambda/+/a266c0674fbebe2b5946813c530956ddb6ff93f5/resources/ext.wikilambda.app/components/default-view-types/ZObjectStringRenderer.vue#63) | |
| | LeaveEditorDialog [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/WikiLambda/+/a266c0674fbebe2b5946813c530956ddb6ff93f5/resources/ext.wikilambda.app/components/widgets/publish/LeaveEditorDialog.vue#13) | |
| | PublishDialog [Dialog](https://gerrit.wikimedia.org/g/mediawiki/extensions/WikiLambda/+/a266c0674fbebe2b5946813c530956ddb6ff93f5/resources/ext.wikilambda.app/components/widgets/publish/PublishDialog.vue#16) | |
| | FunctionViewerDetails [Message](https://gerrit.wikimedia.org/g/mediawiki/extensions/WikiLambda/+/a266c0674fbebe2b5946813c530956ddb6ff93f5/resources/ext.wikilambda.app/components/function/viewer/FunctionViewerDetails.vue#45) | |
### Documentation
(This should be moved onwiki prior to the breaking change)
Codex 1.9.0 contains changes to some component props that are meant to make it easier to use translated text for certain accessible labels that are usually the same across projects.
For example, the Message component can be dismissed by the user via an icon-only "close" button. Before 1.9.0, to add this button, you had to provide a string for the <code>dismissButtonLabel</code> prop. This would both implicitly enable the button and supply the visually-hidden <code>aria-label</code> of the button, which is needed to support users of assistive technology like screen readers. However, in most projects, this button's <code>aria-label</code> will be the same string—"Close"—so it's not ideal to require everyone using the Message component to provide this prop. Plus, it's confusing that the prop not only supplies the label text, but also enables user-dismissal of the message.
To make it easier for Codex users, we changed or removed several props like this so that most users will no longer need to provide the text. '''When using the components inside MediaWiki, you will automatically get translated strings for these features.'''
The past way of using these props will still work until Codex 2.0 is released. In the meantime, we encourage you to migrate your code now, both to prepare for Codex 2.0 and to take advantage of the translations inside MediaWiki. Below is a guide for migrating each prop.
|Component|Prop name|Migration guide
|---|---|---|
| [[ https://doc.wikimedia.org/codex/latest/components/demos/chip-input.html#props | ChipInput ]] | `chipAriaDescription` | Remove prop |
| [[ https://doc.wikimedia.org/codex/latest/components/demos/dialog.html#props | Dialog ]] | `closeButtonLabel` | To enable the close button, set the new `useCloseButton` prop to true. Remove the `closeButtonLabel` prop, unless you want to customize the `aria-label` of the button (the default is "Close"). |
| [[ https://doc.wikimedia.org/codex/latest/components/demos/field.html#props | Field ]], [[ https://doc.wikimedia.org/codex/latest/components/demos/label.html#props | Label ]] | `optionalFlag` | To indicate that a field is optional, set the new `optional` prop to true. Remove the `optionalFlag` prop, unless you want to customize the text of the optional flag (the default is "(optional)"). |
| [[ https://doc.wikimedia.org/codex/latest/components/demos/message.html#props | Message ]] | `dismissButtonLabel` | To enable the dismiss button, set the new `allowUserDismiss` prop to true. Remove the `dismissButtonLabel` prop, unless you want to customize the `aria-label` of the button (the default is "Close"). |
| [[ https://doc.wikimedia.org/codex/latest/components/demos/search-input.html#props | SearchInput ]] | `buttonLabel` | To enable the search button, set the new `useButton` prop to true. Remove the `buttonLabel` prop, unless you want to customize the `aria-label` of the button (the default is "Search"). |
| [[ https://doc.wikimedia.org/codex/latest/components/demos/table.html#props | Table ]] | `selectAllLabel` | Remove prop |
| Table | `selectRowLabel` | Remove prop |
| Table | `sortCaption` | Remove prop |
| [[ https://doc.wikimedia.org/codex/latest/components/demos/typeahead-search.html#props | TypeaheadSearch ]] | `buttonLabel` | To enable the search button, set the new `useButton` prop to true. Remove the `buttonLabel` prop, unless you want to customize the `aria-label` of the button (the default is "Search"). |
| TypeaheadSearch | `searchResultsLabel` | Remove prop |
---
### Acceptance criteria
- [] Instruct users to update props in their code, or open patches for them
- [] Merge all patches
- [] Reconfigure the above props to require the new APIs as described
Uploading through Upload Wizard (e.g. https://commons.wikimedia.org/wiki/special:uploadWizard?campaign=wlm-at&fields%5B%5D=32171&fields%5B%5D=47.70159/15.79294&captionlang=de&caption=Sog.+Huthaus%2C+Glockenhaus+am+Knappenberg+%28BDA-HERIS-ID%3A+34175%29%2C+Kleinau+23%2C+Reichenau+an+der+Rax&descriptionlang=de&description=Sog.+Huthaus%2C+Glockenhaus+am+Knappenberg&categories=Huthaus%2C+Glockenhaus+am+Knappenberg%2C+Reichenau+an+der+Rax) asks for commons categories and offers an example (when language is set to de): 'z.B. Säugetiere im Etosha Nationalpark'
The category does not exist (it is 'Mammals of Etosha National Park'). Nor can I type 'Säugetiere im Etosha Nationalpark' and it gets automatically translated to the correct category name.
So my proposal is not to translate category names in the upload wizard, as this is misleading.
`shouldFlipExceptions` is actually doing something `$script_subtag != 'Arab'`.
We should implemet something `IconFlipByScript` / `IconFlipByWritingSystem` / `IconVariedByScript` / `IconVariedByWritingSystem` instead.
Noticed when poking around {T365355}
https://www.wikidata.org/w/index.php?title=Help:QuickStatements&oldid=2147483647&diff=2154896250
>Die Inhaltsmodelle „Wikibase-Datenobjekt“ und „Wikitext“ können nicht verglichen werden.
https://www.wikidata.org/w/index.php?title=Help:QuickStatements&oldid=2147483647&diff=2154896250&uselang=qqx still shows it verbatim...
https://www.wikidata.org/wiki/MediaWiki:Diff-incompatible
https://www.wikidata.org/wiki/MediaWiki:Diff-incompatible/en
https://www.wikidata.org/wiki/MediaWiki:Diff-incompatible/en-gb
^ All show in English...
**Steps to replicate the issue** (include links if applicable):
* Open https://test.wikidata.org/wiki/Q148729?uselang=ar or https://test.wikidata.org/wiki/Q148729?uselang=he
*
*
**What happens?**:
The statement containing only a year is left-aligned.
**What should have happened instead?**:
The statement should be right-aligned.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
This is caused by `dir="auto"` on wikibase-statementview-mainsnak and wikibase-snakview-value-container. `dir="auto"` directionally isolates the content of an element from the surrounding page (the page direction no longer applies inside the mainsnak container) and should probably not be used here. See https://www.w3.org/International/articles/inline-bidi-markup/index.en#dirauto
Screenshot of https://test.wikidata.org/wiki/Q148729?uselang=ar:
{F54060515}
Screenshot of https://test.wikidata.org/wiki/Q148729?uselang=he:
{F54060520}
See parent task
The code to detect direction of language is here: https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/language/Language.php$2927
This merely reads files like MessagesQqf.php. By adding explicit script code support MediaWiki will correctly detect su-arab as rtl without a dedicated MessagesSu_arab.php file.
In some languages, like Spanish, we can add more information about a topic using a dash symbol, like this: Michael —who is tall— is my friend. However, in those languages, there can't be a line break between the dash and the word. For example:
This would be acceptable:
Michael —who is
tall— is my friend
This (which is the current mediawiki behaviour in wikipedia) is not acceptable:
Michael —who is tall
— is my friend
Michael —
who is tall—
is my friend
It works exactly as parenthesis do.
The phrase "at all," which is commonly used in negative and interrogative sentences,
is used in affirmative sentences in the following messages, making them difficult to translate:
```
"action-wikilambda-create": "create new Objects at all",
"right-wikilambda-create": "Create new Objects at all",
```
#ArticleRatings has a special page called `Special:MassRatings`, but the name is somewhat awkward as it suggests something else than what the page is. In reality the page allows the user to select one or multiple rating(s) and view a list of pages having said rating(s). `MassRatings` suggests, to me, the capability to mass-rate pages (which is something that ArticleRatings currently does //not// have, but I'm working on such a special page).