Don't use conpherence with me, I won't read nor reply. Instead write me by email or my user talk on mediawiki.org.
- User Since
- Oct 10 2014, 2:32 PM (162 w, 4 h)
- LDAP User
- MediaWiki User
- Nemo bis
Wed, Nov 15
Any update on this front considering https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_website/2017_update#Multilingualism ?
Ok, makes sense. Explains why I didn't notice them before checking in the developer console. :-) I don't know whether creating those cookies causes issues (e.g. because other cookies get deleted to "make room" for them), I'll see and maybe file a separate issue. Thanks for creating this one.
Tue, Nov 14
Seems a clear decline, we don't support unfree software.
I assume the same would apply to the "UseDC" cookie?
Mon, Nov 13
I still consider any meaningful interpretation of this task to be blocked on fixing T158507
What does "all" mean?
Selection requires sensible criteria, so I think this is blocked on T158507
Does somebody know why cookies CP, forceHTTPS or even WMF-Last-Access and VEE need to be stored for each subdomain separately? With current cookie limits such a multiplication of redundant cookies make it practically impossible for useful site-specific cookies to survive (for instance session, sitenotice dismissals).
With Chromium 60 I experience a similar problem by the way: according to http://browsercookielimits.squawky.net/ only some 180 cookies in total are allowed, so if you just open a handful tabs and maybe dismiss some sitenotices and centralnotices plus half a dozen VisualEditor splashscreens per wiki then your session is already erased.
The prototype contains a mistake, "from readers like you". There's no reason to assume the donor is (only) a "reader".
Sat, Nov 11
Switching to lowest priority since there was just one wiki asking this and now it's zero wikis. For higher priority requests, see earlier feature requests about making Special:NewFiles a bit smarter, e.g. by separating the patrolling of the *page* (file description) from the patrolling of the *file* (file content, upload action or log thereof).
(Closed per lack of [clear] consensus according to task creator.)
The blocker was correct, but I see a duplicate has been created in the meanwhile.
Thu, Nov 9
Tue, Nov 7
Just noting that there is no way we could afford a usability debacle such as this absurdly complicated interface:
Replacing just the "url" parameter is not free-form but rather structured, so it could be possible, although it would make the interface more cluttered and less user-friendly.
If you use just one metric for "size", I suggest word count, which in WikiStats proved to be the most resilient.
Mon, Nov 6
Sun, Nov 5
This is still happening.
Sat, Nov 4
Offline work would IMHO best served by some kind of import/export API, ideally using a format shared with Translate (XLIFF2? :p), so that people can use existing software for translation. https://www.mediawiki.org/wiki/Help:Extension:Translate/Off-line_translation
Wed, Nov 1
still a little sub-optimal if you're a heavy user and already logged in, no?
c) We could use the API (http://www.sherpa.ac.uk/romeo/apimanual.php?la=en&fIDnum=|&mode=simple) to display the information directly on the page.
As discussed on https://en.wikipedia.org/wiki/Wikipedia_talk:OABOT, we generally link to the records, not to the PDF. The same is done by the citation template for e.g. arxiv, so it would be inconsistent to do otherwise. This can be revised if the norm varies.
What do you mean by "edit links in free form"? There always an edit button on the page. :)
not clear that an edit was made
Tue, Oct 31
Mon, Oct 30
Many wikis use an inputbox or TOC to produce links like https://en.wiktionary.org/wiki/Category:Chinese_reduplications?pagefrom=%E7%87%A6%E7%87%A6 , is this what you mean?
Sat, Oct 28
Fri, Oct 27
Example of what I mean: https://github.com/nemobis/oabot/commit/3ef15e9919e95f1b0a51d48125b47880d1355a73
I've tried the deployed version on Chromium and it seems to work fine.
Most browsers nowadays have a PDF viewer, so an iframe would satisfy 90 % of the needs here.
This was already fixed AFAICT, there is a link to https://meta.wikimedia.org/wiki/The_Wikipedia_Library/OAWiki/Copyright_and_OA (although the page can use some improvement, see talk).
Note that we currently can do this by namespace and language, e.g. "New or modified source messages for Dissemin" is satisfied by https://translatewiki.net/w/api.php?hideminor=1&namespace=1272&urlversion=1&days=30&limit=20&translations=noaction&trailer=%2Fen&action=feedrecentchanges&feedformat=atom (@A3nm asked how to get "new messages to translate", cf. T62904).
Thu, Oct 26
According to MediaWiki principles, it would be ideal if the list of rejected links were hosted on a wiki page, e.g. in the Project namespace of the target wiki or on Meta-Wiki. It can also be in JSON format. This assuming that it's not easier for you to handle a database with any manual updates or change tracking, of course.
Tue, Oct 24
Hmm, the existing French translations have not been imported, as far as I can tell from the statistics. Are the paths wrong in the configuration or is some other step necessary?
Sun, Oct 22
Fri, Oct 20
Oct 16 2017
Oct 15 2017
I suppose this has been fixed in the meanwhile, because I don't see the error any more [I wrote this comment some months ago but failed to save].
This report combines several perceived issues and doesn't describe how the process could be better. We already have a report on granularity, as noted, and of course it's possible to consider alternative target tags if a proposal arises (of course they'll need to be discussed with the people who actually want to follow and act on those reports).
Maybe the extension could already be removed from some sites? How to find out?
Gotta remind myself not to use Translatewiki.net’s “Request info” link ever again…
Oct 13 2017
I cannot reproduce this anymore: searching for filipino returns no results.