:(
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sat, Mar 23
Thu, Mar 21
Maybe consider https://www.dragonflydb.io/replace-redis or https://docs.keydb.dev/
Wed, Mar 20
Tue, Mar 19
Tigraan has stepped back in and provided access :)
Sun, Mar 17
Sat, Mar 16
Sat, Mar 9
I think that potential privacy concerns would need to be sorted out before something like this is implemented.
Mon, Mar 4
Now for Codex, too
Sun, Mar 3
Sat, Mar 2
Fri, Mar 1
(it looks like indeed that emails from all projects are sent from @wikimedia.org, so a restrictive policy for the other domains is a good idea).
will be unstalled on March 15
Feb 16 2024
Hmm, can't reproduce personally on Chrome or Firefox, Windows 11
Feb 11 2024
Jan 15 2024
As well, I don’t see this change causing significantly more logs in the database :)
@Reedy if this task is uncontroversial and does not require the TDF, happy to re-submit the change!
Jan 14 2024
Yes, thank you!
Jan 13 2024
Jan 12 2024
Created T354972 !
It may be helpful to revisit that! The next step would likely be to seek approval for this change in the Technical Decision Forum.
Thank you @HouseBlaster , this flew off my radar! Appreciate it :)
Jan 7 2024
Some cookies are misusing the recommended “SameSite“ attribute 6 Cookie “NetworkProbeLimit” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite Wikipedia:Recent_additions Cookie “NetworkProbeLimit” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite load.php Cookie “NetworkProbeLimit” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite load.php Cookie “NetworkProbeLimit” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite 2 load.php Cookie “NetworkProbeLimit” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite 2 load.php Cookie “enwikimwclientprefs” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite load.php:4:36
Then it is bypassable by abusers. An alternative solution is make loginwiki checkuser data available to all checkusers in all wikis.
I also see how some wikis might want to restrict this to extended-confirmed. It is conceivable that mainspace pages might need to be moved, but as Ammarpad notes, the same might not be true for changing content model.
On Wikimedia wikis the right should be limited to autoconfirmed users, akin to move.
Thanks!
See also T343768
I suggest using the current Wikimedia community logo: https://en.wikipedia.org/wiki/File:Wikimedia_Community_Logo_optimized.svg
Jan 6 2024
Jan 4 2024
Jan 3 2024
Dec 31 2023
The number. Some countries like Thailand use different year formats than Gregorian. Although it might be acceptable to just use Gregorian as most regions abide by the system?
I think including the year would be still beneficial for clarity. See T271968 above for the task to auto update the year.
Translations probably would be difficult to tackle as there are different date formats for different languages
Dec 28 2023
Dec 27 2023
Dec 21 2023
Dec 19 2023
Dec 18 2023
See also https://linkcount.toolforge.org/, which has this functionality.
I've removed the tags from zhwikivoyage :)
Dec 17 2023
I believe that audio files can already have structured data? Example: https://commons.wikimedia.org/wiki/File:OGG_file_Paul_Marshall_Interview_-_March_30_2003.ogg . Perhaps it's an issue of adoption?
Dec 15 2023
Dec 12 2023
It's visible for me in safemode; I'm using Vector 2022.
Dec 11 2023
And now that I think about it, I think that auto redirecting talk pages probably isn’t a worthwhile endeavour. Even if users have no edits on a wiki, they might ask questions off-wiki and others might be, for example, demonstrating talk pages by posting on theirs.
Your talk page was created by a user who sent a welcome message. Best practices for welcome messages differ from wiki to wiki; on the English Wikipedia, messages are usually not sent for accounts without edits, but I’m not sure of the policy that arzwiki has. In general, though, I think that blocking creation of talk pages is not worthwhile; communication is often necessary. In terms of redirecting talk pages, this can be partially achieved through creating a global user page https://meta.m.wikimedia.org/wiki/Global_user_pages and indicating your home wiki.
It’d be optimal to also have another parameter for indicating email access, as the two abilities (talk and email) are separate :)
Dec 10 2023
That's a good point.