User Details
- User Since
- May 20 2015, 1:21 PM (469 w, 6 d)
- Availability
- Available
- LDAP User
- Pols12
- MediaWiki User
- Pols12 [ Global Accounts ]
Sun, May 19
For reference:
Regression from MW-1.43-notes (1.43.0-wmf.5; 2024-05-14) (see logs).
Due to e5488062 for T362811.
Sat, May 18
Fri, Apr 26
Thu, Apr 25
Wed, Apr 24
Tue, Apr 23
Thank you!
Mon, Apr 22
Indeed, DeleteEventCommand::deleteUnsafe() also performed TrackingToolEventWatcher::onEventDeleted() which triggered:
- wikimedia_event_center_controller::unsync_event() through an HTTP POST request
- TrackingToolUpdater::updateToolSyncStatus()
Apr 15 2024
Thank you for the quick and deep investigation and fix despite the poor reproduction steps.
Apr 12 2024
Apr 11 2024
Apr 9 2024
Apr 8 2024
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';
Apr 4 2024
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! 🙂
Apr 3 2024
This regression has probably the same cause than T327778.
Apr 2 2024
(follow-up of T354473)
Translation unit is imported from Meta-Wiki, however, translation page is recreated by FuzzyBot, making author credits hardly discoverable.
Mar 28 2024
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.
Mar 26 2024
Mar 17 2024
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.
Mar 11 2024
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.
Mar 10 2024
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:
Mar 9 2024
Mar 2 2024
Feb 28 2024
Feb 21 2024
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.
Feb 19 2024
Feb 14 2024
Feb 1 2024
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.
Jan 31 2024
Jan 28 2024
@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.
Jan 27 2024
Jan 26 2024
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.
Jan 24 2024
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=}}.
Jan 18 2024
Jan 8 2024
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?
Jan 7 2024
Jan 3 2024
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)
Jan 2 2024
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?
Thank you for providing the proper link.
Jan 1 2024
Dec 28 2023
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">.
Dec 27 2023
Dec 21 2023
Dec 20 2023
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.
Dec 7 2023
What do you mean with “more sensibly”? I can still reproduce the visual issue described in initial report.
Dec 6 2023
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.
Nov 23 2023
Nov 22 2023
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.
Nov 17 2023
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)
Nov 15 2023
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…
Nov 14 2023
Nov 9 2023
Nov 7 2023
These days, I note a several minutes delay (maybe hours) for a page to be translatable.
Oct 28 2023
Oct 24 2023
Oct 23 2023
Oct 21 2023
Oct 11 2023
The easy workaround is to locally create a {{TRANSLATIONLANGUAGE}} template which returns {{PAGELANGUAGE}}.
Oct 10 2023
Also tagging WMF-Communications for review, since this issue increase confusion with Wikimedia Trademarks.
Oct 4 2023
Sep 28 2023
Maybe, I can’t say.
Sep 27 2023
I confirm Ctrl+Alt+Shift+P does properly work on Debian GNU/Linux.