In T303627#9744947, @cscott wrote:

I think even visual editor will "just work", because as I said we already have an escape mechanism that allows VE to insert arbitrary content (including <!-- and --> inside a comment). See https://en.wikipedia.org/wiki/User:Cscott/T303627 -- if you round-trip this you get <!-- this is a comment including <!--T:1--&gt; a translation marker --> which is the "proper" way to include content with --> inside a comment. I'm not sure I'd call that a dirty diff. If you wanted to get really fancy you could teach Translate to recognize <!--T:1--&gt; as a valid translation marker and just call that the "proper" way to escape translation markers inside a comment.

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).

In T333384#9742903, @Jdlrobson wrote:

There’s a namespace tab saying Your lists on Vector 2022, which became default on Meta in the meantime in T349544 (I don’t know if it was there on Vector 2022 when I opened this task). Couldn’t that be hidden, just like on many other special pages like preferences or contributions?

Yeh I think the additional tab should be removed. Opened: T363418

In T311521#9740644, @abi_ wrote:

I made some more tweaks based on discussion with Pau to align the copy button with the X icon always.

In T210784#9602604, @Michael wrote:

As I understand it, what @Tacsipacsi writes is correct. Wikidata sitelinks are disabled on the main namespace of Wiktionary wikis, because that namespace is intended for the actual entries (words), not for things like the main page of a wiki.

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.

In T362203#9739550, @Cyndymediawiksim wrote:

However, this approach could lead to a situation where there is no obvious way for users to navigate back to the Special:CommunityConfiguration page from the history page as @Urbanecm_WMF highlighted above.

In T338750#9737243, @Tacsipacsi wrote:

Vector-2022	Timeless

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):

In T311521#9737097, @abi_ wrote:

I had misunderstood Pau. I reverted to the old design and improved the alignment which is what Pau actually meant.

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?

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.)

In T362125#9720129, @stjn wrote:

That should be fixed

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:

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:

In T358242#9729476, @ssastry wrote:

These work everywhere now, but the reference previews are slightly different from legacy ... the content selection code in the reference preview code probably needs an update for Parsoid's cite output. The difference is especially obvious for named references, unless of course the new output is the preferred version. :)

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.

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:

In T353996#9721766, @IKhitron wrote:

What should I do?

In T311521#9721202, @abi_ wrote:

The reason I did not make it always visible was because it tends to cover up the content.

(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.

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.)

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.

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).

In T360919#9708233, @KStoller-WMF wrote:

I was actually thinking the same thing and almost suggested the full protection language, but it seems like that might not be a common term across wikis. Perhaps the notice could be something like:
"This page is protected. Configuration of this feature is only editable by administrators."

In T275370#9708226, @Wargo wrote:

Code says AND, regardless of what should be.

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).

In T275370#9705139, @aaron wrote:

The user needs movestable or review.

In T354463#9674654, @Tacsipacsi wrote:

• The summary box is huge. In one design, it’s a two-line textbox, in the other one, it’s a one-line input; in the implementation, it’s eight lines tall. This gives the impression that the edit summary can be however long I want it to be (and indeed, nothing on the frontend prevents me from writing an over 1000 characters long summary, even though the backend (MW core) caps the summary at 500 characters).

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.)

In T360919#9705017, @JFernandez-WMF wrote:

Dashboard:

In my previous comment, I commented on the possibility of using a tooltip/popover to convey the meaning of the 'lock' icon. Since this component is not in Codex (yet!) we should find an alternative that allows for Codex usage. One option is using an InfoChip with the editlock icon and an explanation (we could change the 'Read-only' language to something more appropriate or more explanatory).

In T362139#9701584, @matmarex wrote:

(There's also a comment in that code that says "check not shown when editing old revisions, which [would be] confusing", and preparing a revert of the latest revision is a lot like editing the previous revision.)

In T248416#9702465, @Archimedes5000 wrote:

I would have expected the skin to be adjusted for use on desktop devices.

In T362125#9702016, @stjn wrote:

Is there any way to differentiate page-wide translations like MediaWiki translations from these translation units translations? Because making Translate extension compatible can be limited to page-wide translations then so there’s less confusing code.

In T362044#9700836, @Trizek-WMF wrote:

or toggles

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

In T238885#9675315, @Jdlrobson wrote:

Suggested changes

With a single change this looks a lot better (see screenshot) :

• Move class onto li element and remove the span.

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.

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!

In T275370#9695713, @Wargo wrote:

Currently, user must have […] review […] rights, not autoreview.

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).

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:

In T350514#9683008, @Jdlrobson wrote:

https://gerrit.wikimedia.org/g/mediawiki/extensions/FlaggedRevs/+/aa366934663d316a4ef13b0522478820332a0041/includes/frontend/FlaggedRevsUIHooks.php#996

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.

In T361632#9682154, @Varnent wrote:

I have not checked all other uses of the extension

Lingering questions:

• Is this doable?

In T354463#9679542, @Cyndymediawiksim wrote:

what should be the correct number of lines given the backend (MW core) caps the summary at 500 characters)?

In T361512#9680527, @JWheeler-WMF wrote:

For clarity, I am discussing localizing and/or translating the form fields so that the form is accessible in a user's native language. Example image of a form field below.

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).

In T360919#9658466, @Urbanecm_WMF wrote:

Technically-speaking, let's treat anyone with editsitejson permission as admins.

The task title is about the edit summary, the description is about the diff. Which one is a copy-paste error?

In T358035#9663753, @JFernandez-WMF wrote:

• @KStoller-WMF agreed with me in T354463#9625135 that the (optional) label is odd.

I completely agree with this, however I raised this with the Design System team commenting our specific use case, and it has been recommended for us to still use the (optional) label. An alternative they suggested is to reinforce the importance of the edit summary a little bit more by adding a description that says that 'entering an edit summary is highly recommended'. @Tacsipacsi Curious to know your thoughts about this approach?

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.

In T354463#9671719, @Etonkovidova wrote:

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:

Not really. Given simplewiki, T253387 should give simple and wikipedia, as simple is a valid “non-standard language code” (i.e. a language code that is known to MediaWiki but isn’t valid, or has a slightly different meaning, in BCP 47). Given simple, this task gives en-simple, which is the BCP 47 language tag for Simple English.

In T359986#9667941, @MusikAnimal wrote:

It's listed at https://doc.wikimedia.org/index/. I've just added a patch to have it added to the "Components" list on the doc homepage.

Couldn’t it be just a warning, like in the action API? There are cases in which it’s less convenient or even hardly possible to ensure no extra fields:

I don’t see it listed on https://doc.wikimedia.org/, don’t we need yet another patch to add it to the listing?

Won't fix

• jQuery.client docs available at https://doc.wikimedia.org/jquery-client/master/jQuery.client.html

This is not specific to mobile, the search results page displays the same text (namely search-nonefound) on desktop as well. Options:

Thanks! I’ve complained a few times about missing Phabricator→GitHub links, so I’m happy it now happens automatically!

While odd namespace number was a good proxy on Wikitech, Wikipedias use __NEWSECTIONLINK__ a lot, which may lead to inconsistent behavior on them. Maybe it should be reevaluated whether DiscussionTools can be used to determine which parser to use by default.

In T248416#9659645, @stjn wrote:

You get Minerva without MobileFrontend hacks