Just checking if anybody has strong feels on
This is a patch from Isarra adding a $wgLogoHD config setting which can
list URLs for 1.5x and 2x-density images to supplement $wgLogo. They get
loaded in MonoBook/Vector-like skins using CSS and media queries if used,
and have no effect otherwise.
This is roughly equivalent to how a hi-DPI logo is provided on English
Wikipedia and a few other special-cases via custom CSS, but without the
need to fudge around with custom site CSS. :)
Downside: size-derivatives URLs must be specified manually in site config.
Upside: when using SVGs rendered on-wiki, that's *real* easy to automate
and create a suitable config to cut-n-paste.
An alternative might be to fancy things up with a $wgLogo supplement that
accepts an on-wiki file name, with the scaling managed internally by the
wiki. But that might be a bit trickier.
Any thoughts? This is an old "paper cut" issue that drives our designers
nuts and I'd love to get it working one way or another. :)
I've been having this problem with my production setup, and we are
currently down because I can't seem to rectify it. Everything points to a
cache issue, for which we use redis. I've tried restarting our redis
server, as well as our MariaDB install and even nginx on both web servers.
So far, I have yet to make the site usable. Can anyone at least point me in
the right direction of how to start debugging? The site was working just
fine and was actually running pretty quickly up until a few hours ago, when
this error suddenly appeared and took down the site.
This is with a load-balanced server setup including two web servers with
nginx, a PHP-FPM server, a MariaDB server, a redis server, and an NFS file
server which contains the codebase. All of them run on Ubuntu 14.04.
Any help is greatly appreciated.
OOjs UI 0.9.0 was released on Wednesday. It will be in MW from 1.25wmf21+.
As there are several breaking changes, please look carefully over them to
determine if they affect your code.
*Breaking changes since last release:*
- [BREAKING CHANGE] Remove innerOverlay (Ed Sanders)
We've tagged this as a breaking change, but this was an internal-only
feature that we never made part of the public API. We no longer use it
since the removal of iframe support in v0.7.0.
- [BREAKING CHANGE] TextInputWidget: Remove 'icon' and 'indicator'
events (Bartosz Dziewoński)
Deprecated in v0.8.0, at which point they were already unused as far as we
- [BREAKING CHANGE] Remove deprecated LookupInputWidget (Bartosz
Deprecated in v0.6.3, at which point they were already unused as far as we
- [BREAKING CHANGE] Remove deprecated GridLayout (Bartosz Dziewoński)
Deprecated in v0.7.0, at which point they were already unused as far as we
*Deprecation changes since last major release:*
- [DEPRECATING CHANGE] Rename setPosition to setLabelPosition (Ed
This function in TextInputWidget is probably only used privately on
intialise, so it's unlikely to be a breaking change in the real world, but
Additional details are in the full change log
<https://git.wikimedia.org/blob/oojs%2Fui.git/v0.9.0/History.md>. If you
have any further questions or need help dealing with deprecations, please
let me know. As always, general library documentation is available at
mediawiki.org <https://www.mediawiki.org/wiki/OOjs_UI> and generated code-level
documentation at doc.mediawiki.org
I think I proposed this once but I forgot the outcome.
I would like to implement a new feature called "tool edit" it would be
pretty much the same as "bot edit" but with following differences:
-- Every registered user would be able to flag edit as tool edit (bot
needs special user group)
-- The flag wouldn't be intended for use by robots, but regular users
who used some automated tool in order to make the edit
-- Users could optionally mark any edit as tool edit through API only
The rationale is pretty clear: there is a number of tools, like AWB
and many others that produce incredible amounts of edits every day.
They are spamming recent changes page -
https://en.wikipedia.org/wiki/Special:RecentChanges can't be filtered
out and most of regular users are not interested in them. This would
make it possible to filter them out and it would also make it easier
to figure out how many "real edits" some user has made, compared to
automated edits made by tools.
Is it worth implementing? I think yes, but not so sure.
I’ve been learning how to use Moses decoder  for creating machine translation models for the Uzbek language and was wondering if anyone else has any experience with. After talking to Amir, we decided to set Moses up in a Labs instance. Is anyone else interested in this? How was your experience with the decoder?