User Details
- User Since
- May 20 2015, 1:21 PM (492 w, 1 d)
- Availability
- Available
- LDAP User
- Pols12
- MediaWiki User
- Pols12 [ Global Accounts ]
Sat, Oct 19
Aug 11 2024
@Od1n this task is closed, and that’s not clear what you expect from your several messages. I think you should write a clear minimal wiki page as a test case to demonstrate the problematic differences between Vector-2022 and legacy Vector, then open a new task linking that test case.
I can reproduce at home with any skin, including legacy Vector. (Firefox 115 esr, LXQt, Debian)
Aug 9 2024
Aug 7 2024
Aug 6 2024
Same issue with:
- behavior switching magic word (T130479),
- {{DISPLAYTITLE:}} (T36957),
- comments at page top (T25698),
- <templateStyles> tag
- …
In the opposite, <translate> tag and translate markers (<!--T:1-->) are pre-parsed by MediaWiki-extensions-Translate removing the following newline.
Aug 2 2024
So, I would revert the last patch, because it will introduce wrong fails in log.
EDIT: I did not see hueitan’s WIP patch attempts to fix this issue removing non-movable subpages from list. That’s fine.
Aug 1 2024
My patch saves pageCollection data in Session to solve the aforementioned log issue. I don’t know whether it is a good way to stash such data.
Jul 30 2024
Allowing sub-pages to be moved make the script trying to move immovable sub-pages, so the log is populated with entries like this:
[USER] encountered a problem while moving page Foo/sub to Bar/sub
I wonder if it is acceptable.
Many thanks @hueitan for fixing all the remaining issues of my patch, because I had no time in last weeks to work on this task, and I know it may be annoying to work on someone else’s patch.
Jun 20 2024
Finally, I reopen it since I think I’m able to provide a patch which will allow to move the page without any subpages instead of fully failing.
Being able to move only subpages without issues along with main page is a bit more complex, or costly.
Jun 19 2024
Note it is a bug, not a feature request, since you can’t move the page even if “Move all subpages” could be unchecked (actually, you can’t reach the step where you would uncheck this option).
Jun 18 2024
Jun 12 2024
Tested on 3 pages at Beta-Wikipedia, and I did not meet this issue anymore. Thank you!
Jun 9 2024
Another problematic usecase we have on frwiki:
.col { margin-top: 0.3em; column-width: 30ex; } .col ul { margin-top: 0; }
<div class="col"> * list * with * several * elements * displayed * in * several * columns </div>
As I wrote, the webcache of Google does contain the og:site_name meta tag, so we can be sure the page has been crawled and indexed. Unless the crawler which store webcache is not the same one which index content, but that would surprise me.
Jun 7 2024
Given many wikis and users have this gadget as a workaround, that may worth to consider this task in DiscussionTools / Desktop Improvements (Vector 2022) , eventually declining it since other ways to make creating discussion easier have been thought.
I surely appreciate your answer, thank you, even if it is late and opposed to my opinion. 🙂
(Just for reference: ⚫ is in code because of T176485.
Per Jdlrobson’s investigations, this issue is a regression from MW-1.43-notes (1.43.0-wmf.8; 2024-06-04).)
Jun 3 2024
May 29 2024
Note I achieved to reproduce on several pages, but I can’t reproduce at fr:Koenigsegg_CC8S.
May 19 2024
For reference:
Regression from MW-1.43-notes (1.43.0-wmf.5; 2024-05-14) (see logs).
Due to e5488062 for T362811.
May 18 2024
Apr 26 2024
Apr 25 2024
Apr 24 2024
Apr 23 2024
Thank you!
Apr 22 2024
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=}}.