- Open Source dev since 2001
- Wikipedian since 2005
- Wikipedia admin since 2008
- Commons admin 2010-2015
- MediaWiki dev (+2) since 2009
Uses Safari most of the time (because someone has to)
Uses Safari most of the time (because someone has to)
sigh auto complete ;)
@Jc3s5h thank you for taking the steps, it is very valuable. As you note, adding thumb nailing support is a lot more steps than a simple upload ;)
I've removed site-requests tag until this is completely actionable.
Maybe this one ?
Also, given that these formats all seem to be text based, is there a reason we should be treating them as files, and not as editable wiki pages?
maps-tiles1 now has access to the pgsql server.
@aborrero I can confirm access.
This is due to query to retrieve the categories making the url too long I think
One of the alternatives I have seen suggested that I think might be feasible, is a captcha fallback using verification via phone number.
Now 0 on both. Can be closed as far as I'm concerned
You'd have to purge all the djvu files, because this is cached in the database with img_media_type
There is a local workaround in place, that helps for the float positioning for now, but toclimit is still broken because of this.
i think that's just how it was initially done, and now one ever thought about alignment between the two.
It looks like they're not going to support constants at all, and this configuration should be changed to use string keys like $wgCategoryTreeMaxDepth = [ 'pages' => 2, 'all' => 2, 'categories' => 3 ];
"CSS changes should be easy to test."
You know, this is what I hate about MediaWiki sometimes.. Everything is so convoluted, even the smallest of changes turns into a F'ing nightmare. Moving this platform forward is like dragging a dead cat through mud. ;)
This doesn't really seem too relevant anymore..
I think @cscott worked on some of this stuff not too long ago. Maybe he knows how to fix this. I suspect it has to be switched to wrapWikiTextAsInterface, with 'mw-parser-input' or true, but i'm not entirely sure.
Making the installer support enabling certain bundled extensions by default would be T55983: Select checkboxes for bundled extensions by default I believe.
@Sasheto hi, I haven't forgotten about your request... Please don't take this the wrong way, but lately there has been quite a LOT of malicious activity and your account is brand new.. And I can't find any history of your activity with the projects... At this time that makes me uncomfortable to give you access to this set of servers as one of them is actually rather critical and could allow a person to do a lot of harm to wikimedians. I'm considering how we should approach this.
@Chippyy can you please document the setup somewhere for the future ? That would be super helpful.
If you want full free-flow resizing, you'll need to turn off the display flex rules as soon as you start resizing. Textbox resizing is kind of bonkers really, it doesn't really fit into the standard rules of CSS dimensioning, as soon as you start applying it, all CSS rules regarding automatic sizing are thrown out the window.
P.S. Is this in any way related to T95849: Search for unicode symbols like ★ is inconsistent and unpredictable ?
You could also define synonyms for many of these:
There isn't one I think.
IIUC when the svg rendering was introduced, it was rejected early on (when pure mathml on firefox was considered).
<span> with display:block is always an option of course. ;)
And i've sent out an email on maps-l and wikitech-l
It seems overpass-wiki instance is not in use. Was once made by Jotpe in 2015. I've sent out an email via his wikimedia wiki account. I suggest we delete it if there is no response before the 18th.
I have updated https://wikitech.wikimedia.org/wiki/OSM_Tileserver#Technology_stack with some information about the current tiles servers as far as I could deconstruct from looking at the instances. If anyone has any further information, that would be appreciated.
Yes, this is a known issue for dynamically sized elements that are loaded via mw.hook (which loads fragments before they are added to the page dom). There are similar problems when you put maps or timedmediahandler within collapsed templates.
Just a followup/enhancement idea: since we have precision.. wouldn't this be a good place to draw a precision circle ?
This issue is a known problem with older versions of Google Chrome and Versions of Webkit up to version 12. It is suspected this will be fixed in Safari 12.1 (eta march 2019).
As the upstream browser problem has been fixed, we are closing this ticket, as there is nothing further we can do from our side.
Wow never knew CodeMirror supported this.. impressive. (cmd instead of ctrl on MacOSX btw).
What if we turn wgPopupsOptInStateForNewAccounts into a date value instead ?
Can't we somehow flip that logic around ? Seems more sane to me..
Get everyone currently not set to true, with a maintenance script, write them to false, configure default as true...
@Tgr I think in the past we also said that some UI and interface messaging rework was needed to make the steps more understandable, esp around the topic of scratchcodes.
we could convert every ResourceLoader module into a file that exports modules for testing purposes and have ResourceLoader modules that are trivial to port to npm/and run headless with our node-qunit library
I just noticed there is a bit of precedent for this styling in the StructuredDiscussions UI, in their history, reply and thank links.
@stjn I just tested .autocomment, .autocomment a:not(:hover):not(:focus):not(:active) and I kind of like that..
It's worth to read previous comments (such as T165189#4789628) before pretending that somebody could speak for "the community".
Please take meta-level discussions (such as 'developers and communities') somewhere else. It's off-topic here. Thanks.
I'm sorry, but the community (including myself) has every right to provide their input here or wherever when it is clearly affecting them. Pulling the wool over our eyes or telling us to go elsewhere is inappropriate.
Note to self: This is because the dialogs are shared between editors... If a dialog was already opened before, it is reused the next time, even if it is from a different editor....
@gh87 are you replying to me or to schnark ?
@Nikerabbit maybe those pages should be deleted then ? To avoid people accidentally using them ?
nvmd. i was on the wrong path myself ;)
ping @Umar hi, can you provide your feedback to my change that is linked in the comment above ? I've not removed the russian translations, as that would break any wikitext that would already uses them.
@PFWOz yes. We always advise people to use extensions that are of the same branch version as core. So you shouldn't use a 1.32 version of an extension on an LTS 1.27 release of core. We provide no guarantees that this will work, and only after 1.27 we are keeping a limited set of information per extension that keeps track of compatibility (But because of how new that is and the enormous backlog, I wouldn't rely on this information yet to judge actual compatibility).
While in general this might be common, this is unlikely to be offered by the MediaWiki core team.
ticket was solved by tpt in april. Other issues should be filed separately.
This labs feature of the original WikiEditor was removed from the extension quite some while ago. Ticket no longer valid.