In T363187#9741040, @Geertivp wrote:

Now there is something else: to my opinion it should always be possible to add the event banner again, the same way as when the event page was initially created. I can see no reason why this would not be allowed.

Thank you!

In T362365#9736407, @Daimona wrote:

Once the fix is merged, you should be able to remove the tool, and add it again if you wish.

Indeed, DeleteEventCommand::deleteUnsafe() also performed TrackingToolEventWatcher::onEventDeleted() which triggered:

• wikimedia_event_center_controller::unsync_event() through an HTTP POST request
• TrackingToolUpdater::updateToolSyncStatus()

In T90511#7730629, @Tacsipacsi wrote:

Unfortunately this change broke anchor links to default-collapsed aggregate groups (see this edit by @Quiddity removing a now-broken anchor), as the div#tp-subgroup-XXX gets display:hidden. Anchor links would especially help exactly because of how long this page is. I think either the id should be moved up one level in the DOM tree (from div.tp-sub-groups to div.mw-tpa-group), or a new ID should be added to div.mw-tpa-group.

Thank you for the quick and deep investigation and fix despite the poor reproduction steps.

In T347156#9701997, @abi_ wrote:

In T347156#9687747, @Nikerabbit wrote:

I see translationPages being exported by the script, so I am confused why they aren't imported. Is that a bug, @abi_?

My guess is that permission restrictions that we have in place to not allow translation pages to be created by users is blocking the creation of the translation page during import.

Page number is the only index for pages in books; whereas in the file list, each file is indexed per its file name. You may also refer to a given file thanks to its date.
To describe a use case, a story is often better; e.g. “While reviewing all files from a specific user opening them in new browser tabs, I would like them to be numbered, so I can easier remember the last file I have open.”
You can’t say “sometimes it is useful to have numbers”, we need to explicit “sometimes” with a precise story.

The reproduction also needs Vector-2022 skin enabled with sticky header, along with “Place categories above all other content.” gadget enabled too.
Firefox well opens the select downward: no issue. I don’t see interest to opening the select upward, so I would turn

if ( textPos.y < maxListHeight + offset + 1 ) {
	// The list might extend beyond the upper border of the page. Let's avoid that by placing it
	// below the input text field.
	nt = this.text.offsetHeight + offset + 1;
	if ( this.engineName ) this.engineSelector.style.top = this.text.offsetHeight + 'px';
} else {
	nt = -listh - offset - 1;
	if ( this.engineName ) this.engineSelector.style.top = -( offset + 1 ) + 'px';
}

into

// The list might extend beyond the upper border of the page. Let's avoid that by placing it below the input text field.
nt = this.text.offsetHeight + offset + 1;
if ( this.engineName ) this.engineSelector.style.top = this.text.offsetHeight + 'px';

I haven’t meet this issue for several weeks (probably MW 1.42.0-wmf.21), whereas it consistently failed from November. Thank you for the work! 🙂

This regression has probably the same cause than T327778.

(follow-up of T354473)
Translation unit is imported from Meta-Wiki, however, translation page is recreated by FuzzyBot, making author credits hardly discoverable.

Thank you for the patch @MusikAnimal.

That seems to be fixed with MW 1.42-wmf.24 (7e9d90bb5256 I guess), but I’m not sure that was expected.

In T359751#9659830, @matmarex wrote:

I tested this locally just now and I can't reproduce the problem. If you still see it, it would be helpful if you could link to the specific pages and topics where it didn't work as expected.

Also, please check whether the automatic subscription status appears after you refresh the page – Ed and I were wondering in T360942/T360863 whether the problem is that the subscription is added, but the page is not updated to show it.

Note: if you mark a page for translation with 0 unit (empty translate tag pair, and disabled Page display title translation), this will remove translation pages with the reason Part of translation page "<source_page>": Page no longer has any translations (example). That breaks transclusion of the page, since that removes subpage in source language.

The same? You’ll find a starting guide and DiscussionTools repository (Phabricator mirror). Reviewing sister tasks (e.g. T284836) may also help you to locate the related code.

A simple fix is needed, not an Epic task.

An heuristics can add a proper markup in most cases (lists, headings…). I see two exceptions:

• Images: some textual image may want to be fully replaced, whereas we only want to translate the captions for pictures.
• Some Template parameters are string constants (no localization expected), whereas other one are literal content which should be translated. We could use templateData (string vs content parameter types), but those are rarely well provided.

Unlike legacy parser which breaks the list (T11996), Parsoid well supports <gallery> inside list item: wikitext-to-html seems to work correctly.
However, this bug seems to indicate there is an issue with html-to-wiktext, since VisualEditor rendering is correct:

In T13555#9592779, @Jack_who_built_the_house wrote:

DT's subscribe button is now inside span.mw-headline which is inside h2. Doesn't seem right and in line with this task.

In T299202#7625676, @jhsoby wrote:

Where I'm having trouble though, is the language selector on Translatewiki's [[ translatewiki.net/wiki/Special:Translate | Special:Language ]], as well as the "general" language selector on multilingual wikis like Commons and Wikidata (the one that appears next to your username).

This could be done for both live and non-live preview, and although it means a sort-of unnecessary page load in the case of live preview I think it might still actually be better because it'd return the form to the initial state.

If we can’t force Live preview, I think we should try to keep such “live discarding” when Live preview is enabled: the UI is much more user-friendly than a page reload. I don’t know how complex it is to guess whether Live preview is enabled, though.

In T354494#9552224, @HMonroy wrote:

