User Details
- User Since
- Jun 5 2015, 5:03 AM (458 w, 3 d)
- Availability
- Available
- IRC Nick
- samwilson
- LDAP User
- Samwilson
- MediaWiki User
- Samwilson [ Global Accounts ]
Today
It seems to be due to the <ref> being transcluded. I've got a patch.
Yesterday
Thanks! And yep, no worries about the actual PDF, we can get it from that link.
Yes a link to the page in question would be great, thanks.
The gadget isn't quite complete yet, there's a bit more to be done (see the AutosuggestSitelink board). There's already a documentation page at https://meta.wikimedia.org/wiki/AutosuggestSitelink, but perhaps that's slightly different from a project (i.e. time-bound specific work)?
The link is now appearing above the 'What links here' item. @JSengupta-WMF is this okay?
We can also include a setting on the same pop up saying "Do not ask me for confirmation in the future".
Fri, Mar 15
I think the default filename should be {{PAGENAMEE}}.svg
One way I was thinking about this would require the page to be in at least one category, but then would suggest other categories based on the category membership of other pages in that category. They could be listed in order of page count, perhaps. For example: File:Unknown_artist_-_Fish_Bowl_-_1917.54_-_Cleveland_Museum_of_Art.jpg is in Category:Jade_bowls, as is File:Jade_bowl_national_museum_india.JPG. The latter is also in Category:Mughal_jade and so that could be suggested for the first file. (I'm not saying that'd be a good suggestion, just trying to explain the mechanism!)
@ThierryW23 As mentioned on Telegram, the setup instructions are in the readme. For the actual task, you probably want to look at adding the nextnode parameter to mw.util.addPortletLink(), in this code.
All sorted I think. Thanks!
❓Potential Issue- When switching to English, Serbian language pops up as seen in the video
Thu, Mar 14
The PHP upgrade is done now, and the preview issue should be fixed now.
Yes I think we can just store the first preloaded text. There could be some issues with, e.g. workflows that involve preloading sections (including their titles) with parameters that change, but I think we can revisit it if people report problems.
Wed, Mar 13
Tue, Mar 12
Mon, Mar 11
Yes, thanks!
The same issue was with https://ws-export.wmcloud.org/statistics
For my understanding, why can't preloaded text and edit recovery text be preserved?
What I mean: If we set $wgEditRecoveryExpiry to 0, we effectively disabled edit recovery. So there is a way to disable without introducing another setting.
It sounds like we'll probably remove the feature flag, once it's enabled on all Wikimedia wikis.
If it remains, should the default value be true or false?
I've added both legacy URLs to the Apache config (change), and made a PR for removing them from the app routes: https://github.com/wikimedia/ws-export/pull/509
I was talking about the notification that appears on the diff or preview page when there is an intervening edit.
Is this a discoverable API? Is it faster and/or more cacheable for end-users? Is it easier to maintain?
I think all the important parts of this are solved now, and the other bits are from too long ago to still be relevant (or if they are, will hopefully be raised in separate tasks).
Sat, Mar 9
Actually, scratch that: I've added a redirect for that URL, and all should now be working correctly again. Still not sure what happened to the rewrite rules!
This appears to be a fault in the URL rewriting. We're supposedly handling /tool/book.php in the app:
Fri, Mar 8
Thu, Mar 7
PR to fix some deprecations: https://github.com/wikimedia/svgtranslate/pull/753
It appears that we can get around this by not using Webpack's autoProvideVariables() and instead load jQuery into the global window scope (as described here). This works in my tests, and I've made a PR: https://github.com/wikimedia/svgtranslate/pull/752
I got this error on my local dev environment when I had a file ownership problem in $wgCacheDirectory. Rebuilding the localisation cache didn't help, because I was doing that as the CLI user. I saw someone recommend separate cache directories, e.g.
Wed, Mar 6
Ready for QA again. With follow-ups to be created as separate tasks so we can close this one.
Version 2.0.0 has been tagged and released, and everything seems to be working fine. I've got a small follow-up patch here: https://github.com/wikimedia/svgtranslate/pull/751
Tue, Mar 5
Mon, Mar 4
Fri, Mar 1
Is there a lag between when messages are edited on the wiki and when they're available for export? Because it looks like at least some where already done, e.g. https://translatewiki.net/wiki/Wikimedia:Wdlocator-close-panel/it was edited on 2024-02-28.
Thu, Feb 29
First PR for this: https://github.com/wikimedia/svgtranslate/pull/741
I've deployed the above change in 1.2.5, and it's throwing the following error:
Wed, Feb 28
You might be looking to report against the wiwosm tool; it looks like their bug tracker is at https://github.com/wikiosm/osm-on-ol/issues
@Berete5212 I'm not sure what issue you're trying to report here, sorry. Could you elaborate?
Yes, 'Developers + Maintainers' groups are 'Allowed to merge' and 'Allowed to push and merge' to main. I think that means it's all good.
@Wangombe not yet, but I've invited that user to be a developer; can you accept that invitation? Or is there another way to grant the access? Thanks for helping with this!
Tue, Feb 27
Do you get a notification when re-opening it though, at step 3? The new warning is within the same notification toast. If you click one of the buttons at that point, it'll disappear.
Mon, Feb 26
This is done, and available at https://ocr.wmcloud.org/transkribus
You have to have saved a new revision of the page after you opened it for editing, something like:
Is this the same as T358414?
That's true, I was glossing over that because the main thing I think is that we don't want to force a live diff on people unless they've opted in to doing so. Live diff people will get it already, and non-live people should get a page reload (back to action=edit).
I think it should be possible to determine when Live Preview is in use or not, and act accordingly. It would be pretty annoying to get a page reload every time you want to discard (although maybe it would encourage people to switch to live preview!).
How is multiple selection meant to work in the case of the link inserter? i.e. follow the above steps but instead of hitting do . With the above patch it's slightly strange, but then it's probably a slightly strange thing to do anyway.
Is this check intended to apply to non-Wikimedia extensions? e.g. T358432: TalkBelow module is failing on Vector's PerformanceBudgetTest