Just checking if anybody has strong feels on
https://gerrit.wikimedia.org/r/#/c/195195/
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. :)
-- brion
In the next RFC meeting we will discuss the following RFCs:
* Service split along presentation vs data manipulation line
<https://www.mediawiki.org/wiki/Requests_for_comment/Service_split_along_pre…>
* Support for user-specific page lists in core
<https://www.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specif…>
The meeting time is the same as last week as measured in UTC, which
means that it will be an hour later for people in the US who observe
daylight savings time.
The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:
* UTC: Wednesday 21:00
* US PDT: Wednesday 14:00
* Europe CET: Wednesday 22:00
* Australia AEDT: Thursday 08:00
-- Tim Starling
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.
----
Justin Folvarcik
Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_March_9th>
For a longer term view, see the new Roadmap project in Phabricator:
https://phabricator.wikimedia.org/tag/roadmap/
A quick list of notable items for next week...
== Week of... ==
* Deploy RESTBase (separate announcement to follow)
** https://phabricator.wikimedia.org/T89481
* Use RESTBase for Visual ditor from the MediaWiki Virtual Rest Service
** https://phabricator.wikimedia.org/T89066
== Tuesday ==
* MediaWiki deploy
** group1 to 1.25wmf20: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf20>
== Wednesday ==
* MediaWiki deploy
** group2 to 1.25wmf20 (all Wikipedias)
** group0 to 1.25wmf21 (test/test2/testwikidata/mediawiki)
Thanks and as always, questions and comments welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
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
are aware.
- [BREAKING CHANGE] Remove deprecated LookupInputWidget (Bartosz
Dziewoński)
Deprecated in v0.6.3, at which point they were already unused as far as we
are aware.
- [BREAKING CHANGE] Remove deprecated GridLayout (Bartosz Dziewoński)
Deprecated in v0.7.0, at which point they were already unused as far as we
are aware.
*Deprecation changes since last major release:*
- [DEPRECATING CHANGE] Rename setPosition to setLabelPosition (Ed
Sanders)
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
flagging here.
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
<https://doc.wikimedia.org/oojs-ui/master/#!/api>.
- Trevor
Hi,
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.
Thanks
Hello,
I’ve been learning how to use Moses decoder [1] 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?
Thanks,
Baha
[1] https://github.com/moses-smt/mosesdecoder