TL;DR: Parsoid isn't i18n friendly and uses English keywords instead of
localized. Is it a bug or feature? Please voice your opinion!
For some funny reasons Parsoid is reading arrays from "right to left",
that is, it uses the LAST alias of the magic words rather than the first
One of the reasons for this is because in English the shorter "thumb" is
preferred compared to the long "thumbnail". However, instead of fixing
MessagesEn.php to define thumb as the first option, parsoid uses the last
This choice result in all other wikis using the English alias (which
appears last in magic words) rather than the localized one - so Parsoid
isn't i18n friendly.
However there are different POVs regarding the correct solution for it:
1. Use English aliases in all projects - these are the most used aliases
[and one of the reasons is people copying code from enwiki or using biased
tools such as Parsoid]
2. Use localized aliases - keep the article content and syntax in the same
language. This is especially important for non-latin languages with
And there is a consensus for English being bad choice for RTL languages as
it cause mixed directional content which should be avoided. So if we go
with 1 choice, RTL languages should be exception.
I believe there is a cultural point of view here, and would like to hear
what do you think (especially non RTL and non English speakers): Do you
prefer mini (German), vignette (French), miniaturadeimagen (Spanish), мини
(Russian) instead of thumb (for example)?
I did some dump-minning to get the usage statistics:
And based on this I wrote a python script to suggest a reordering of the
aliases by usage, so if choice 2 is selected, we can merge and all
languages will use the preferred choice.
On Apr 1, 2016 11:00 PM, "C. Scott Ananian" <cananian(a)wikimedia.org> wrote:
> On Fri, Apr 1, 2016 at 3:24 PM, Legoktm <legoktm.wikipedia(a)gmail.com>
> > I've written a patch that introduces a new feature to the Thanks
> > extension called "feelings". When hovering over a "thank" link, five
> > different emoji icons will pop up, representing five different
> > feelings: happy, love, surprise, anger, and fear. Editors can pick one
> > of those options instead of just a plain thanks, to indicate how they
> > really feel, which the recipient will see.
> Only one of these options?
> --scott, surprised, happy & a bit fearful
Not angry, just disappointed
> Wikitech-l mailing list
Some of us at the hackathon ran into this old bug again:
namely, the MediaWiki API currently completely forbids cross-origin
requests in the CORS config except for whitelisting authenticated requests
from our own domains, whereas it could also allow non-authenticated
cross-origin requests from non-whitelisted domains.
mashups, whatever) to get anonymous data from Wikipedia, Wikidata, etc
without resorting to JSONP (an old-school hack whereby JSON data is loaded
via a callback in a <script> tag).
JSONP is fragile, and is unsafe for other sites to rely on, as it's a
potential cross-site scripting vector for them.
CORS is pretty mature these days, and should be something we can rely on. I
I'm writing to let you know of a cool new facility for debugging MediaWiki
code on the Wikimedia production cluster -- the X-Wikimedia-Debug
<https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug> HTTP header.
By setting this header on requests to Wikimedia wikis, you can:
- Bypass the cache.
- Force Varnish to pass your request to a specific backend server.
- Profile request and log profiling data to XHGui.
- Turn on all log channels and send log messages to a special view in
Kibana / Logstash.
- Force MediaWiki to process the request in read-only mode.
And the best part: there are browser extensions for Chrome and Firefox that
provide a friendly user-interface for these features:
Read the docs on Wikitech
<https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug> for more
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2016-03): 307
Active users (any activity) in (2016-03): 923
Task authors in (2016-03): 501
Users who have closed tasks in (2016-03): 280
Projects which had at least one task moved from one column to another on
their workboard in (2016-03): 190
Tasks created in (2016-03): 2997
Tasks closed in (2016-03): 2543
Open and stalled tasks in total: 29261
Median age in days of open tasks by priority:
Unbreak now: 42
Needs Triage: 150
(How long tasks have been open, not how long they have had that priority)
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Fab Rick Aytor
(via community_metrics.sh on iridium at Fri Apr 1 00:00:10 UTC 2016)