User Details
- User Since
- Oct 9 2014, 8:09 PM (498 w, 1 d)
- Availability
- Available
- LDAP User
- Tacsipacsi
- MediaWiki User
- Tacsipacsi [ Global Accounts ]
Today
Reference Previews is the extension (which was fixed in T358242), not the gadget.
Thanks!
Thanks @KStoller-WMF! However, as you updated the acceptance criteria, I noticed that those are also accurate. You wrote “an account that does not have edit access” – but there’s no such thing: a user may have edit access to one page but not to the other. So each Community Configuration configuration needs to be checked for edit access individually (even though usually the result will be the same for all).
Yesterday
User Story:
As a logged out users or logged in non-admin, I want to be able to view configuration options, because Community Configuration is protected and only editable by admins.
When a non-admin user goes to Special:CommunityConfiguration and selects a provider to edit, they are unable to change any of the form fields
Thu, Apr 25
Looks good, thanks!
You’re basically adding two comments in two topics, one of which is unsigned (the talk header). The PHPDoc in rEDTO includes/CommentUtils.php:729-735 (at 1130ab2491fa8bbfcb8113fbc0a35cd1725a9356) starts with Assuming that the thread item set contains exactly one comment (or multiple comments with identical signatures […]) – this assumption doesn’t hold. Maybe it would work if you signed the talk header, but of course signing a talk header doesn’t make any sense.
Well, it’s true that marking the page for translation won’t edit the page (if you didn’t add the unit ID, marking for translation would edit the page to add the auto-generated ID).
Wed, Apr 24
Yes, except that the link (tab) could appear on every page action (including view, source code editing etc.) rather than only on the history action; and that I used wrong terminology: it’s a view, not a content action. You can use SkinTemplateNavigation::Universal.
Tue, Apr 23
It may be for another bug, but the display is still not perfect: the toggle icon (triangle in front of the summary text) doesn’t appear due to rSTIM resources/libraries/normalise.css:39 (at e33b34517f07):
Thanks for the screenshots! First, I think it should have a bit more right margin. Second, I think I personally would prefer it being vertically aligned to the top rather than the middle. Have you pushed the code anywhere, or is it only on your machine yet?
Mon, Apr 22
I don’t think there will be the same count inline: first, I don’t imagine this feature to be as obvious as the file upload button/link; and second, it can be used only by people who know how to copy the source code of an SVG (or know that an SVG has a source code at all, i.e. that it’s a textual format).
Inline SVG, being part of the wikitext, should be CC BY-SA 4.0, just like other parts of the wikitext. It’s mainly useful for graphs that visualize data specified in template parameters or Wikidata; it shouldn’t replace SVG uploads. Logos should continue to be uploaded as before, and logos included inline should be treated like any other form of copyright violation. (I think it will mainly be used through meta-templates and meta-modules, not directly, so a simple search for inline:svg inline:/\<svg/ will have very few false positives. So checking can happen through for example simple searches, bots, AbuseFilter or Toolforge tools.)
Sun, Apr 21
I don’t imagine these advanced things being used much. While the third option would be by far the most powerful, I don’t it would be by far the most useful.
Ah, I see. We tested two completely different pieces of software:
Sat, Apr 20
File description pages can exist without a file existing (manually created pages in the File namespace) and files can exist without description pages existing (Commons files without local description pages), so title.exists and title.file.exists are independent. I propose declining this task.
I don’t like when messages used on-wiki are translated on translatewiki.net:
I created two additional test pages:
- https://patchdemo.wmflabs.org/wikis/83a92cb3f0/w/index.php?title=Test3&action=edit&undoafter=157&undo=158 tries to undo the oldest pending revision while not undoing a later pending revision, shows the checkbox as expected
- https://patchdemo.wmflabs.org/wikis/83a92cb3f0/w/index.php?title=Test4&action=history: I actually reverted a change where the checkbox didn’t appear (as expected), it got autoreviewed as expected
I think it just got even more confusing:
I hope this Phase 5: (Later) doesn’t mean Parsoid read views will be enabled on wikis with language conversion (even in talk namespaces) before this is done.
Sorry for being nitpicking, but I don’t like this position either: I’d think it copies the message ID (which would also make sense), not the original text.
Wed, Apr 17
Even WMF wikis do have sometimes interwikis even now, eleven years after Wikidata going live (e.g. when topics don’t perfectly match up in different languages) – although probably few enough that they on their own don’t justify a genfix. However, if Wikia/Fandom continues to rely on them, maybe this task should be declined?
They shouldn’t be blindly deleted. If they still exist, it’s probably because articles in different languages don’t perfectly match up. Interwikis should be removed only in one of the following three cases:
Tue, Apr 16
(By the way, it was me who proposed calling .json() in https://gerrit.wikimedia.org/r/c/wikimedia/portals/+/1008109/comment/62e991ae_ea557d44/ without thinking enough about it. Sorry.)
Instead of trying if the response is JSON, I think httpGet should have a second parameter that specifies whether it is. I tried this:
I don’t think it’s that broken that it would warrant UBN, but I do think there’s room for improvement even from the screenshots @Samwalton9-WMF shared. It’s not terrible, but not nice either.
Because, as I said, it gives the impression that VE is supported – an impression that couldn’t be further from the reality. It’s not only unsupported, it’s known to be broken.
Mon, Apr 15
The extent to which it’s a subtask of T343454: Use Codex CSS components or OOUI form instead of mediawiki.ui in Translate may be resolved, but I don’t think the result is particularly a “solid base that's easy to extend”. It mixes a JavaScript frontend (that actually provides nothing more in its current state than a pure-PHP version would) and a Mustache-based template, Codex classes with title search provided (and styled) by searchSuggest.js. It’s more like an experiment showcasing as many technologies as possible than a solid base that’s easy to extend. 🙂
I think we shouldn’t give the impression that VE is supported (by showing the edit notice) before fuzzy messages are marked at least as visibly as in the wikitext editor, because it’s now broken without the breakage being obvious. (Not supporting translation variables is another thing: it’s broken in an obvious way, so users are able to decide if they want to use VE regardless.)
Sun, Apr 14
Should be fixed by d1eb5cc8a4c1.
Did anyone test FlaggedRevs usage using API on MediaWiki 1.40.0 or higher?
Why would be the third one “by far” the most useful? I’d think most use cases can be satisfied by either of the first two, especially if TemplateStyles is allowed within the SVGs. Of course, there are some cases that can be satisfied only by the third option (say, using CSS variables defined in wikitext), but they aren’t that important.
Fri, Apr 12
As far as I see, it’s executed at most once per parse (assuming that ContentAlterParserOutput is called at most once), so it should be safe to continue using ParserOutput::setExtensionData. (It sets an array, but in one pass. And the order matters, which is not guaranteed if the set behavior of ParserOutput::appendExtensionData is taken seriously.)
Thanks for filing the task and fixing the bug!
Being a decade-old bug, I think it’s newsworthy that it has been fixed (draft added to Tech/News/2024/16).
Thu, Apr 11
It’s very unclear to me which icon means what. I’d probably put the clear button within the textarea, similarly to how Codex does with text inputs (although Codex itself doesn’t support the clear icon on text areas).
Couldn’t the action=history page be made linking back to Special:CommunityConfiguration? Similarly to VisualEditor’s Edit link, Community Configuration provides an alternate edit view of the same page, so putting its link among the content actions would make sense. (And even vice versa: simply call Skin::setRelevantTitle() on Special:CommunityConfiguration, which gives a history link, a talk page link etc. for free.)
Wed, Apr 10
Tue, Apr 9
I’ve created a patch demo. I thought the edit notice would be awfully long, but it’s actually not that bad (log in with Patch Demo / patchdemo1 and open https://patchdemo.wmflabs.org/wikis/1f6668b3c1/wiki/Translations:Main_Page/1/en?veaction=edit or https://patchdemo.wmflabs.org/wikis/1f6668b3c1/wiki/Translations:Main_Page/1/hu?veaction=edit).
- Suggest to start with ContentNamespaces and content model being wikitext
Thanks! I’ve used Timeless on Translatewiki for some years, and it always annoyed me, but not enough to file a bug report…
Actually, a “not stable yet” pages list in addition to the proposed pages list would make sense (assuming that pages that don’t need translation are more or less consistently marked as such): these pages need to be checked from time to time to see if they still aren’t stable yet.
The fourth one is actually something that’s quite possible to cause issues in DiscussionTools as well: DT doesn’t work with very old timestamps (T350633), and an integer overflow can turn your seemingly current timestamps into very old ones.
Mon, Apr 8
Thanks! However, there’s a bug: Tux doesn’t warn me when I try to translate the page into either Hindi or Hungarian, nor is the save button disabled if I change/add the translation. Is that a regression from this task, or an independent regression?
Thanks!
Sun, Apr 7
Since @adrelanos stated that the upgrade broke this, i.e. it used to work, I find it unlikely that it’s a problem with user groups – why would an upgrade remove any user from a group?
The skin style is already there (in the FlaggedRevs repo), the notice already looks quite different on Minerva than on other skins. So fixing the color contrast in that skin style wouldn’t worsen the consistency situation between skins (granted, it wouldn’t improve it either).
Sat, Apr 6
Wed, Apr 3
This task is about message bundles – message groups specified on JSON-formatted wiki pages. JSON files stored in Gerrit work differently: they already support documentation (qqq.json), and they also have some metadata, but in the translatewiki repo rather than next to the messages. (It may be worth expanding the metadata and moving in the extension repos, but not in this task.)
Couldn’t just the translation pages be imported as-is, just like any other imported page? Translate prevents direct editing of translation pages, but it can make an exception and allow itself to do those direct edits.
As far as I understand, it powers the review state box visible on the top right on https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0?safemode=1 – ruwiki uses Common.css to hide the box, but FlaggedRevs cannot know this in advance. I see two options:
Tue, Apr 2
If I wanted to see who are the authors of a translation, I’d probably press the History tab on the translation itself, not the history links of each and every translation unit – and thus see FuzzyBot as the only author. If I wasn’t a translator, I’d probably not even know about the per-translation unit histories. So I hope translation pages themselves can also have histories migrated, not only units.
Lingering questions:
- Is this doable?
Translate allows translating pages, not forms. If you want to have a localized form, I think chances are better with VisualEditor and TemplateData, as TemplateData natively supports translating parameter labels and descriptions (of which a form is composed). It also allows dropdown lists for parameter values, although the list items are not localizable yet (T292969).
The task title is about the edit summary, the description is about the diff. Which one is a copy-paste error?
Sat, Mar 30
A tangential comment: I could change and save the configuration on eswiki beta without getting any error message. Of course, the configuration wasn’t in fact saved, since I’m not an admin or interface admin there. While it’s useful in this testing phase that I can try out much of the interface even if I don’t have rights, it shouldn’t remain this way in the finished version.
This seems to be because Special:ExportTranslations doesn’t allow exporting discouraged message groups (rETRA src/Synchronization/ExportTranslationsSpecialPage.php:135 (at 6fd67a881b9e)), but apparently the JavaScript-based message group selector doesn’t consider this (if you disable JavaScript, you can’t select the group in the first place). So there are two ways to restore consistency: