Page MenuHomePhabricator
Search Global Search
Use the application-specific Advanced Search for better results and additional search criteria: Tasks, Commits. (More information)
    • Task
    == Reproducing ``` <cdx-dialog :open="true" title="..."> <cdx-message>Hello 1</cdx-message> <cdx-message>Hello 2</cdx-message> </cdx-dialog> ``` == Expected behavior All sides of the message have correct padding. == Acrual behavior The top padding of Hello 1 is zero, bottom padding of Hello 2 is zero. == Analysis Dialog have this rule: ``` .cdx-dialog__body>*:first-child { margin-top: 0; padding-top: 0; } .cdx-dialog__body>*:last-child { margin-bottom: 0; padding-bottom: 0; } ``` It always removing margin & padding from the first/last element in dialog body. And it may breaks other component, and we have no reason to remove padding of them. == Acceptance critera [] - The message inside dialog have correct padding for all sides
    • Task
    In https://wikimedia.slack.com/archives/CLKDS4MG9/p1787726993615349?thread_ts=1787610598.708249&cid=CLKDS4MG9 @phuedx wrote: >> As far as I know JS does not execute in background when page is not visible, so in the case you described the timer would not start until the user has switched to the new tab, thus making it visible and starting the execution of the loaded JS code. @phuedx: can you please check my answer? > > Broadly, JavaScript still runs in a background tab until the browser freezes the tab to conserve resources. However, Chromium-based browsers will actively try to conserve resources consumed by a background tab before it freezes it: > > 1. [[ https://chromestatus.com/feature/5527160148197376 | They throttle the number of concurrent requests initiated by background tabs to 3 ]], which would necessarily delay loading and execution of JavaScript instrumentation > 2. [[ https://docs.google.com/document/d/11FhKHRcABGS4SWPFGwoL6g0ALMqrFKapCk5ZTKKupEk/view?tab=t.0#heading=h.v5h0zisp5o0h | They throttle timer wake ups to 1 second for tabs that have been backgrounded for more than 5 minutes ]] > There's more detail here if you're interested but I don't think it's relevant to this conversation > > I think (1) could explain some of what's being seen here but I don't think it's a full explanation. I don't think (2) will have an impact at all unless your ticks are being sent at sub-second intervals. We should record whether the tab is visible when the `page_visit` event is sent in its `action_context`, e.g.: ```lang=js { action_context: JSON.stringify( { visibility_state: Document.visibilityState // "visible" or "hidden" } ) } ``` ## AC [ ] [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikimediaEvents/+/b2c83b188624543f72661133b5f5621cf9980d76/modules/ext.wikimediaEvents/anyPageVisit.js | anyPageVisit.js ]] records `visibility_state` with all `page_visit` events
    • Task
    **Steps to replicate the issue** (include links if applicable): * Fresh install or clear the app data * Make sure you are logged out * Open the app and navigate to the Activity * The top toolbar with "Activity" and the overflow menu disappears. **What happens?**: The top toolbar with "Activity" and the overflow menu disappears. |{F99885648}|{F99885642}| **What should have happened instead?**: {F99885713} **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): 50601-r-2026-08-11
    • Task
    When I run deleteArchivedFiles.php without the --delete flag, I expect it to display the number of files to delete, similar to what deleteArchivedRevisions.php does. However, it doesn't, it just displays "Use --delete to actually confirm this script".
    • Task
    According to [[https://gerrit.wikimedia.org/g/mediawiki/extensions/TestKitchen/+/c8fe23b72e5940cbab707d0fd144ecc7567fb2a4/extension.json#38 | extension.json ]]: > Required by the GrowthExperiments extension. Supereded by $wgTestKitchenEnableConfigsFetching above. However, there are no known usages in [[https://codesearch.wmcloud.org/search/?q=TestKitchenEnableExperimentConfigsFetching&files=&excludeFiles=&repos= | codesearch ]], and in particular nothing in GrowthExperiments, so I assume this flag is no longer needed. The [[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TestKitchen/+/1235768 | commit ]] that renamed the flag linked to a [[https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/56dad4e93c0a80f5dc82e447454387fadf85ebde/includes/ExperimentTestKitchenManager.php#60 | specific usage ]] in GrowthExperiments, which was since [[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/1238411 | dropped ]] in February.
    • Task
    ####User feedback - a user reported that they were unable to figure out how to answer questions in the Which Came First? game using a screen reader. ####Task - Review VoiceOver support, and ensure users can easily submit answers to the Game ####Refrence From Erika's investigation: The voice over reads only **question x of 5, button**.  But doesn't indicate that it's actually a s**ubmit button**, or a **next question button**. you can see what the voice over read on the bottom of the snapshot {F98839388} {F98839389} ####Acceptance Criteria The "Submit" button and the "Next" button should be read aloud.
    • Task
    == Overview The color of Icon in a button that inside a Card is unexpected. == Expected behavior Color is text color of button == Actual behavior Color is cdx-subtle == Code to reproduce ``` <cdx-card> <template #descritpion> <cdx-button action="progressive"><cdx-icon :icon="cdxIconAdd"/>Do something</cdx-button> </template> </cdx-card> ``` == Analysis `.cdx-card__text__description .cdx-icon` overrided `.cdx-button .cdx-icon`
    • Task
    **Steps to replicate the issue** (include links if applicable): - Navigate to `Teatro Amazonas` on ptwiki. - Tap the lead image to view in full-screen gallery. Appears to be caused by error 500 from `media-list`: https://pt.wikipedia.org/api/rest_v1/page/media-list/Teatro_Amazonas Happening on Android & iOS
    • Task
    **Feature summary** (what you would like to be able to do and where): Mention format JSON will not be used in fact. **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): 1. Visit https://en.wiktionary.org/wiki/Special:ApiSandbox#action=feedcontributions&user=Example 2. See prominent "format=json", in several places. 3. Hit "Make request". 4. Huh? The result is in format rss. Ah ha, way over on a different page, way at the bottom, it says: https://www.mediawiki.org/wiki/API:Feedcontributions#Additional_notes > Note that if the request is successful, the output will be in the > format requested by the feedformat parameter. The format requested by > the standard format parameter (e.g., JSON) will only be used in the > event of an error. No wonder. OK, that also needs to be mentioned on https://en.wiktionary.org/wiki/Special:ApiSandbox#action=feedcontributions&user=Example too! **Benefits** (why should this be implemented?): Else there is no way users can figure out why they picked A but got B. ### To do Edit the value of `apihelp-feedcontributions-param-feedformat` in [Api/i18n/en.json](https://gerrit.wikimedia.org/g/mediawiki/core/+/master/includes/Api/i18n/en.json) in MediaWiki core. The new value should clarify that `feedformat` overrides `format`, for example: "The format of the feed. This parameter overrides the <code>format</code> parameter." Make sure that the name of any parameters used in the message are wrapped in `<code>` tags so they are not translated. For information about contributing to MediaWiki core, see the [Gerrit tutorial](https://www.mediawiki.org/wiki/Gerrit/Tutorial) and [How to become a MediaWiki hacker](https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker)
    • Task
    **Feature summary** (what you would like to be able to do and where): https://en.wiktionary.org/w/api.php?action=help&modules=feedcontributions says tagfilter Filter contributions that have these tags. It should say if it means filter in, or filter out. **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): Currently it is ambiguous. **Benefits** (why should this be implemented?): E.g., coffee grinds, we filter out. English needs to be clear. ### To do Edit the value of `apihelp-feedcontributions-param-tagfilter` in [Api/i18n/en.json](https://gerrit.wikimedia.org/g/mediawiki/core/+/master/includes/Api/i18n/en.json) in MediaWiki core. The new value should clarify the behavior of tagfilter as an inclusive filter, such as "Only show contributions that have these tags." For information about contributing to MediaWiki core, see the [Gerrit tutorial](https://www.mediawiki.org/wiki/Gerrit/Tutorial) and [How to become a MediaWiki hacker](https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker)
    • Task
    **Feature summary** (what you would like to be able to do and where): Capability to internationalize the interface in multiple languages. **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): Wikinewsie currently loads articles from multiple language Wikipedias, but the interface so far is only in English. The interface actually only uses a few words so far, so it should be relatively easily to add new languages, once a basic internationalization infrastructure is set up. **Benefits** (why should this be implemented?): More use by non-English speakers.
    • Task
    ###Background For the "Which Came First" game, the Android app announced Wikipedia games, but we'd like to reduce the amount of pop-ups live in the app. We should remove this now that the games have been present for a while. ###Task [] Remove games pop-up https://www.figma.com/design/JljLgMaebLZ5ugbZ9qnXB2/Android-%E2%86%92-Games-%E2%86%92-T...?node-id=3462-25122&t=YLChZDcby2rNUybp-4 & accompanying toast Nice to have [] Also remove home-feed tooltip {https://phabricator.wikimedia.org/T428681}
    • Task
    Requested at https://translatewiki.net/wiki/Support#Request_to_enable_Izere_[izr]_language Autonym: Izere ISO 639-3 code: izr References: * [[ https://commons.wikimedia.org/wiki/File:AMatiyu_12_-_Kushu_Kufas_Kufe_Rife%CC%B1_Adakunom_01.jpg | Matthew 12 - New Testament (aMatiyu 12 - Kushu Kufas Kufe Rife̱ Adakunom) ]]. * [[ https://commons.wikimedia.org/wiki/File:Kufas_ne_Kuzibir_Izere_kufe_Inoon_-_2_01.jpg | "Kufas ne Kuzibir Izere kufe Inoon - 2," a children Izere (izr) language learning booklet ]]. * [[ https://commons.wikimedia.org/wiki/File:Kuyis_Ikere_Ni_Izere_be_Niseng_ne_Itirik_01.jpg | "Kuyis Ikere Ni Izere be Niseng ne Itirik," an Izere (izr) language booklet ]]. * [[ https://commons.wikimedia.org/wiki/File:AMatiyu_12_-_Kushu_Kufas_Kufe_Rife%CC%B1_Adakunom_01.jpg | New Testament Bible in the Izere language ]] [x] Add to language-data([[https://github.com/wikimedia/language-data/pull/512|patch]]) -- [x] Run `src/util/ulsdata2json.php` before adding -- [x] Run `src/util/ulsdata2json.php` after adding [x] Add to translatewiki configuration([[https://gerrit.wikimedia.org/r/c/translatewiki/+/1321586|patch]]) [x] Deploy configuration to translatewiki [x] Add an entry to LocalNames/LocalNamesEn.php in the CLDR extension (if needed)([[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/cldr/+/1327190|patch]]) [x] Add jquery.ime keyboard (if needed)([[https://github.com/wikimedia/jquery.ime/pull/861|patch]]) -- [x] Add keyboard documentation. **Note: **: In terms of special characters, the language does have use the minus below diacritic, the acute and grave accents on vowel sounds. Here are the special characters in Izere: e̱, o̱, á, é, é̱, í, ó, ó̱, ú, à, è, è̱, ì, ò, ò̱, and ù. See [[ https://commons.wikimedia.org/wiki/File:Bo%CC%B1so%CC%B1p_Izere_-_Kufas_ne_Kuzibir_Izere_kufe_Inoon_-_2.jpg | here ]] for orthography. [x] Update jquery.uls and jquery.ime in the ULS extension [x] Deploy ULS to translatewiki [x] Create the translatewiki language portal [x] Make sure that the category for the language is not marked as disabled [x] Update the translatewiki language portal to indicate that the language is enabled [x] Add the requester (and possibly other relevant users) to the translators list on the portal [x] Enter the autonym in the Wikimedia Portals project [ ] Test language search in UniversalLanguageSelector and fix the search index (if needed) [ ] Enable machine translation and test that it works (if needed) See documentation on how to add a language to translatewiki: https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages#translatewiki
    • Task
    The [[ https://www.mediawiki.org/wiki/Extension:EventBus | EventBus MediaWiki extension ]] is both a backend library and user of its own backend library. The main `EventBus` interface is a PHP API for producing [[ https://wikitech.wikimedia.org/wiki/Event_Platform | Event Platform ]] events to [[ https://wikitech.wikimedia.org/wiki/Event_Platform/EventGate | eventgate ]]. The EventBus extension also contains [[ https://github.com/wikimedia/mediawiki-extensions-EventBus#eventbus-handlers-and-generated-events | event producer code ]]. This code subscribes to various MediaWiki Hooks and DomainEvents and translates them into JSON events, and then an EventBus class instance to produce the events. This has been the status quo since [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EventBus/+/254086 | EventBus extension's initial creation 11 years ago ]]. It hasn't been a practical problem until now. As more event streams are being created and more data fields being added, EventBus is starting to add dependencies on other extensions. - T430967 is adding a dependency on CentralAuth - T428176 is adding a dependency on WikiBase. If EventBus depends on another extension, that means that extension can't depend on EventBus. Event producer logic should move to another extension so that EventBus can be used as a standalone library. === Done is [] Event producer logic is no longer in EventBus extension [] EventBus extension does not depend on other extensions that might themselves want to depend on EventBus.
    • Task
    The README says "Node.js v18+" in one place but tells you to `nvm install 24` in another. **Files:** `README.md` **Acceptance criteria:** [] A single, consistent Node version recommendation
    • Task
    There are duplicate `cookieParser()` and body-parser lines, some active and some commented out. **Files:** `backend/src/server.js` **Acceptance criteria:** [] Each middleware registered exactly once, in correct order [] Dead comments removed
    • Task
    `backend/README.md` describes a **Flask / Python / PostgreSQL** stack, but the real code is **Node / Express / MongoDB**. It also has duplicated sections. **Files:** `backend/README.md` **Acceptance criteria:** [] README reflects the actual stack, scripts, and endpoints [] Duplicate content removed
    • Task
    Both READMEs claim an MIT license "see the LICENSE file", but no `LICENSE` file exists. **Files:** add `LICENSE` at repo root. **Acceptance criteria:** [] Standard MIT license text with correct year and owner
    • Task
    Debug `console.log` statements were left in production code. **Files:** - `backend/src/server.js` — the `DEBUG CHECK` request-logging middleware (~lines 79-86) - `frontend/src/lib/api.ts` — the `API verify call` logs in `submissionApi.verify` (~lines 233-237) **Acceptance criteria:** [] No stray debug logs [] Intentional `morgan` logging kept [] App still functions
    • Task
    The category emojis render as garbage (`📗`, `📘`, `🚫`) because of a file-encoding issue. **Files:** `frontend/src/pages/SubmissionForm.tsx` (~lines 279, 291, 304). Grep the repo for other `ðŸ` occurrences. **Acceptance criteria:** [] Emojis (📗 📘 🚫) display correctly [] File saved as UTF-8
    • Task
    Per-user/IP throttling via MediaWiki's pingLimiter, plus a daily token budget will help in saving LLM usage costs for users with a tight budget.
    • Task
    === Background The `mpo` override cookie is not guaranteed to work for everyone experiments. If the request wasn't served by the app server, then the `mpo` cookie wasn't read and the server-side component of an experiment wouldn't know about the override. However, the JS SDKs read the `mpo` cookie directly and so the client-side component of an experiment would know about the override. The `mpo` override query parameter, however, works with all experiments. Also, FY26-27 ST6 is exploring (and delivering?) serving requests from logged-in users via from the caches, which will exacerbate the `mpo` cookie behavior. See also {T428694}. === AC [] The `mpo` cookie behavior is removed from the PHP and JS SDKs [] The documentation is updated === Notes 1. This is fairly simple to do. There are a total of 9 mentions of 'mpo' in the TestKitchen codebase (including unit/integration tests) that would need to be removed: https://codesearch.wmcloud.org/search/?q=%27mpo%27&files=&excludeFiles=&repos=Extension%3ATestKitchen
    • Task
    Requested at https://translatewiki.net/wiki/Support?markasread=285911#Request_to_add_Sindhi_(Khudabadi)_on_translatewiki Autonym: 𑋝𑋡𑋟𑋐𑋢 (𑊻𑋩𑋣𑋏𑋠𑋔𑋠𑋏𑋢) Source: https://www.omniglot.com/writing/sindhi.htm ISO 639-3 code: sd-sind [x] Add to language-data ([[ https://github.com/wikimedia/language-data/pull/507 | patch ]]) -- [x] Run `src/util/ulsdata2json.php` before adding -- [x] Run `src/util/ulsdata2json.php` after adding [x] Add to translatewiki configuration ([[ https://gerrit.wikimedia.org/r/c/translatewiki/+/1302653 | patch ]]) [x] Deploy configuration to translatewiki [x] Add an entry to LocalNames/LocalNamesEn.php in the CLDR extension (if needed) [] Add jquery.ime keyboard (if needed) -- [] Add keyboard documentation [x] Update jquery.uls and jquery.ime in the ULS extension([[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UniversalLanguageSelector/+/1320297|patch]]) [] Deploy ULS to translatewiki [x] Create the translatewiki language portal [x] Make sure that the category for the language is not marked as disabled [x] Update the translatewiki language portal to indicate that the language is enabled [x] Add the requester (and possibly other relevant users) to the translators list on the portal [x] Enter the autonym in the Wikimedia Portals project [] Test language search in UniversalLanguageSelector and fix the search index (if needed) See documentation on how to add a language to translatewiki: https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages#translatewiki
    • Task
    Very minor #technical-debt issue in `/languages/messages/MessagesEn.php` **What’s the problem?**: In `MessagesEn.php`, there are two separate alias entries that resolve to the same special page and behave identically: Line 429: ```php 'AllMyUploads' => [ 'AllMyUploads', 'AllMyFiles' ] ``` Line 504: ```php 'Myuploads' => [ 'MyUploads', 'MyFiles' ], ``` All redirect to `Special:ListFiles/[$username]`. **What can be done about it?**: The two entries can be consolidated into a single line by: - Deleting line 429 (`'AllMyUploads' => [ 'AllMyUploads', 'AllMyFiles' ]`), and - Adding its aliases to line 504, so that line (now line 503) becomes: ```php 'Myuploads' => [ 'MyUploads', 'MyFiles', 'AllMyUploads', 'AllMyFiles' ], ``` This keeps the same behaviour but reduces duplication. I think it's better to keep line 504 because then it's listed as part of the block of other special pages beginning `My...`, i.e. `MyLanguage`, `MyLog`, `MyPage` and `MyTalk`. **Good first task**: This is a good candidate for a **#good_first_task**, because it only involves: - Removing one line, and - Updating a second line with additional aliases. No functional changes occur, and the change is limited to message‑alias definitions in English.
    • Task
    **Feature summary**: Alias `Special:Mylogs` to `Special:Mylog` **Use case(s)**: `Special:Logs` (plural) is aliased to `Special:Log` (singular), so it makes sense for similar aliasing to `Special:Mylog`. And Special:MyLogs does list all the user's log entries in the various logs. Then, a user might type or link to the plural name. **Good first task** There's only a minor change required here to `languages / messages / MessagesEn.php` to add these aliases. It's literally a change to one line of code to add it to the array: ```php 'Mylog' => [ 'MyLog' ], ``` Currently at line 484 to: ```php 'Mylog' => [ 'MyLog', 'MyLogs' ], ```
    • Task
    The consumer will split a WDQS patch into separate `delete` and `insert` requests to the triple-store. Qlever actually returns a rather detailed report on the changes applied. This might make it possible to apply a patch in a single request. AC: [] The possibility of combined patches has been evaluated [] If the outcome is positive, a new task has been created to actually implement the change
    • Task
    == Problem The search input placeholder has a grammar issue: "Search for a Wikidata Items (e.g., Albert Einstein)" == Goal Fix the sentence to be grammatically correct. == Expected Fix Update it to: "Search for a Wikidata item (e.g., Albert Einstein)" == File Location Search input field in the homepage template == Difficulty Very Easy (Good First Task)
    • Task
    Preconditions: - Set the iOS device to dark mode in iOS System Settings - Install the Wikipedia iOS mobile app **Steps to replicate the issue** (include links if applicable): * Ensure the device theme is set to dark. * Navigate to a Project namespace. Search for a `Wikipedia:` namespace page like "Wikipedia:About" in the app's search bar. Alternative: Tap this URL, which should open in the app: https://en.wikipedia.org/wiki/Wikipedia:Project_namespace * Observe the page background and top navigation bar. **What happens?**: The page content retains a white background regardless of the theme setting. The "Share" and "Search" icon-only buttons are invisible because the white icons are rendered on a white background. **What should have happened instead?**: The page background should transition to a dark color, and icons should invert color. "Share" and "Search" icons should remain visible. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.):
    • Task
    Currently the streaming-consumer uses the [[ https://github.com/prometheus/jmx_exporter | Prometheus JMX Exporter ]] to report metrics to Prometheus. This means injecting the [[ https://github.com/wikimedia/operations-puppet/blob/production/modules/profile/manifests/query_service/streaming_updater.pp#L30 | exporter into the JVM ]] in combination with [[ https://github.com/wikimedia/operations-puppet/blob/production/modules/profile/files/query_service/updater-prometheus-jmx.yaml | a config file ]] that defines a whitelist for the mbeans to be exported. The consumer itself, uses [[ https://gitlab.wikimedia.org/repos/wikidata-platform/wdqs/wdqs-streaming-consumer/-/blob/main/src/main/java/org/wikidata/query/rdf/updater/consumer/StreamingUpdate.java?ref_type=heads#L51 | codehale to export any metrics ]]. A [[ https://gitlab.wikimedia.org/repos/wikidata-platform/wdqs/wdqs-streaming-consumer/-/blob/main/src/main/java/org/wikidata/query/rdf/updater/consumer/options/StreamingUpdateOptions.java?ref_type=heads#L38 | command line parameter ]] can be used to customize the object domain for the exported metrics (defaults to `wdqs-streaming-updater`). The streamiong producer on the other hand, uses the flink infrastructure to do the same, without the need for the JMX exporter. It was suggested that there needs to be a way to simplify the exposure of metrics to Prometheus.
    • Task
    This is a pretty common extension that lots of parties interact with. It's probably a good idea to get its documentation properly published. Extension description and repo location: https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:WikiEditor Some documentation exists at: https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:WikiEditor/Toolbar_customization https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:WikiEditor/Toolbar_customization/Library CodeMirror is an existing extension that has JSDoc that is being published. https://gerrit.wikimedia.org/g/mediawiki/extensions/CodeMirror Instructions for JSDoc are at: https://www.mediawiki.org/wiki/JSDoc This includes publishing instructions: https://www.mediawiki.org/wiki/JSDoc#4._Publish_on_doc.wikimedia.org After setting up publishing, it would then end up at https://doc.wikimedia.org in the MediaWiki Components section
    • Task
    Requested at https://translatewiki.net/wiki/Support/Archive/2026/04#Adding_Southern_Uzbek_to_Translatewiki Autonym: اۉزبېکچه [x] Add to language-data ([[ https://github.com/wikimedia/language-data/pull/506 | patch ]]) -- [x] Run `src/util/ulsdata2json.php` before adding -- [x] Run `src/util/ulsdata2json.php` after adding [x] Add to translatewiki configuration([[https://gerrit.wikimedia.org/r/c/translatewiki/+/1311544|patch]]) [x] Deploy configuration to translatewiki [x] Add a Messages*.php file with `$rtl = true;` (if needed)([[https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1326389|patch]]) [ ] Deploy the Messages*.php file with `$rtl = true;` to translatewiki [x] Add an entry to LocalNames/LocalNamesEn.php in the CLDR extension (if needed)([[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/cldr/+/1327204|patch]]) [ ] Add jquery.ime keyboard (if needed) -- [ ] Add keyboard documentation [x] Update jquery.uls and jquery.ime in the ULS extension([[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UniversalLanguageSelector/+/1320297|patch]]) [ ] Deploy ULS to translatewiki [x] Create the translatewiki language portal [x] Make sure that the category for the language is not marked as disabled [x] Update the translatewiki language portal to indicate that the language is enabled [x] Add the requester (and possibly other relevant users) to the translators list on the portal [x] Enter the autonym in the Wikimedia Portals project [ ] Test language search in UniversalLanguageSelector and fix the search index (if needed) [ ] Enable machine translation and test that it works (if needed) See documentation on how to add a language to translatewiki: https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages#translatewiki
    • Task
    Requested at https://translatewiki.net/wiki/Support#Request_to_Add_Sindhi_(Devangari)_on_translatewiki Autonym: सिंधी (देवनागरी), Source: Government of India's CIIL Sindhi Devanagari Primer: https://ciil.gov.in/primers/Sindhi_(Devanagari)_Primer.pdf ISO 639-3 code: sd-deva [x] Add to language-data ([[ https://github.com/wikimedia/language-data/pull/501 | patch ]]) -- [x] Run `src/util/ulsdata2json.php` before adding -- [x] Run `src/util/ulsdata2json.php` after adding [x] Add to translatewiki configuration ([[ https://gerrit.wikimedia.org/r/c/translatewiki/+/1287997 | patch ]]) [x] Deploy configuration to translatewiki [x] Add an entry to LocalNames/LocalNamesEn.php in the CLDR extension (if needed) [x] Add jquery.ime keyboard (if needed) -- [] Add keyboard documentation [x] Update jquery.uls and jquery.ime in the ULS extension([[https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UniversalLanguageSelector/+/1320297|patch]]) [x] Deploy ULS to translatewiki [x] Create the translatewiki language portal [x] Make sure that the category for the language is not marked as disabled [x] Update the translatewiki language portal to indicate that the language is enabled [x] Add the requester (and possibly other relevant users) to the translators list on the portal [x] Enter the autonym in the Wikimedia Portals project [] Test language search in UniversalLanguageSelector and fix the search index (if needed) See documentation on how to add a language to translatewiki: https://www.mediawiki.org/wiki/Manual:Adding_and_removing_languages#translatewiki
    • Task
    ### Issue From user feedback: "One thing though please: when scrolling down an article the status bar lacks any translucency. It shows the status bar elements superimposed above the Wikipedia article, there is no translucent gradient - (in contrast to scrolling up when this standard iOS behaviour is implemented). Hope that this is a big (and not a feature 😉) that can be fixed." According to this comment, the issue seems to be the lack of background behind the status bar. See below our example vs an Apple one: {F76261547} {F76261621} This ticket is to add the gradient behind the status bar, updating it according to themes. ### User story As a user reading an article, I want the status bar to display a translucent gradient when scrolling down, so that the reading experience feels native, polished and visually consistent with standard iOS behaviours. Full Slack thread here: https://wikimedia.slack.com/archives/C4DDMJ9CH/p1776343159594579
    • Task
    `server.js` contains unused/commented code, including potentially dead variables, unreachable logic, commented-out blocks, unused imports, or redundant utility functions — that no longer serve any purpose in the current implementation. This dead code should be identified and removed to improve readability, reduce cognitive overhead, and keep the code clean and maintainable.
    • Task
    The emoji character in the "Label Management" feature description is corrupted or incorrectly encoded, rendering as a broken replacement character (��) instead of a valid visible emoji. This should be replaced with a suitable valid emoji or removed entirely. The "Label Management" feature description should render cleanly with either a valid, correctly encoded emoji appropriate to the context, or no emoji at all.
    • Task
    The emoji character in the "What it does" section heading on line 5 of the README is corrupted or incorrectly encoded, rendering as a broken or empty character (��) instead of a valid visible emoji. This should be replaced with a valid emoji or removed entirely. **Expected Behavior** The section title should render cleanly with either a valid, correctly encoded emoji that is relevant to the section content, or no emoji at all if a suitable replacement is not agreed upon.
    • Task
    Hi. When moving to a table, a css ```lang=css .mw-redirect { font-style: italic; } ``` was lost. # Open Special:EditWatchlist. # Find an entry for a redirect. # Expected: italic link text. # Got: plain link text. For example, [[https://en.wikipedia.org/w/index.php?title=2024_injury_of_Donald_Trump_at_rally&redirect=no|this page]]: {F72854548} Thank you.
    • Task
    **Steps to replicate the issue** (include links if applicable): * Go to a Module page which you have permission to edit from a mobile, for example https://en.wikipedia.org/wiki/Module:Article_stub_box/sandbox * Press "edit full page" in the menu **What happens?**: Error: Section editing not supported Section editing is not supported in this page or is disabled for this view. **What should have happened instead?**: No button (since basic button already is a full page edit button) or a button that works **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.):
    • Task
    These three tabs are all different pages, but it's really hard to tell which one is which at the moment: {F71525905} The simple approach to have this is to add a new variable to the title, and add it to the context of all calls to `specialpage.SpecialPage` as part of the context.
    • Task
    So we've recently migrated beta-vct to beta-commons. The beta env of the tool (https://beta-videocuttool.wmcloud.org/) is primarily for testing changes before we go live on prod. [P0] [BUG] `import.meta.env.VITE_ENV !== "production"` check is failling on production, as `import.meta.env.VITE_ENV ` is not being picked up by vite (even though its set up in Dockerfile.prd). This causes tool to pickup BETA_COMMONS_BASE_URL on client side (for production as well), causing issues to upload [P1/P2] This ticket addresses the following concerns. 1) Currently in beta-vct, the placeholder input url begins with `commons.wikimedia.org` which might be misleading to users. Remove the hardcoded placeholder from this, and use a generic one (which shows commons.wikimedia.beta.org for beta env, and commons.wikimedia.org for prod env) 2) We have a couple of util functions `retrieveVideoData` and `checkFileExist` which have a hardcoded check for `commons.wikimedia.org`. Remove all instances of this hardcoded url, use dyanmic base url fetched from ENV_SETTINGS. 3) Also as a precautionary measure, add a error notification if video doesn't exist/not found in commons/beta-commons (based on the env). We can have the error message like `Video: {video_title} not found in {commons link based on env}. Video url: {final generated video url}`
    • Task
    This task has two parts: 1. Make sure all errors are handled and throw a 4xx error. If during any flow we see an exception, which is not handled, it throws 5xx (this should not be the case). 2. Since 5xx error usually mean service is unavailable (this should ideally happen when server is unavailable/unhealthy). In this case we should make a static Service Unavailable page, and show it (via React). The page should look like this {F70766850}
    • Task
    **Steps to replicate the issue** (include links if applicable): * Go to `Special:Homepage` * Launch a suggested edit (that is not a structured task) * Quick tips dialog opens **What happens?**: The icons of the buttons inside the header of the full-screen dialog (on mobile) or floating dialog (on desktop) appear grey. The buttons look inactive/disable. **What should have happened instead?**: The icons should not have reduced opacity, so that their existing black / `color-base` / `#202122` color is fully visible **Other information** (browser name/version, screenshots, etc.): {F66752087}
    • Task
    Looking at a patchdemo from June, the button had the same horizontal padding (visible on hover or focus) as the plain buttons adjacent (5px): {F65964130} It now has none: {F65964134} with normal styling: |Before regression |After regression |{F65964140}|{F65964138}
    • Task
    **Steps to replicate the issue** (include links if applicable): * Go to the REST Sandbox: https://test.wikipedia.org/wiki/Special:RestSandbox * Expand the documentation for any endpoint (for example, GET /v1/page/{title}/history) * Look at the "Response" section * Under the "Media type" label, there is a dropdown; under the dropdown, there is a label that says "Controls **Accept** header" **What happens?**: * The highlight color on the word "Accept" is hard to read in both dark and light mode. See screenshots below: {F65805751} {F65805766} **What should have happened instead?**: "Accept" should be easy to read. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.): Observed in Chrome and Firefox.
    • Task
    There is no 404 page for VCT as of now. We should build a 404 page for VCT, which should come when user tries to enter the video url (along with the id) Eg: https://videocuttool.wmcloud.org/edit/a2e08b03-3a82-4dc6-b0df-b2fc4ee0c5a7
    • Task
    **Steps to replicate the issue:** 1. Open VideoCutTool (e.g., at http://localhost:8000/ or https://videocuttool.wmcloud.org/). 2. Upload a video file. 3. Navigate to the rotation feature/section. 4. Apply a rotation (e.g., 90 degrees clockwise). 5. Observe the "Preview" and "Reset" buttons. **What happens?:** After applying a rotation, the "Preview" and "Reset" buttons become unresponsive. Clicking them has no effect, preventing the user from previewing the rotated video or resetting the rotation. **What should have happened instead?:** The "Preview" button should allow the user to see the video with the applied rotation, and the "Reset" button should revert the video to its original orientation before rotation was applied. Both buttons should be functional and responsive after a rotation is performed. **Software version:** Current prod (VideoCutTool) [https://videocuttool.wmcloud.org/] (If testing locally, also mention: Local development setup, cloned from [https://gerrit.wikimedia.org/r/labs/tools/VideoCutTool]) **Other information (browser name/version, screenshots, etc.):** * Browser: [Your Browser Name and Version, e.g., Chrome 126.0.6478.126, Firefox 128.0] * Operating System: [Your OS, e.g., Windows 10, macOS Sonoma, Ubuntu 22.04] * (Optional: Attach a screenshot or short video demonstrating the issue if possible, though you haven't provided one for this specific bug yet.)
    • Task
    It is a bit cosmetic, but it is quite important to us. Current credit text does not provide any link to Wiki in Africa. Even though we are the primary organization behind that tool, originally and still today. I would appreciate that a link is also provided for Wiki in Africa : https://www.wikiinafrica.org Current credit text : ISA tool was developed as a collaboration between Wiki In Africa, Histropedia and the Structured Data on Commons project. Further devopment supported by Wikimedia Sverige, SWITCH and Bern University of Applied Sciences. It is running on tools.wmflabs.org , and is subject to the Wikimedia Cloud Services Terms of use . ISA is published under GPLv3 . Content added through the tool to Wikimedia Commons is released under CC0 . I can not replicate the linked text. But the one I would like to be fixed is simply the Wiki in Africa one Thanks
    • Task
    The PyYAML version needs to be removed from the `requirement.txt ` files for Linux users as this causes an error.
    • Task
    This task involves UPDATING and IMPROVING on-wiki documentation for the [[ https://meta.wikimedia.org/wiki/Adiutor | Adiutor]] tool. This task was filed as part of the Wiki Mentor Hackathon 2025, but anyone can work on it. This tool already has documentation, but the creators welcome contributions, and would like the docs to align with the https://www.mediawiki.org/wiki/Documentation/Tool_doc_template ==Steps:== Explore the tool: https://meta.wikimedia.org/wiki/Adiutor **Note: **Please use this wiki-text template: https://www.mediawiki.org/wiki/Documentation/Tool_doc_template Create on-wiki docs: - In your user space, create a new subpage (for example https://meta.wikimedia.org/wiki/User:{YOUR USERNAME}/New_page - Use the existing tool documentation to create a revised document or set of documents that follow the template format. - Reach out to the maintainers of the tool to share your document, and collaborate on how and where to publish it with the existing tool docs. Use this guide to help you! https://www.mediawiki.org/wiki/Documentation/Tool_docs **Skills Required:** Technical writing, MediaWiki editing, Collaboration - Mentorship & Support: @TBurmeister
    • Task
    Attaching 2 screenshots of the tool from desktop and mobile view. Lets try to synchronize them and make them look similar Explicitly in mobile view: 1. Text color is somehow blue (not black, as in desktop). 2. No Border around the hamburger menu drawer, makes it difficult to differentiate from the previous screen. Lets add a border to the menu Exit Criteria: 1. Check for both logged in and logged out state 2. Check for both dark and light mode. Feel free to ping any of the maintainers or maybe here in the phabricator itself if any doubt. {F58583638} {F58583644}
    • Task
    The home icon / text [VIdeoCutTool] should be clickable, and should redirect to `/` {F58513054}
    • Task
    **Steps to replicate the issue** (include links if applicable): * Edit any video * Check on the progress bar time **What happens?**: The Time shown exceeds the 60 second mark, and we see time like 19.80s (where as it should be 20.20s). **What should have happened instead?**: The millisecond timer goes up to 100, and should go till 59. **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): Current prod (VideoCutTool) [https://videocuttool.wmcloud.org/] **Other information** (browser name/version, screenshots, etc.): PFA screenshots {F58512838} {F58512837} **Exit criteria** * Time should follow the basic validation. * Make a util function for the same. * Unit tests around the same util function.
    • Task
    == Background Currently we're applying code formatting in inline comments sparesly and inconsistently. In order to provide consistent and inclusive documentation with reduced cognitive load we should follow a particular style. When comparing following different Markdown comments - An icon at the end of the textarea element. Similar to an ::after pseudo-element. - An icon at the end of the `textarea` element. Similar to an `::after` pseudo-element. - An icon at the end of the `<textarea>` element. Similar to an `::after` pseudo-element. The third option is the clearest and most inclusive. ==== Why? **Clarity of Syntax** - Markdown often supports HTML elements. Including the explicit `<textarea>` ensures clarity about the type of element involved. - This is particularly helpful for users with varying levels of expertise, as the `<textarea>` is a recognizable HTML tag. **Inclusivity Across Accessibility Needs** - People using assistive technologies (e.g., screen readers) or those less familiar with programming terminology might not understand `textarea` without the angle brackets `<` `>`. - Specifying `<textarea>` aligns with common documentation practices, making it universally recognizable. **Reduces Ambiguity** - Without the angle brackets, "textarea" could be misinterpreted as general text or another concept entirely, rather than a specific HTML element. - This distinction becomes crucial in international or beginner-friendly contexts. == Goal Agree on above and apply uniform way to markup code (and HTML elements) == Acceptance criteria [] All Codex pages have been unified to the agreed-on format
    • Task
    This work is a follow-up task to {T379812}. **Background** Background colors vary per module: - Suggested edits module: #f5f9ff (not a color token) - Community updates module: #f1f4fd (background-color-progressive-subtle) - Impact module: #f8f9fa (background-color-interactive-subtle) - Your mentor module: #fff (background-color-base) - ‘Get help with editing’ module: #fff (background-color-base) **Suggestion** Use two background colors → Default: #fff (background-color-base) → Main module (Suggested edits): #f1f4fd (background-color-progressive-subtle) **Acceptance criteria** [] Change module backgrounds (all use #fff except for the Suggested edits module that uses #f1f4fd)
    • Task
    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 ]].
    • Task
    Codex Icons are not visible in Windows high contrast mode. OOUI icons were fixed in T180890 to work with high contrast mode. Here is a screenshot of the issue. Note that the two visible icons are OOUI Icons from gadget Adiutor. {F57783827} First reported [[ https://fr.wikipedia.org/wiki/Discussion_aide:Mode_sombre#c-IpMultiChiffré-20241205191600-Problème_d'affichage_des_icones_avec_windows_en_mode_contraste_noir | here ]].
    • Task
    As a follow up to {T375900}, we should prove uniform distribution of user enrollment assignments in experiments managed by Test Kitchen. ==Description Add another test to the `UserSplitterInstrumentation` class in the Test Kitchen extension by injecting randomness into the user ID value (user hash) and checking that resultant variant values have set membership instead of evaluating to a deterministic value when there are multiple variant values. See https://gitlab.wikimedia.org/phuedx/id-distribution-test as an example of an ID distribution test. ==Acceptance Criteria [] Relevant test is added and passes ==Required [] Unit/Integration tests? [] Documentation? [] Passed QA?
    • Task
    `attachAccount.php` can merge local accounts into a global account with the same name, which is a sensitive operation (it gives the global account owner access to the local account, and under some conditions the reverse as well). It's logged to Logstash, but there should probably be a proper on-wiki log entry as well.
    • Task
    {F57691958} Notice how the "Kyiv-Pasazhyrskyi railway station" list item has a dark gray line going through it, and below it there's a slightly different gray background on the edges. In addition the "view all edits" link should have some bottom padding.
    • Task
    # Overview The design tokens on the docs site is being redesigned. The tables are getting restyled and restructured as a part of T373200. Part of the redesign involves changing the "copy" button to an icon-only button and displaying only when hovering over the cell for the token to copy. ## Example {F57497033} | [[ https://www.figma.com/design/3T3k7VdQiAt0VkiOifE8cA/codex-docs-tokens?node-id=6-11281&t=mIOa425sVFHWXOS4-1 | Figma file ]] | ## Acceptance criteria [] The copy button in token tables is updated to use an icon-only button and appears only on hover with a tooltip that reads "Copy token"
    • Task
    Example search: https://codesearch.wmcloud.org/search/?q=wgMFStopRedirectCookieHost&files=&excludeFiles=&repos= Click on the README.md result and you will get a rendered Markdown file (and line number links will of course not work). This part of gitiles is undocumented but after some googling I found [[https://gerrit-review.googlesource.com/c/gitiles/+/251333|this patch]] which mentions +show, and that does seem to work: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/923b14e23a3f95f0cb900fab28d96e8c4c67fdab/README.md https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+show/923b14e23a3f95f0cb900fab28d96e8c4c67fdab/README.md So codesearch should add that to Gitiles URLs of .md files (or all files, I think it's harmless otherwise).
    • Task
    All other pages have their footers at the bottom of the page. However, seems this was not done on the user campaigns page. Below is a view of the current display. {F54039756}
    • Task
    Hard-deprecated methods can be removed when they have been emitting deprecation warnings by calling wfDeprecated for at least three months, and the call to wfDeprecated is included in at least one stable release (see the [[https://www.mediawiki.org/wiki/Stable_interface_policy|Stable Interface Policy]]). As of April 2024, all methods that had been hard-deprecated in the 1.41 release can be removed (See https://phabricator.wikimedia.org/source/mediawiki/browse/REL1_41/ for the code of that release). Code search can be used to find calls to wfDeprecated. For instance, to find methods that have been soft-deprecated in 1.39 or earlier, use https://codesearch.wmcloud.org/search/?q=wfDeprecated%5C%28.*%2C+%271%5C.3&files=&excludeFiles=&repos=MediaWiki+core Note however that the version number in the call indicates when the code was //soft// deprecated by tagging it. Sometimes, a method was soft-deprecated for many releases, but only got hard deprecated recently - so a method that says 1.35 in the wfDeprecated call can //probably// be removed, but if that call to wfDeprecated wasn't present in the 1.41 release, then it can't be removed yet. Also, codesearch should be used to double-check that the method in question is no longer used in any deployed code: <https://codesearch.wmcloud.org/deployed/>. If remaining (ungated) usages are found, a ticket should be filed about that issue. NOTE: Each method should be removed in a separate patch. That makes it easier to revert the change in case problems arise.
    • Task
    Some of the functions in certain blueprints of the tool do not have docstrings. Adding these docstrings would give more explanation to what the functions accomplish.
    • Task
    There are several imports which are no longer used with the current version of the application. Removing these imports may improve the load time of the application.
    • Task
    The explanation comment tries to mention `more than **one** language` but rather mentions "more than **on** language" instead.
    • Task
    **Steps to replicate the issue** (include links if applicable): * Try to edit https://commons.wikimedia.org/wiki/File:Unknown_flower_in_Tawangmangu.webm * After finished, I clicked "Overwrite" button, (and then the Upload to Commons button), expecting that it would overwrite that file * The tool uploaded the result as a new file, regardless: https://commons.wikimedia.org/wiki/File:Unknown_flower_in_Tawangmangu_edited_0.webm **What happens?**: I was expecting to overwrite the old video, but instead the result was uploaded as a new file instead, which I didn't wish. I didn't want to try doing it again to reproduce the error. **What should have happened instead?**: When I click "Overwrite", first, it shouldn't offer me this templates `|source={{Derived from|1=blablabla}}` and `{{Extracted from|File:blablabla}}` and then, it should overwrite the file, not create a new file **Software version** (skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.):
    • Task
    The "upright" value of **img_upright** in languages/messages/MessagesHu.php is mistranslated to fennjobbra. Correct translation would be álló. Please replace fennjobbra in the value of img_upright with **álló** Configuration file: [[/source/mediawiki/browse/master/languages/messages/MessagesHu.php$207]], line 207 New value would look like: ``` 'img_upright' => [ '1', 'álló', 'álló=$1', 'álló $1', 'upright', 'upright=$1', 'upright $1' ], ``` Discussion to change this setting: https://hu.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:Kocsmafal_(k%C3%A9pek)&oldid=26177366#K%C3%A9p_upright_param%C3%A9ter
    • Task
    **Feature summary**: ApiQuerySiteinfo should add a siprop 'slotroles' to provide known and defined slot roles including content_model and layout hints. Example response: ```lang=json { "batchcomplete": "", "query": { "slotroles": { "main": { "defined": "", "slot_role_layout": { "display": "section", "region": "center", "placement": "append" }, "content_model": "wikitext" }, "jsondata": { "defined": "", "slot_role_layout": { "display": "details", "region": "footer", "placement": "append" }, "content_model": "json" }, "deprecated": { "slot_role_layout": { "display": "section", "region": "center", "placement": "append" }, "content_model": "unknown" } } } } ``` Example implementation ```lang=php $result = $module->getResult(); $data = []; $slotRoleRegistry = MediaWikiServices::getInstance()->getSlotRoleRegistry(); $definedRoles = $slotRoleRegistry->getDefinedRoles(); $knownRoles = $slotRoleRegistry->getKnownRoles(); foreach ( $knownRoles as $slotName ) { $defined = in_array( $slotName, $definedRoles ); $slotRoleHandler = $slotRoleRegistry->getRoleHandler( $slotName ); $data[$slotName]['defined'] = $defined; $data[$slotName]['slot_role_layout'] = $slotRoleHandler->getOutputLayoutHints(); $data[$slotName]['content_model'] = $slotRoleHandler->getDefaultModel(Title::newFromDBkey( "Main_Page" )); } $result->addValue(['query'], 'slots', $data); ``` **Use case(s)**: Enable bots to check if a slot role is defined and to retrieve it's content model **Benefits**: Currently there's (to my knowledge) no option to direct access this information via API. Fetching revisions of a page only provides access to slot roles already used within a page.
    • Task
    The Wikipedia Library homepage (https://wikipedialibrary.wmflabs.org/ when not logged in) is our default landing page for linking to the library, including in the on-wiki notification. It is very optimised for getting users to log in, but doesn't provide much detail on what the library actually is. We would like to extend it with some content to contextualise what the tool provides access to and why it's useful. The primary audience of this content is Wikipedia editors, particularly those who recently reached the threshold for access, who are coming to the library for the first time and don't know what it is or how it works. **Desktop** {F37034456} **Mobile** {F57559277}
    • Task
    **Feature summary** (what you would like to be able to do and where): Should be at top of the depicts edit box: https://commons.wikimedia.org/wiki/Commons:Depiction_guidelines
    • Task
    People have mentioned in IRC, in the WMCS annual survey, and on Talk pages that https://wikitech.wikimedia.org/wiki/Help:Access_to_Toolforge_instances_with_PuTTY_and_WinSCP needs an update. **Edit:** the similar page https://wikitech.wikimedia.org/wiki/Help:Access_to_Cloud_VPS_instances_with_PuTTY_and_WinSCP should also be updated (or merged with the one above) I suggest the following improvements (there may be more, this is just after an initial review without any subject expertise in this area): [ ] Add an introductory line or two about *why* someone may need or want to read this doc. For example, "To upload multiple files and manage folder structure for your Toolforge account or your tools, you can use an ssh-compatible file or FTP browser instead of the command line." [ ] Improve doc structure: Choosing and installing a file or FTP browser to use seems like the first step, but Filezilla is added as an afterthought at the bottom of the page. Perhaps it should be moved up to an earlier section. [ ] Clarify / link to info about Toolforge bastion servers upon first mentioning them, and standardize the language ("bastion host" vs "bastion server"). https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge#Bastion_hosts. See comment on Talk page as well: https://wikitech.wikimedia.org/wiki/Help_talk:Access_to_Toolforge_instances_with_PuTTY_and_WinSCP#Bastion_hosts [ ] Rewrite the sentence "You are likely going to set up connections to each of the login servers". Instead, tell the reader which server they must set up connections to and why, or tell them to do both. Remove the ambiguity. [ ] Clarify: how does one "Make sure private key is compatible with putty"? How would I know if it wasn't? [ ] Check validity of all screenshots and update them for a reasonably recent version of the software. [ ] Improve the page structure and readability: create subsections for each of the steps under "How to set up...". If you think there's not enough content for page sections, there should at least be a numbered list of steps within each section. In the "How to set up WinSCP" section, crucial instructions are in image captions. The should be placed in normal paragraph text and/or represented as a list of steps. [ ] Review comments on Talk page and add to or update the doc to try to resolve the issues they mention. [ ] Go through the process described yourself, and verify that the information on the page enables you to complete the task of setting up each of the mentioned file transfer tools to connect to a Toolforge account and transfer/create files with the necessary and correct permissions settings. [ ] There seems to be some ambiguity around file permissions and ownership, as indicated by both the Troubleshooting section. If it's a common issue that the file system permissions on the tool directory are easy to mess up, maybe it would also be good to add some additional troubleshooting instructions like what [[ https://wikitech.wikimedia.org/wiki/User:Dvorapa/Toolforge_for_beginners/Daily_basic_tasks | User:Dvorapa has put on their userpage ]] about how to unify ownership even if you changed files under the wrong user or forgot to "become" your tool. (i.e. if owner of files you changed using your browser is username and the owner of files you changed using your command line is my_tool.) With these suggestions, I'm opening this task up for anyone to work on. If you claim this task and have questions, you can get help on one of the Cloud Services communications channels listed here: https://wikitech.wikimedia.org/wiki/Help:Access_to_Toolforge_instances_with_PuTTY_and_WinSCP#Communication_and_support
    • Task
    **Steps to replicate the issue** (include links if applicable): * Go to https://m.mediawiki.org/wiki/Special:Contributions/Hamdsaif * notice the duplicate headers '1 March 2023' above '18 February 2023' and '11 February 2023' above '9 February 2023' **What happens?**: Double date headers on mobile (presumably do to the Flow edits?) **What should have happened instead?**: no double date headers **Software version** (skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.): Chrome 110.0.5481.153 (Android) When inspected the following HTML is present: "<!-- Could not format Special:Contribution row. -->" This inline comment was added by @Bawolff in ede90ac05abc in December 2012 but I'm not sure I understand the circumstances in which it occurs. {F36907849}
    • Task
    Add a mechanism to preview the file text field in VideoCutTool similar to how DiscussionTools does it
    • Task
    Currently, we by default have a file text field while overwriting a file, however this is not desirable since it might lead to important information (such as POTY nominations, mass upload headers, Categories etc) to be lost by overwriting. We should fill the file text field with the exact same data that is already there in the file. {F36893196} == Deliverables - Setup VideoCutTool locally based on the [instructions given in the README file here](https://gerrit.wikimedia.org/r/plugins/gitiles/labs/tools/VideoCutTool/+/refs/heads/master/README.md) - Reproduce the above bug - Make changes and verify that the changes meet the following criteria - When the uploading to commons screen is shown, the file text field should show the exact text that was availiable in the original file should be mirrored - After uploading to commons the text should remain the same (unless the text has been edited).. - Upload a patch for your change to Gerrit [using the following tutorial](https://mediawiki.org/wiki/Gerrit/Tutorial) - Make sure that your commit message aligns with the [commit message guidelines](https://mediawiki.org/wiki/Commit_message_guidelines) - Add @Gopavasanth and @Soda as reviewers for your patch.
    • Task
    Currently, we hard-code the license to the following text, `{{self|cc-by-sa-4.0}}\n`, however, we shouldn't be doing this and instead should be lifting the licensing text from the previous video (we don't want to get into a licensing mismatch issue by releasing it under a potentially incompatible license). {F36893186} == Deliverables - Setup VideoCutTool locally based on the [instructions given in the README file here](https://gerrit.wikimedia.org/r/plugins/gitiles/labs/tools/VideoCutTool/+/refs/heads/master/README.md) - Reproduce the above bug - Make changes and verify that the changes meet the following criteria - When the uploading to commons screen is shown, the file text field should show use the license text in the commons file from which the current file was created. - After uploading to commons the licensing text for both the newly uploaded and old files should be the same (unless the text has been edited). - Upload a patch for your change to Gerrit [using the following tutorial](https://mediawiki.org/wiki/Gerrit/Tutorial) - Make sure that your commit message aligns with the [commit message guidelines](https://mediawiki.org/wiki/Commit_message_guidelines) - Add @Gopavasanth and @Soda as reviewers for your patch.
    • Task
    IMPORTANT: Don't assign yourself this task, but feel free to link to the task using the Gerrit `Bug:` [marker](https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines) Currently there are no tests for VideoCutTool, as a small task, chose one component (in the frontend or backend) of the tool, and write a few tests for it. == Prerequisites == * [[https://reactjs.org/docs/testing.html|ReactJS]] (frontend only) * [[https://testing-library.com/docs/react-testing-library/intro/|React-testing library]] (frontend-testing framework) * [[https://jestjs.io/|Jest]] (backend and frontend testing framework) NOTE: We use `create-react-app` to bootstrap our frontend, `ffmpeg` for the image manipulation, and `mongoose` as the database ORM == Deliverables == - Setup #videocuttool using instructions in the [[https://gerrit.wikimedia.org/r/admin/repos/labs%2Ftools%2FVideoCutTool,general|README.md]] - Pick a component of the tool and write a few tests validating some functionality of the tool (ex: a test to make sure when a user is logged out, the sidebar stops displaying their name) - Run `npm run test` inside the docker container and verify that your test runs without any errors - Create a patch on Gerrit for VideoCutTool and upload your changes. - Make sure your commit message aligns with the [[https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines|Wikimedia commit message guidelines]] - Add @Gopavasanth and @Soda to your patch on Gerrit as reviewers. == Communication == If you have any questions, feel free to reach out on [[https://wikimedia.zulipchat.com/#streams/275007/VideoCutTool|Zulip]] :)
    • Task
    cargo-binstall is a tool to try downloading Rust binaries from their repositories instead of compiling them locally, which can be slow. Metadata needs to be specified in Cargo.toml, see <https://github.com/cargo-bins/cargo-binstall/blob/main/SUPPORT.md>. The toolforge crate publishes a "toolforge-tunnel" CLI, and CI automatically builds binaries when a tag is pushed: <https://gitlab.wikimedia.org/repos/mwbot-rs/toolforge/-/releases>. So for this task, we need to add the correct metadata in Cargo.toml so cargo-binstall can find the published binaries. ---- This is a good first task, let us know if you have any questions! Also take a look at [[https://www.mediawiki.org/wiki/Mwbot-rs#Contributing|mwbot-rs's contributing instructions]].
    • Task
    //Originally filed on [[https://gitlab.com/mwbot-rs/mwbot/-/issues/20|GitLab.com]]// Used by https://github.com/Krinkle/pywiki-fileprotectionsync/blob/master/fileprotectionsync.py#L52 mwapi_responses uses JSON files to represent structs that the API responds with, see https://gitlab.wikimedia.org/repos/mwbot-rs/mwbot/-/tree/main/mwapi_responses_derive/data. You'll need to create a new one for `prop=images`, which is documented at https://www.mediawiki.org/wiki/API:Images. Then you can automatically generate test cases (see https://gitlab.wikimedia.org/repos/mwbot-rs/mwbot/-/blob/main/mwapi_responses/gen_tests.py) and verify they pass. --- Also take a look at [[https://www.mediawiki.org/wiki/Mwbot-rs#Contributing|mwbot-rs's contributing instructions]].
    • Task
    mwbot allows bots to be configured using a `mwbot.toml` file. We want bots to be able to extend it for their own configuration. For example: ```lang=toml [custom] my_key = "foo" [custom.even_more] another_key = "bar" ``` We would store `custom` as `Option<toml::Value>`, and then add a function like `Bot::get_custom_config<T: serde::de::DeserializeOwned>(&self) -> Result<T>` to allow for getting the custom configuration while still being type-safe. --- Also take a look at [[https://www.mediawiki.org/wiki/Mwbot-rs#Contributing|mwbot-rs's contributing instructions]].
    • Task
    //Originally filed on [[https://gitlab.com/mwbot-rs/mwbot/-/issues/12|GitLab.com]]// https://www.mediawiki.org/wiki/API:Protect - note that any new errors need to be added to mwapi_errors. Ideally the function would be named `mwbot::Page::protect(...)`. You be able to borrow some code from https://github.com/legoktm/tfa-protector-bot/blob/f1a933552ce790cbcf2fa9318988da51aff04a2a/src/main.rs#L207 ---- Also take a look at [[https://www.mediawiki.org/wiki/Mwbot-rs#Contributing|mwbot-rs's contributing instructions]].
    • Task
    Many integration tests involve database access. For example, they use: * LBFactory::getDatabase() * LoadBalancer::getConnection() All of these methods involve a DBConnRef that properly handles the database domain (e.g. what $db->getDomainId() returns). However, MediaWikiIntegrationTestCase has a member field called "db", which was provided for easy access to a database handles. The problem is that it was created before DBConnRef and just directly points to a Database object (instead of a DBConnRef wrapper). This makes usage of MediaWikiIntegrationTestCase::db idiosyncratic and subject to unexpected database domain changes due to other code getting a connection to a domain that is not the current one. The field is currently defined using an LB method that is supposed to be internal: ``` $this->db = $lb->getConnectionInternal( DB_PRIMARY ); ``` This fix for this is to: [x] Fix uses of $this->db that block https://gerrit.wikimedia.org/r/c/mediawiki/core/+/519305 [] Remove use of $this->db from subclasses of MediaWikiIntegrationTestCase that override the field (e.g. `$this->db = ...` in setUp()) but can just use MediaWikiIntegrationTestCase::getDB() in each test function. For example, DatabaseIntegrationTest currently has `$this->db = MediaWikiServices::getInstance()->getConnectionProvider()->getPrimaryDatabase()`. [] Remove use of $this->db from subclasses of MediaWikiIntegrationTestCase that rely on the parent class to set the field. They can use MediaWikiIntegrationTestCase::getDB() in each test method instead. When grepping, note that many classes do harmless things like `$this->db = new DatabaseTestHelper(...)` and are not subclasses of MediaWikiIntegrationTestCase. Code search: https://codesearch.wmcloud.org/search/?q=-%3Edb-%3E&files=Test%5C.php%24&excludeFiles=&repos=
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): ``` var api = new mw.Api(); var params = {format: 'json',action: 'parse',mobileformat:false,disablelimitreport:true,pst: '1',prop: 'text',formatversion: '2',text:'<div class="nomobile">this div has the nomobile class but mobileformat is disabled, so if you\'re not seeing this it\'s a bug.</div><div>You\'re not seeing it, are you?</div>'}; api.post( params ).done( function ( data ) {console.log(data.parse.text);}); ``` As mobileformat is false it gets stripped [[ https://en.wikipedia.org/w/api.php?action=help&modules=main#main/datatype/boolean | which is expected ]]. So you can just as well omit it, makes no difference. **What happens?**: On https://en.wikipedia.org/wiki/Main_Page: ``` <div class="mw-parser-output"><div class="nomobile">this div has the nomobile class but mobileformat is disabled, so if you're not seeing this it's a bug.</div><div>You're not seeing it, are you?</div></div> ``` On https://en.m.wikipedia.org/wiki/Main_Page: ``` <div class="mw-parser-output"><section class="mf-section-0" id="mf-section-0"><div>You're not seeing it, are you?</div></section></div> ``` **What should have happened instead?**: Get both divs regardless of domain as mobileformat:false was specified. Or there should be a "nomobileformat" (or "desktopformat") option. Whatever. The only way to get wikitext parsed in desktop format on the mobile domain is using a super ugly hack.
    • Task
    Ideally I as a power user would like to be able to report a bug with 1 click. 2 is passable, but then it should be very easy and visible and simple. Dolibarr has a "Report a bug" link in the left menu on every single page. It automatically prefills the github issue with information about the installation. Very nice experience! **List of steps to reproduce** (step by step, including full links if applicable): * * * **What happens?**: **What should have happened instead?**: **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**:
    • Task
    The download box (#coll-downloadbox) at Special:Book has been disabled for years now and just serves to be confusing. It should be hidden or removed until if/when it's actually possible to download books again.
    • Task
    In fc745f5dfb483766e12cf4123ef08cc1427d37a4, support was added that allowed PagelistWidget to retrieve all of ProofreadPage's builtin labels using `mw.config.get( 'prpPagelistBuiltinLabels' )`. We should use this to build the default configuration returned by `PageNumberInputWidget.getNumberTypeConfig()` when no configuration file is found. == Documentation == - [Tutorial on setting up and working with Gerrit](https://www.mediawiki.org/wiki/Gerrit/Tutorial) (Gerrit is Wikimedia's code review platform) - File that needs to be modified: [PagelistInputWidget.PageNumberInputWidget.js](https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/ProofreadPage/+/refs/heads/master/modules/index.pagelist/PagelistInputWidget.PageNumberInputWidget.js) - [OOUI](https://www.mediawiki.org/wiki/OOUI) (the framework used to build PagelistWidget) - [Documentation regarding the configuration file syntax](https://www.mediawiki.org/wiki/Help:Extension:ProofreadPage/Pagelist_widget#Configuration_(for_wiki_admins)) == Criteria == - The default config should contain all the builtin types offered by ProofreadPage dynamically generated using `mw.config.get( 'prpPagelistBuiltinLabels' )`
    • Task
    When the PagelistWidget dialogue window is opened for the second or third time, there is no loading animation for the first image. == Reproduction steps == - Open an Index: page ( ex: [[http://localhost:8080/wiki/Index:War and Peace.djvu|Index:War and Peace.djvu]]) - Navigate to edit mode - Click on "Preview pagelist" - Click on any of the generated page numbered buttons to open a popup - Inside the popup navigate to a different page == Documentation == - [Tutorial on setting up and working with Gerrit](https://www.mediawiki.org/wiki/Gerrit/Tutorial) (Gerrit is Wikimedia's code review platform) - File that needs to be modified: [PagelistInputWidget.ImagePanel.js](https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/ProofreadPage/+/refs/heads/master/modules/index.pagelist/PagelistInputWidget.ImagePanel.js) - [OOUI](https://www.mediawiki.org/wiki/OOUI) (the framework used to build the PagelistWidget) == Criteria == - Loading animation should be shown even for the first image everytime.
    • Task
    I had a quick look, and none of the onwiki documentation seems to say how to reset a BotPassword. For example, pages such as https://www.mediawiki.org/wiki/Manual:Bot_passwords. There's probably other places this should be documented too It's fairly simple, instructions such as this should suffice ``` Visit Special:BotPasswords. Re-auth; both password and 2FA will be needed if you use 2FA. Click on the relevant entry under "Existing bot passwords". Check "Reset password" and then click update at the bottom. It will give you a new password. ```
    • Task
    ### Background [Wikimedia tutorials](https://www.mediawiki.org/wiki/Wikimedia_tutorials) is a page on mediawiki.org intended to help people learn about Wikimedia technologies by aggregating both on-wiki and off-wiki tutorials. To help people choose a tutorial, the page uses topic tags via [Template:Topic](https://www.mediawiki.org/wiki/Template:Topic). ### To do - [x] Create a user script as a proof of concept for adding filter behavior based on topic tags. See https://www.mediawiki.org/wiki/Gadget_kitchen for more information on user scripts. - [] [In progress] Review and test - [] Start the process of enabling it as a gadget on the Wikimedia tutorials page ### Concept Create a gadget (prototype as a user script!) that adds search/filter behavior to the page by first walking the DOM to extract the topics, keywords, etc that can be used for filtering. Then add inputs to the page via js that are bound to events that walk the collected data and show/hide divs as appropriate. The js used in [Hay's Directory](https://hay.toolforge.org/directory/) is relatively easy to understand. Template:Topic adds a `data-topic="..."` attribute now. Something like `$("span[data-topic=Python]")` will find all the "Python" topic tags. And something like `$("span[data-topic=Python]").parents(".mw-tpl-colorbox").css( "border", "2px red solid" )` would then highlight the cards that contain the Python topic tag.
    • Task
    Several Node.js services based on `service-template-node`[1] include a `static/index.html` file with old HTML, which keeps showing up when doing skin or JS related migrations/deprecations[2]. These likely don't render well currently and also may no longer match current MW output behavior. These are usually not served to clients behind RESTBase and serve no purpose besides demonstrating how to serve a static file. This task is to either simplify the HTML or remove the file. If we remove the file we should consider to also disable serving of static files in app.js[3]. List of repos with this file[2]: [x] mobileapps [x] wikifeeds [] recommendation-api ~~[] trending-edits~~ ~~[] graphoid~~ [1] https://github.com/wikimedia/service-template-node [2] https://codesearch.wmcloud.org/search/?q=ResourceLoaderDynamicStyles&i=nope&files=html%24&repos= [3] https://github.com/wikimedia/service-template-node/blob/master/app.js#L236
    • Task
    If a sysop or oversighter revdels/suppresses a username on a given revision, someone with those same perms will see at Special:Contributions that revision followed by the following html: `<strong>[username or IP address removed – edit hidden from contributions]</strong>` There's no span and no class, so it can be a bit of a pain to access; at the very least, it stands out from everything else. I'm not sure on ideas for a class; `history-deleted` will gray and cross-out the message, which is //not// what would be wanted here.
    • Task
    When using the #Minerva skin (a.k.a. #mobile) there is no info icon to open the help popup, or the info icon is heavily misplaced. As of 2020: {F31855010} As of 2022: {F35151029} It looks like the reason is **not** the placement of the icon, but some misplaced `form { width: 90%; }` in the #Minerva CSS. This reduces the width of the form to 90% * 90% = 81%, while the icon is still placed at the right corner of a 90% wide rectangle. These `90%` need to be removed/reset. Here is a debug view that highlights the problem. The lower blue box should be as wide as the top blue box. The placement of the (i) icon on the right is actually correct. {F35151046} --- Instructions when working on the task: [] Install the #two-column-edit-conflict-merge extension [] Install and use the #minervaneue skin [] Figure what CSS could fix the issue [] Put it into an extra .css file under `/modules/SplitTwoColConflict` in the #two-column-edit-conflict-merge extension repo `ext.TwoColConflict.Split.minerva.css` If you need help along the way, feel free to poke @WMDE-Fisch
    • Task
    As part of T187154#6034369 I noticed the following on enwiki in production: ```lang=json "wgConfigRegistry": { "vector": "GlobalVarConfig::newInstance", "cite": "GlobalVarConfig::newInstance", "categorytree": "GlobalVarConfig::newInstance", "timedmediahandler": "GlobalVarConfig::newInstance", "CirrusSearch": "CirrusSearch\\SearchConfig::newFromGlobals", "globalcssjs": "GlobalVarConfig::newInstance", "globaluserpage": "GlobalVarConfig::newInstance", "ApiFeatureUsage": "GlobalVarConfig::newInstance", "templatestyles": "GlobalVarConfig::newInstance", "ArticleCreationWorkflow": "GlobalVarConfig::newInstance", "popups": "GlobalVarConfig::newInstance", "visualeditor": "GlobalVarConfig::newInstance", "citoid": "GlobalVarConfig::newInstance", "mobilefrontend": "GlobalVarConfig::newInstance", "minerva": "GlobalVarConfig::newInstance", "textextracts": "GlobalVarConfig::newInstance", "RelatedArticles": "GlobalVarConfig::newInstance", "revisionslider": "GlobalVarConfig::newInstance", "ExternalGuidance": "GlobalVarConfig::newInstance", "mwoauth": "GlobalVarConfig::newInstance", "quicksurveys": "GlobalVarConfig::newInstance", "PageViewInfo": "GlobalVarConfig::newInstance", "ReadingLists": "GlobalVarConfig::newInstance" } ``` It seems a fairly small and arbitrary subset of extensions are using this to create their own copy of GlobalVarConfig, but I can't tell whether this is unguided copy-pasta or adding value for someone. E.g. what is the value today in Cite doing `ConfigFactory::makeConfig('cite')` compared to `getMainConfig()`? Being able to have separate objects and multiple sources of configuration is certainly useful. And being able to read config from Etcd like we do in production already is an example of that. (ConfigFactory is great, I'm not suggesting we change anything about that). But the way some extensions anticipate some imaginary future where extensions might have their own config source, is not serving a clear purpose to me. Especially since 1) afaik it is still to-be-determined how and when that would work and 2) there is no restrictions enforced right now on what this object should or shouldn't be capable of. That is, there is nothing stopping Cite from using its copy of the Config to also read out core configuration variables. I've already seen developers be confused by this, thinking the local object should be used for all config keys, including when you need those from core. If there is an intentional and tangible benefit from this today, this task will track documenting that as a best-practice to eventually being adopted across the board. I not, I suggest we remove this pattern from the few extensions that accidentally adopted it in favour of using the Config object from the Service container like everything else does. See also: * {T249257} * {T155154}
    • Task
    https://wikitech.wikimedia.org/wiki/Help:Toolforge/My_first_Django_OAuth_tool contains inaccurate information. [] Check to see if the information and workarounds outlined in this taks are still appropriate: https://phabricator.wikimedia.org/T198508 [] If the changes are still appropriate, integrate into the documentation [] Review for further inaccuracies and update. This would make a good document for a hackathon sprint or possibly first bug depending on knowledge level.
    • Task
    # Problem You can add yourself as a subscriber of document changes, even you are unauthorized to see the documents. # Proposed solution Prohibit users who do not have permission to see documents to subscribe to document changes. Student is expected to send a patch for `wikimedia-cz/tracker` repository, hosted at Wikimedia Gerrit. When claiming task on GCI website, student should claim a respective Phabricator task as well. # Materials * [Tracker in production](https://tracker.wikimedia.cz) * [Test Tracker version](https://tracker2.wikimedia.cz) - you can play with Tracker freely here * [Codebase](https://gerrit.wikimedia.org/r/admin/projects/wikimedia-cz/tracker)
    • Task
    # Problem Tracker contains some `user.is_staff` checks, which can expose some information even to admins with no permission to see it. Example of this is in `viewsets.py`. or `importcsv`/`export` in `views.py`. This is problematic because user who is a staff can have zero permissions assigned, and thus, actually have no advanced permissions. # Proposed solution Please fix one occurance of this bug. You should use your own judgement if a new permission would be appropriate, or if one of Django default permissions can be reused. Student is expected to send a patch for `wikimedia-cz/tracker` repository, hosted at Wikimedia Gerrit. When claiming task on GCI website, student should claim a respective Phabricator task as well. # Materials * [Tracker in production](https://tracker.wikimedia.cz) * [Test Tracker version](https://tracker2.wikimedia.cz) - you can play with Tracker freely here * [Codebase](https://gerrit.wikimedia.org/r/admin/projects/wikimedia-cz/tracker)
    • Task
    Currently, some information is displayed as a caption covering the lower part of the image. It is sometimes problematic because it hides important elements that need to be depicted. Here is an example where almost half the image is hidden. {F30582552} It would be great if this information was displayed elsewhere, for example with the rest of the other information just below :) Thanks in advance!
    • Task
    When creating adding a references list to an article, we always add a References header if it doesn't exist yet. The References list tool should do it for us. Current workflow: # Create a References header # Insert > References list (to add the References list) Desired workflow: # Insert > References list (to both create a References header if not existing and add the References list) This is actually a feature of the wikitext editor standard toolbar on :en and :fr wikipedias: {F30543032} {F30543034}
    • Task
    # Problem Each time someone changes their bank account number, administrators needs to know, so the reimbursement processs is not delayed unecessarily. # Proposed solution Anyone being able to see bank account should be able to subscribe to a notification that would be fired when an user changes the bank account number. The notification should be part of the daily digest. Student is expected to send a patch for `wikimedia-cz/tracker` repository, hosted at Wikimedia Gerrit. When claiming task on GCI website, student should claim a respective Phabricator task as well. # Materials * [Tracker in production](https://tracker.wikimedia.cz) * [Test Tracker version](https://tracker2.wikimedia.cz) - you can play with Tracker freely here * [Codebase](https://gerrit.wikimedia.org/r/admin/projects/wikimedia-cz/tracker)