Wed, Jul 19
So... are they effectively under MIT license?
Mon, Jul 17
Wed, Jul 12
Tue, Jul 11
Mon, Jul 10
How well would this actually work? Would it catch our common issues? Would it react badly to all the bad stuff already present? What about false positives where things are very much intentional/needed that it may not actually like?
Jun 10 2017
If you really want a technical solution to possible copyright misuse, allowing files from commons is probably exactly what you should do. Unlike local projects, they don't have fair use images at all, and you can further narrow down options by only showing in search results files belonging to categories of licenses that are viable.
I disagree with this task as well. Even if you support the CoC in general, it really doesn't make sense to put it in every single repository when the CoC is for the people and the interactive spaces in which they work, not the technical output thereof. We don't even have separate files for the license in every single repository, and that actually is for the code itself.
Jun 9 2017
My point was that images are already used in this way on WMF projects. The issue with avatars is that they generally do not link to the actual file page, and thus attribution-requiring images cannot be used. But this also applies to any uploaded images used as links or buttons or background art for pages or whatever - they just need to be pd or the like, own work, or specifically allowed for this purpose, too. The communities tend to be pretty good about policing this.
Jun 8 2017
May 26 2017
May 25 2017
Bear in mind that both screenshots are the status quo on different platforms, each demonstrating the currently possible extremes, at least with the latin fonts.
I've clarified the description to explain what the actual problem is. Please tell me if anything about that isn't clear.
May 23 2017
@santhosh Please take a look at 354739 when you can. This is basically all we're waiting on now for deploying Timeless to production (well, testwiki, but still), so if the change is good, let's get it in! And if it isn't, let's fix it..
May 21 2017
@Nirzar I've gone through and filed some more tasks. Some thoughts/questions:
I could have sworn this was already filed somewhere, but now I can't find it.
Also concerns about link (blue/red) colours being too light in T158012
May 20 2017
@Nirzar Will you be around tomorrow?
Okay, this last one should actually fix everything. >.>
Also there's apparently a problem with the logic above with the caret one (settings) anyway, according to matma rex. So it's possible it's related to why the triangle one (compact selector) wouldn't work anyway?
May 19 2017
Okay, chrome's fine, that had nothing to do with this.
Which is to say chrome seems to be broken.
Possibly relatedly, I can't get this stuff to show up at all in chrome now. >.>
There is also a problem of "caret" appearing at the side of scrollbar, which cannot blend into the popout background. Screenshot showing the issue
...what. Er. Okay.
May 18 2017
So, er, I got it to appear, but I can't get the suggested change to actually work. This may not mean much.
I'm an idiot. My copy of bluesky wasn't up to date. >.>
So what's wrong with them, what should they be doing? What does this mean?
So, er, how do I get this callout to appear in the first place? I've installed ULS, but it only added the one in p-personal, not the one in the languages.
May 16 2017
May 15 2017
Okay. I'll test the ULS thing as soon as I can and see where we wind up with that.
@Nirzar Thanks! It's very helpful to get a separate opinion on these things. I've got a few questions about some things, which I'll try to actually follow up with in the next few days.
May 2 2017
Per T158012#3037196, I don't think the design review is really a blocker, just related/helpful.
Apr 27 2017
So what all is blocking Timeless from deployment to the above wikis? Is it mostly just the ULS thing at this point?
Apr 24 2017
Store snapshots of the status daily/weekly/whatever? Do we need to add a database table or something?
Apr 20 2017
Another would be to have all headers use the same font family (e.g. by specifying just "sans-serif" or "serif" for everything).
Apr 18 2017
I'ma go ahead and change this to a general interface task, but I would like to note:
This is an interesting problem. Generally skins don't touch this stuff - the content itself (everything under the firstHeading) is rendered and styled by MediaWiki core - but special pages are predictable, unlike user-created content, and there is some precedent for this already: Special:Preferences is styled only by the skins, and to my knowledge doesn't even have any default core styles (unless this has since been fixed). It could well be worth implementing different handling in different skins for others, too, given reason.
Correction: it's actually 'times' instead of 'times new roman', which also results in some variation as not all fonts matching 'times' are consistent either. Times new roman specifically is, but is not what's specified.
Rammanojpotla: The issue is caused by the font stack for the h2s having inconsistent metrics with each other (linux libertine and times new roman are similar, but Georgia is much larger), and the 'sans serif' the rest use also resulting in inconsistent metrics depending on the system in question (for english, windows generally winds up with arial and macs with helvetica, which are comparable, but various linux distributions wind up with everything from nimbus sans (also comparable) to dejavu sans (larger)). Across these, linux libertine, times new roman, arial, helvetica, and nimbus sans all work reasonably well together. The issue primarily shows up on linux due to the combination of linux libertine (or times new roman as a fallback), which are small, and dejavu sans, which is much larger, but can also potentially show up on any platform depending on user settings (such as use of dyslexia-friendly fonts).
Does not render correctly on 1.5ppp firefox. Results in a blurry image.
Interestingly, there's a flash where the image initially does appear
sharp, before being replaced with the blurry version.
Apr 14 2017
@Nirzar Unfortunately Timeless appears to currently be broken on the beta cluster because I screwed up. So if there's a grey bar on top and the edit links are in a weird place, that... would be why. >.>
Apr 11 2017
If it's pointless, it won't be installed. That's not what this is about - this is about the many wikis that do have cite available for use, but do not use citations as a primary editing feature. What I am asking for here is for VE's defaults to be changed to the same defaults of the wikimedia cluster: citation menu in the general insert menu unless told otherwise. $wgCiteVisualEditorOtherGroup = true unless overridden.
A textarea is a visually distinct element, separate from the rest of the content. Isn't the whole point of VE that it just IS the content, edited directly in place?
Sorry about that.
You know what, this appears to be a browser-specific problem (oldopera), so nevermind. In firefox VE does just treat it as a weird template and ignore the content. Which is... fine.
Is CSS doing something weird to cause this?
Honestly we generally don't actually need the special CSS for general editing (it's usually random crap like restyling the TOC or changing the monobook theme or mimicking enwp's crazy templates or something dumb like that, rarely anything that does much to the content itself), so VE might as well just skip over it and edit the page as if it weren't there?
Apr 10 2017
Heads up, I wrote a very hasty wikimania submission about this, so if anyone is going to be at wikimania and wants to take part (we can sort out the details later), please feel free to add yourself to it: https://wikimania2017.wikimedia.org/wiki/Submissions/Timeless:_building_a_new_interface_for_Wikimedia
It's very difficult to keep styles consistent across several files. We need better variables and mixins in each skin to define what the styles should actually be, generally, before splitting the files up becomes really tenable.