Hi,
I've been reading the mw.org and wikitech pages on Cirrussearch (and
the code) in the hope that I will be able to understand how is the
page content transformed before being sent to ES and how is it kept in
ES and I have a few questions:
1. Is the documentation available anywhere? I don't see it on
https://doc.wikimedia.org/
2. What part of the whole ecosystem transforms the wikitext into
indexable text? Where can I find it? It should be somewhere downstream
fromCirrusSearch\Updater::updateFromTitle(), but I can't figure uout
where exactly.
If this transformation doesn't happen, from where is the searchable
text obtained?
3. Where can I find the ES schema used for wikipages? Is it different
for images/categories?
Thanks,
Strainu
Hi All,
TLDR: on the mobile web, Wikidata descriptions will appear under article
titles in search results, nearby and watchlist starting tomorrow afternoon
(Thu, Oct 29) across projects. A 'kill switch' has been implemented so
that this feature can be turned off if necessary.
Background:
In Q2 of last year, Wikidata descriptions were added to both our official
apps: iOS and Android and resulted in wonderful qualitative feedback (as
the discovery team knows, it is hard to define 'success' with search (fewer
searches, more searches?). Though moving Wikidata descriptions to search
on mobile web was planned for Q3 of last year, it has been sitting in beta
for many months as there was some concern that at scale on the web, it
might prove to be an incentive to vandalize Wikidata (and article editors
would not have an obvious, wikipedia way to undo such edits).
Ultimately, we think that anything showing up on Wikipedia should be
editable ON Wikipedia. Wikidata description editing is something we are
going to aim for. Given the success of descriptions in search results on
apps, we would rather move forward with the presentation and work towards a
goal of editing in-line than to hold up the entire thing based on a fear
that might not be warranted. In consultation with the Wikidata team, we
decided to move forward with pushing the feature to stable as long as we
had the ability to pull the feature back if there were any issues.
We are relying on community feedback to let us know if you have any issues
or hear from anyone that this is causing problems. Our community liaison
team will be posting notices on village pumps shortly. Thanks!
Best,
Jon
WMF Reading Product Lead
Hi.
I was curious about the prevalence and types of inline styling (or more
specifically, inline CSS) in articles on the English Wikipedia.
The relevant task is here: <https://phabricator.wikimedia.org/T115228>.
The results are here: <https://phabricator.wikimedia.org/P2230>.
The following are the top ten instances of inline styling from main
namespace pages on the English Wikipedia, as of about 2015-10-02:
1552197 text-align: center;
499756 text-align: left;
355952 background: #dfffdf;
235222 background: #cfcfff;
215038 background: #efcfff;
210702 text-align: right;
143095 display: none;
93646 background: #efefef;
86391 font-size: 90%;
80420 background: #fff;
My hope is that a better understanding of the uses of inline styling will
allow us to reduce the overall amount of it in smart ways. Semantic CSS
classes and per-page or per-template CSS files might be part of this.
MZMcBride
Hi,
It seems there's a new problem with named refs : several articles are now
displaying errors of having the same name for several references with
different content.
See my description on https://phabricator.wikimedia.org/T117037
It happens with {{#tag:ref| |...}}, when there's a whitespace instead of
nothing in the content part. The whitespace seems to be considered as being
a content on its own, rather than being considered as empty.
Nico
Hi,
I have recently did some review of the Mediawiki-Installer
project, fixing some minor bugs right away:
https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+branch:master+top…https://phabricator.wikimedia.org/tag/mediawiki-installer/
As far as I understand the workboard, I cannot (and shouldn't)
have too many columns - they are there to illustrate the progress of work.
Since we have so many issues open there (129 open in the backlog,
which is one per 100 lines of code counted with "wc -l")
I'd like to group them into those than can be tested and even
probably fixed at the same time:
* Restricted environments (currently a column on the workboard).
* Users and passwords
* Environment checks
etc.
Those things need to be pretty fluid (I like to re-think
and re-organize as I go).
How can I do that? I understand I need a permission to create
a project, which is too bureaucratic for this task.
Probably the good way would be to define sprints (but without
dates, since it's volunteer work:) but a Sprint is also
a project, so I need permission, too.
Any ideas how to do it?
~Saper
In the next RFC meeting, we will discuss the following RFC:
* Dependency Injection for MediaWiki core
<https://phabricator.wikimedia.org/T384>
In the event that Daniel is not able to attend, we will instead discuss:
* Implementing the reliable event bus using Kafka
<https://phabricator.wikimedia.org/T88459>
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
Hi all,
We're rapidly approaching the 1.26 release. General guilting e-mail
to get some extra eyes on the things currently tagged against the
release.
https://phabricator.wikimedia.org/maniphest/query/jcSXdUecbcLp/#R
Buggy releases -> sad times. Let's wrap this one up :)
-Chad