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 (171 w, 3 d)
- LDAP User
- MediaWiki User
- Nemo bis
Wed, Jan 17
Tue, Jan 16
I was hoping to restore this but I can't give a timeline. Probably in May.
Sun, Jan 14
Thu, Jan 11
What is meant here by "long term"? Feedback must not be collected unless it's acted upon. Either it goes to a public place where people can make use of it, or an end should be configured for the collection (say 1 year) and then whoever is left using it can ask the term to be prolonged.
Fri, Jan 5
Thu, Jan 4
Wed, Jan 3
Tue, Jan 2
The conversation has been pretty much inactive since the beginning of December.
Sun, Dec 31
Fri, Dec 29
Dec 19 2017
the underlying problem is lack of transparency
Dec 16 2017
Dec 15 2017
Dec 13 2017
Dec 9 2017
I'm not sure what this task is about, but it seems that the underlying desire for the proposer is to have a familiar interface for the API. This seems typical territory for a client library: many like to access MediaWiki data in a pythonic way, so they choose a library and access a subset of the MediaWiki API by that method.
I'm not sure what "freeform external access" even means. If I understood correctly, the proposer would like an API module with a "Google-like" search, where you input an arbitrary set of keywords in a black box and you get some unpredictable output which you're hopefully going to like or do something with.
Dec 3 2017
The description doesn't explain how this goes towards T158181: Aim for 1:1 feature equivalence for MediaWiki on desktop and mobile web. Besides, nearly all the "prominent special pages" listed are not even special pages in MediaWiki proper.
The mock description doesn't state what the pink is for.
What's a "Form"? The first thing I think of is SemanticForms (now PageForms), while if I don't know anything about it I end up on https://www.mediawiki.org/wiki/Extension:Form and if I already know that it's about Wikidata and Wiktionary I find one line «Create new entity types (for Lexeme, Form, Sense and Embedded)» https://www.wikidata.org/wiki/Wikidata:Wiktionary#Our_plan .
@Anomie do you think this preference should be removed from the userinfo API, or made "prettier"?
Current status for future comparison: 7 matches for AboutTopic, 0 of which are Special:AboutTopic https://archive.fo/fcX97
Dec 2 2017
The horse is very much alive: for instance I still find myself fixing corrupt preferences for my account pretty much every week. It's also a bit hard to claim that the reliability of the underlying data doesn't matter to your analysis, or that the analysis cannot be fixed to keep into account the data corruption.
Dec 1 2017
First you'd need to restore the actual user preferences after they were polluted/corrupted by T114208.
Nov 29 2017
Nov 26 2017
Links are actually more of an issue in enotif, because they usually get linkified by email clients for plain text emails.
Nov 25 2017
Nov 23 2017
Nov 22 2017
Misleading messages should be removed but they're not a coding matter.
Nov 21 2017
Indeed I don't see how disabling the feature would help the goal, i.e. have the translators receive the information they need asked for with minimum collateral damage.
How so? The translation has been proposed by local users.
Nov 20 2017
Nov 19 2017
Customary note that "functionary" is not a defined term on 99 % of the wikis.
And how do you propose to gauge whether the functionality is missed? It's not about feelings, it's about choosing solutions which fit the stated purpose. Again, it's fine to just state you want one more chat/discussion system: people keep creating new ones all the time, it's not like it will be the end of the world.
That's what people used to do before Internet Archive became widely used (and now again I guess), see http://en.wikisource.org/wiki/Help:DjVu_files
Yeah but that's just one example, what about the 70 other languages? :) It would be nice to have a systematic solution, e.g. fall back to the normal enotif if the new one is untranslated.
No, this is resolved: since a long time you can/must dismiss each banner/campaign separately. The other part was switched to T108849 I guess.
Nov 18 2017
I don't understand how the current proposal at https://www.mediawiki.org/wiki/Discourse fits with the stated purpose. Discourse is a forum system, not a Q&A system. It may compete with existing discussion venues such as mailing lists, IRC and Phabricator, but it's not a support system. I don't see any benefit in adding yet another forum.
The WMF doesn't really dedicate any resources to keeping it running.
Where is the file?
Hopefully the task summary is clearer now.
Now that I think of it, why is a cookie used in the first place for this preference? Can't it rely on a hidden preference like ULS does?
Nov 16 2017
Nov 15 2017
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.
Nov 14 2017
Seems a clear decline, we don't support unfree software.
I assume the same would apply to the "UseDC" and "UseCDNCache" cookies? And maybe also the "cpPosTime"?
Nov 13 2017
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".
Nov 11 2017
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).