Is this issue still around? I'm not able to replicate it :)

In T283210#9504791, @Tgr wrote:

Flipping applies to the icon name so I don't think you need :dir() for that. css-sanitizer should generally support standard, widely accepted CSS selectors though, regardless of whether we have a specific use case for them, so the task is fine.

I completed the review and fix for the 135 templateStyles sheet on Meta-Wiki which contain a h# selector.
In most cases, I could simply replace h2 with .mw-heading2, however there are two main issues:

• color property is not inherited by h2.
• If the style sheet is used both on Main namespace and on specific namespaces (e.g. Grant: or Research:), the inconsistency (wrapper or not) makes maintenance really painful.

In T283210#7109876, @Pols12 wrote:

I don’t see any case where we would want to target a specific direction for content

@Od1n it is because this task has not been completed. Only T314714 has been done, for DiscussionTools.
“mw:Heading HTML changes” show expected changes in the future.

In T13555#9492386, @Od1n wrote:

Hi, on frwiki homepage (permalink), I noticed there is an element in the wikicode that doesn't get converted to the new markup: <h2 style="margin-top:1.5rem">. When removing the style="margin-top:1.5rem", the element gets converted, as the other <h2>'s of the page.

Is it intentional that the markup change is avoided in this case? (I don't think so, as ultimately the old markup is expected to be found nowhere)

And how should MediaWiki handle such case (i.e. what to do with the style attribute)?

In T13555#9407996, @matmarex wrote:

wmf.9 contains some styling changes (core / skin / DiscussionTools), which, in hindsight, could have disturbed custom styling.

Another similar report.

Instead of pasting primary selection, you may also drag and drop some text to reproduce this issue.

Actually, I am still able to reproduce the issue. Note you need to ensure you are in Visual mode, this works properly in source mode. I missed to provide this piece of information in reproduction steps.

I can’t reproduce anymore. That was probably an issue in my local environment.

I also thought about a {{#HEADING-ANCHOR|}} parser function for T62544 and followups, but that would require a new core hook to edit the heading.
We may want to mix both parser functions with something like {{#HEADING-EDIT|anchor=|class=}}.

That could be a regression of T351273 again, but looking at recent edits, the bug seems no longer reproduced. Can you confirm it is now fixed @Ameisenigel?

Search-Console-access-request is not the right tag, but maybe the team who grants that access can help us to reach someone who has that precious access. I am unfortunately not enough trusted to request this access myself.

(The missing use case for <base lang> was reported on T309329#8031966)

Thank you for opening this task Reedy. 🙂 But I wonder if this is not a duplicate of T265853, given upstream report linked there.

All links actually do work as of today. Can you confirm this is fixed for you too?

Wikidata does not use uselang hack: this task is specific to Commons. See T58464 for a global task (all wikis, including Wikidata); or T352645 for Wikidata eventual specificities.

Thank you for providing the proper link.

Unfortunately, my patch seem to have not fixed the issue: wiktionnaire Jeux paralympiques still displays “Wikipedia” as site name, whereas source of cached page well contains <meta property="og:site_name" content="Wiktionnaire">.

The recommended fix is providing schema:name at home page.
However, “By home page, we mean the domain or subdomain level root URI.” (GSC)
Since our root URIs return HTTP 301 (moved permanently), I don’t know whether we can use the redirection target to place schema properties.

What do you mean with “more sensibly”? I can still reproduce the visual issue described in initial report.

Job lag similar to T318484: a big job execution time which causes unexpected delay between translation editing and them to be visible:
132 minutes between translation unit update and translation page update.

In T239847#9355422, @MSantos wrote:

In T239847#9342139, @Pols12 wrote:

Parsoid issue, I guess.

Hey @Pols12 can you provide more context about why this is a Parsoid issue?

It is actually <span class="mw-reflink-text">[14]</span> which is display:none in default Cite style sheet.
It is followed by an ::after pseudoelement.

Parsoid issue, I guess.

Really nice UX! 🙂
Some minor limitations I noted:

• Added/edited headings in the current editing session are not reachable.
• Since selecting the target page with directional keys does not fill the text input (what a browser URL bar usually does), in order to link an external section without fully typing the target page name, you have to first add a link to the page name, then edit it to add the fragment.
• For local page section suggestions, a middle click opens the page in visual editing mode rather than reading mode like for external sections.
• It does not recognize underscore as space equivalent; so copying the fragment from a URL looks like it is not an existing section.
• For local sections, the resulting wikitext uselessly adds page name before fragment. (T239847)

In provided patchDemo, in visual mode, “Show preview” button is visible but disabled. That seems me counterproductive.
In my opinion, we should:

• remove it to make the interface lighter;
• or keeping it enabled, to let users display a real preview which is actually (but unfortunately) different from visual editor rendering because of legacy parser, slugs, new French armories…

These days, I note a several minutes delay (maybe hours) for a page to be translatable.

This is a regression introduced by 4d4e86e for T348275.

The easy workaround is to locally create a {{TRANSLATIONLANGUAGE}} template which returns {{PAGELANGUAGE}}.

Also tagging WMF-Communications for review, since this issue increase confusion with Wikimedia Trademarks.

Maybe, I can’t say.

I confirm Ctrl+Alt+Shift+P does properly work on Debian GNU/Linux.

No other report. Please reopen if you still cannot use that shortcut.

Given VisualEditor is able to properly get a template preview while typing subst:Name as template name, I think this is more a bug than a feature request.