I just want to check on folks to see if there's any more comments or issues
with this RfC:
https://www.mediawiki.org/wiki/Requests_for_comment/LESS
Basically, this adds a stylesheet preprocessor for ResourceLoader styles
specified as '.less' files; currently no on-wiki or gadget handling is
included, so there are not security issues with LESS @import rules.
LESS <http://lesscss.org/> is pretty handy and is used by a number of our
extensions to make styles more maintainable (set constants, do math, make
combined rules for things like -webkit-blah). Direct LESS support in core
will do away with the precompilation step during development.
There's a patch implementing it in core:
https://gerrit.wikimedia.org/r/#/c/78669/
and a sample patch updating MobileFrontend to use it:
https://gerrit.wikimedia.org/r/#/c/84139/
Open questions:
* Are there any remaining problems with the caching and dependency checks?
* What's the best way to handle image embedding? (/* @embed */ rules get
messed up but we can use an alternate function...) -- see notes on gerrit
* ...any other concerns with performance, security, or basic functionality?
-- brion
Within the Flow extension we have a need for inserting our own special
changes into the recentchanges table so that Watchlists continue to inform
users of changes in the same ways they are used to. Within mediawiki the
WikiData extension has similar requirements and has implemented a solution
that works for their use case. Flow is looking to extend this to handle
multiple types of external change sources. The solution taken by WikiData
to render the lines works well and will be used by Flow, but we have some
concerns regarding how different types of external changes will be filtered
by the queries that generate the Special:RecentChanges and
Special:Watchlist pages.
How does the current solution work?
There is a field in the recentchanges table, rc_type. All WikiData entries
use the value of RC_EXTERNAL( = 5) for this field. Queries are generated
with either (rc_type = 5) or (rc_type != 5) when filtering is required.
Requirements:
- Currently WikiData entries into recentchanges are filtered from
Special:RecentChanges and Special:Watchlist. This is toggleable. By
default we will not want to filter Flow entries, but will want to offer a
toggle much like WikiData does.
- More types of external change sources should be able to add themselves
in the future without core changes
- We should play nice with the db slave's serving up watchlists.
There are a couple options, each with their own tradeoffs.
1. Use rc_type = RC_EXTERNAL and add a new field to the recentchanges
table, rc_external_type. This would be a varchar(16) field. Wikidata and
Flow would put their respective names in the field to distinguish between
each other. This is conceptually simple, but makes the queries look even
odder. (rc_type != 5) becomes (rc_type != 5 AND rc_external_type !=
'wikidata').
2. Similar to 1, but instead of creating a new field reuse rc_log_type
field which is only used when rc_type = RC_LOG. This seems a bit hacky,
but would only need a field rename to not feel so hacky. I'm not proposing
to rename the field though as there are a variety of extensions depending
on the current field name and we are not going to coordinate getting them
all updated at the exact same time. The fact that this field is used by
various extensions may be a hint that we shouldn't reuse it.
3. Replace RC_EXTERNAL with RC_WIKIDATA and RC_FLOW constants in their
respective extensions. This is also straightforward, but adds development
overhead to ensure future creators of RC_* constants do not conflict with
each other. It would be handled similarly to NS_* constants with an
on-wiki list. I have heard some mention that naming conflicts have
occurred in the past with this solution. This would force queries looking
for only core sources of change to provide an inclusive list of RC_* values
to find, rather than using rc_type != RC_EXTERNAL.
Things to consider:
On smaller wiki's WikiData changes can account for > 50% of the changes.
Talk namespace edits, which we expect to eventually replace with flow
edits, account for ~20% of enwiki recentchanges rows
The standard query issued by Special:RecentChanges is
SELECT /* lots of fields */
FROM `recentchanges`
FORCE INDEX (rc_timestamp)
LEFT JOIN `watchlist` ON (wl_user = '2' AND (wl_title=rc_title) AND
(wl_namespace=rc_namespace))
LEFT JOIN `tag_summary` ON ((ts_rc_id=rc_id))
WHERE (rc_timestamp >= '20130912000000') AND rc_bot = '0' AND (rc_type !=
5)
ORDER BY rc_timestamp DESC LIMIT 50
The standard query issued by Special:Watchlist is
SELECT /* lots of fields */
FROM `recentchanges`
INNER JOIN `watchlist` ON (wl_user = '2' AND (wl_namespace=rc_namespace)
AND (wl_title=rc_title))
LEFT JOIN `page` ON ((rc_cur_id=page_id))
LEFT JOIN `tag_summary` ON ((ts_rc_id=rc_id))
WHERE (rc_timestamp > '20130916175626') AND (rc_this_oldid=page_latest OR
rc_type=3) AND (rc_type != 5)
ORDER BY rc_timestamp DESC
Without further input I will be implementing option 3 from above, I welcome
any input on better solutions, or potential pitfalls with this solution.
Erik Bernhardson
Hello,
Persian Wikipedia is one of the largest wikis based on number of categories
but It's not very common that people consider adding interwiki of
categories (they think interwiki is just for articles) so we have tons of
tons (before writing my engine that was 30K out of 170K) categories without
any interwikis which is really bad. I wrote some codes to make it better
but It wasn't enough So I wrote an engine that gets two database: 1-list of
categories without interwiki 2-list of categories with interwiki to a
certain language (e.g. English) with the target interwiki and after that my
bot analyzes and "guess" what is the correct interwiki of category based on
patterns of naming them in the second database
and bot reports. After running this code on fa.wp there was a very huge
report [1] and we started to sort things out (merging duplicates [2],
deleting extra ones, adding the correct iw) and now it's less than 25K
categories without interwikis (and It's becoming less and less) we did the
same on templates namespace [3] and we interwikified more than 10K
templates after that.
And because this engine doesn't use any language-related analyses It can be
ran in any language and get interwiki from any language (we planned to run
this on Persian Wikipedia again but this time we use Dutch and German
languages as repo of interwiki)
So here is my question: Is there similar situation in your wiki? Do you
want to run this code in your wiki too? Do you have any suggestion?
[1]: https://fa.wikipedia.org/w/index.php?title=کاربر:Ladsgroup/
ردهها&oldid=10959457
[2]: One of the benefits of running this engine is we can find duplicates
[3]:
https://fa.wikipedia.org/wiki/%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1:Ladsgroup/%D8%…
Best
---
Amir
Today's top news in Sweden is a revelation of how
the police keeps a register or computer file on
certain categories of people. Anyway, a side track
of this discussion is that they apparently are using
a software called Analyst's Notebook, which is
useful for tracing connections between individuals.
This software is made by i2, now owned by IBM.
http://en.wikipedia.org/wiki/Analyst%27s_Notebook
I think this kind of software could be useful in
tracing relationships between historic writers,
artists, inventors, and politicians. Who socialized
with, learned from, or inspired whom? Even
though Wikipedia contains lots of basic facts,
the large patterns of connections are not so
easily visible.
Are there any examples of counterterrorism software
being used to better understand history? Are there
any free/open source and/or web based versions of
such software?
All that I have seen of DBpedia is much more
primitive than this.
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
Hello!
There was a grrrit-wm outage for a few hours earlier today. This was
caused by the link between our tampa datacenter (where toollabs mostly
lives) and our eqiad data center (where gerrit lives) (see preliminary
report on http://lists.wikimedia.org/pipermail/labs-l/2013-September/001678.html).
It is back up now, and I'll see if I can find ways of figuring out
when a ssh connection to gerrit is 'hung' (but not terminated).
Thanks!
--
Yuvi Panda T
http://yuvi.in/blog
Ugh, that was meant to go to wikitech-l too...
On 09/20/2013 03:38 PM, Juliusz Gonera wrote:
> Hi,
>
> A bit of background: Not long ago we launched mobile editing. Soon
> after that we discovered that the mobile editor fails on many wikis
> because we hadn't thought think about AbuseFilter support. We're
> trying to fix this now.
>
> Statistics about the most frequent AbuseFilter error codes we're getting:
> https://mingle.corp.wikimedia.org/projects/mobile/cards/1162
> Related bug:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=52049
>
> After getting some initial information from legoktm, my thoughts are:
>
> * Probably no changes to AbuseFilter are necessary and we should
> implement everything in MobileFrontend.
>
> * We should display the warning message (edit.warning in API response)
> for all codes (edit.code in API response) that start with
> abusefilter-warning* and allow the user to resubmit.
>
> * We should display the disallow message (edit.warning in API
> response) for abusefilter-disallow and not allow the user to resubmit.
>
> * We should display edit.warning message if present or a general one
> and not allow the user to resubmit for all the other error codes
> (until now we've got abusefilter-blanking, abusefilter-blank,
> abusefilter-imza, abusefilter-blocked-display and
> abusefilter-autobiography, but they don't happen too often).
>
> Are my assumptions correct? Any thoughts or suggestions?
>
Hello!
Here's what's coming up, deployment-wise, next week!
As always, full schedule here:
https://wikitech.wikimedia.org/wiki/Deployments
== Monday ==
* MediaWiki 1.22wmf18 to all non-wikipedia project sites
* WikiData will be enabled on Wikimedia Commons (interwiki links)
* CirrusSearch (the new search backend) will be turned on as the default
search backend for Italian Wikitionary and enabled as a secondary
backend for English Wikisource and Catalan Wikipedia.
== Tuesday ==
* CirrusSearch will be enabled on the set of closed wikis (eg: old
Wikimania wikis).
== Thursday ==
* MediaWiki 1.22wmf18 will be deployed to all Wikipedias
* MediaWiki 1.22wmf19 will be deployed to the set of test wikis plus
mediawiki.org
Have a good weekend!
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
[Cross-posted]
Hello,
The Wikimedia Language Engineering team will be hosting an IRC office
hour on Wednesday, September 25, 2013 between 17:00 - 18:00 UTC. (See
below for timezone conversion and other details.) We will be talking
about some of our projects that are in development, a short round up
from Google Summer of Code and then taking questions for the remaining
time.
If there are things that you would like to bring to our attention then
this would be a good time to do so. Questions can also be sent to me
directly before the event. See you there!
Thanks
Runa
=== Event Details ===
What: WMF Language Engineering Office hour
When: September 25, 2013 (Wednesday). 1700-1800 UTC
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130925T1700
Where: IRC Channel #wikimedia-office on FreeNode
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation