I started working with Wikimedia since Feb, 2019. My primarily work will be on the Translate extension and translatewiki.net.
Fri, Nov 27
Assigning to Niklas since he is primarily working on this.
Replaced all occurrences of .show, .hide, .toggle and added ESLint rule: no-jquery/no-visibility that will throw errors if these are used in the future.
Thu, Nov 26
@Yaron_Koren - The problem with the current system on Anvesha is that it can handle 2 plural forms fine, but anything more than that I expect it will have problems.
Also - what is wrong with that i18n message?
I was able to get Translate setup with MariaDB also, incase needed. Some notes related to that are here: https://www.mediawiki.org/wiki/User:APatro_(WMF)/Docker_Translate
Wed, Nov 25
Tue, Nov 24
In addition to the template, added,
Mon, Nov 23
Submitted separate patches to remove usage of .hide / .show from the each pages. After these are merged, do another sanity check to ensure all instances are removed, and then add an eslint rule.
Sat, Nov 21
Ran setup-03-launch-mediawiki-docker.sh from the docker scripts.
Wed, Nov 18
Mon, Nov 16
Reviewed the documentation. Discussed and made a few changes.
Mon, Nov 9
Auto merge, and i18n checks are running properly now. Also updated the project page with the general template.
Thu, Nov 5
Added web-plugin to automerge.
Moving to recheck after deployment. Will run exports today, and if all goes well, can mark this as done.
Via series of patches, strings have been added to the ignored / optional list.
After release, this bug - T267260: PHP Notices generated by GettextFFS.php & missing new-lines in export.php was reported but its not severe enough to do an out of schedule release. Marking this as resolved.
Wed, Nov 4
Tue, Nov 3
OK, better. I can see the strings for translation here: https://translatewiki.net/wiki/Special:Translate?action=translate&group=wmcz-web&filter=%21translated
@Urbanecm Yup, looks good to me.
@Urbanecm - We've deployed the patches on the twn server but are having problems with empty groups.
Mon, Nov 2
Oct 29 2020
Had some discussion with Niklas regarding the documentation. This is now ready for release.
MLEB 2020.10 has been released. Moving this task to done, but leaving it open for few days to gather any issues reported.
This was fixed and tested as part of the weekly translatewiki deployment and for MLEB release.
B/W code from the Translate extension has been cleaned up to support 1.34 and above, and hence by extension, MLEB as a whole also will now only support MW >= 1.34. We decided to not update the code for the other individual extensions to MW >=1.34 only.
This fix was tested and released along with MLEB 2020.10
We've released a new version of the language-data library: https://github.com/wikimedia/language-data/releases/tag/1.0.3
Oct 27 2020
PR to update the Changelog: https://github.com/wikimedia/language-data/pull/125
Oct 26 2020
Submitted the following patches:
Oct 20 2020
Oct 19 2020
Working on this since we would like to have this for MLEB release
Oct 16 2020
Related patch has been deployed and merged on translatewiki.
Oct 14 2020
Oct 13 2020
Automatically created PR from translatewiki: https://github.com/wikimedia/apps-android-wikipedia/pull/1700
Oct 12 2020
Related patch has been merged, to check during next export.
Oct 1 2020
The data in the graph cannot be read because its in a canvas, but I was expecting it to read out the table. I'll check with Niklas, who tested it with NVDA on Windows.
Development on all tasks (and bugs) under this task is done and deployed. Currently waiting for QA on T263543: Improve accessibility for the Translation statistics and configuration change for T264158: Stat type registrations is too slow for Wikimedia production
Marking this as resolved as Niklas reviewed the document.
@Jpita, Yes, that is the expected behavior. I would check to ensure that the text spoken by the voice assistant conveys the data in the graph / table accurately.
@MattCleinman - Using our current infrastructure it will not be possible to run those specific script so that Github action will have to remain in place but we can remove these sections of the Github action to create a PR, and possibly remove theGitHub access token incase its not being used anywhere.