TL;DR: Parsoid isn't i18n friendly and uses English keywords instead of
localized.[1] Is it a bug or feature? Please voice your opinion!
Longer version:
For some funny reasons Parsoid is reading arrays from "right to left"[1],
that is, it uses the LAST alias of the magic words rather than the first
one[2].
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
option.
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
different alphabet.
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:
https://phab.wmfusercontent.org/file/data/bskxfupspqo64dnnkdr7/PHID-FILE-v4…
And based on this I wrote a python script to suggest a reordering of the
aliases by usage[3], so if choice 2 is selected, we can merge[2] and all
languages will use the preferred choice.
[1] https://phabricator.wikimedia.org/T53852
[2] https://gerrit.wikimedia.org/r/#/c/244254/3/lib/wts.LinkHandler.js
[3] https://gerrit.wikimedia.org/r/#/c/247914
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>
wrote:
>
> > I've written a patch[1] that introduces a new feature to the Thanks
> > extension called "feelings". When hovering over a "thank" link, five
> > different emoji icons will pop up[2], 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[3].
> >
>
>
> Only one of these options?
> --scott, surprised, happy & a bit fearful
>
> --
> (http://cscott.net)
Not angry, just disappointed
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Some of us at the hackathon ran into this old bug again:
https://phabricator.wikimedia.org/T62835
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.
This would allow browser-side JavaScript code on other sites (tools,
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
hope. :)
-- brion
Hey all,
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:
http://i.imgur.com/XzWUk0h.gifvhttp://i.imgur.com/lJ7l6Vl.gifv
Cool? Cool.
Read the docs on Wikitech
<https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug> for more
information.
Hi,
this week's RFC update sees two RFCs entering the discussion, and one RFC (on
requiring mbstring <https://phabricator.wikimedia.org/T129435>) entering
the "final comment period", after which a decision will be made.
Gabriel
RFC inbox:
T130567: WIP RFC: Hygienic transclusions for WYSIWYG, incremental parsing &
composition <https://phabricator.wikimedia.org/T130567>: High-level
companion task to T114444 DOM scopes
<https://phabricator.wikimedia.org/T114444> and T114445 Balanced templates
<https://phabricator.wikimedia.org/T114445>. Moving to “Needs shepherd”.
Tim?
T16950: Support global preferences
<https://phabricator.wikimedia.org/T16950>: "It would be nice if users and
developers could designate certain preferences to automatically apply
across all wikis. This will require A Lot of Work™.
Extension:GlobalPreferences is a rough draft of the functionality."
Leaving in inbox, RobLa will ask Kunal.
Today's IRC session:
Open discussion about the following RFCs
-
T124504 <https://phabricator.wikimedia.org/T124504> Transition WikiDev
'16 working areas into working groups
-
T123753 <https://phabricator.wikimedia.org/T123753> Establish
retrospective reports for Security
<https://phabricator.wikimedia.org/tag/security/> and Performance
<https://phabricator.wikimedia.org/tag/performance/> incidents
-
T119908 <https://phabricator.wikimedia.org/T119908> [RfC]: Migrate code
review / management to Phabricator from Gerrit
-
T120164 <https://phabricator.wikimedia.org/T120164> RfC: Institute "last
call" period for MediaWiki RfCs (WIP)
Much of the discussion was on T119908: [RfC]: Migrate code review /
management to Phabricator from Gerrit
<https://phabricator.wikimedia.org/T119908>, and some on T123753
<https://phabricator.wikimedia.org/T123753> (retrospectives). RobLa has
posted a full summary of the discussion
<https://phabricator.wikimedia.org/E152#1603> on phabricator.
Entering Final Comment Period:
RFCs which are reaching a decision are entering a week-long 'final comment
period', after which the ArchCom makes a final decision based on the
discussion. Express your opinions now. This week's FCPs are:
T129435 RFC: Drop support for running without mbstring
<https://phabricator.wikimedia.org/T129435> (Gabriel): The PHP mbstring
module enables multi-lingual string handling. Given good distribution
support and significant performance benefits, most participants have
expressed support for requiring the module. If you think that we should
continue to provide fall-backs despite relatively poor performance, then
please comment now.
Under discussion:
T108655 Standardise on how to access/register JavaScript interfaces
<https://phabricator.wikimedia.org/T108655> (Roan) Minimal version was
approved and being implemented. Waiting for drafting of second RFC for the
more contentious changes.
T122942 RFC: Support language variants in the REST API
<https://phabricator.wikimedia.org/T122942> (Gabriel): Different options
for supporting language variant selection in the REST API. Needed for
languages like Chinese.
T39902 RFC: Implement rendering of redlinks (in a post-processor?)
<https://phabricator.wikimedia.org/T39902> (Gabriel): Solutions for
highlighting links to non-existing pages in Parsoid HTML. Main question is
preprocessing vs. separate metadata processed on client. Parsing and
Services teams investigating performance trade-offs.
T130663 WIP RFC: Reference API requirements and options
<https://phabricator.wikimedia.org/T130663> (Timo): Working with Gabriel
and others to better define the scope of the RFC and come up with a solid
proposal. Relates to other on-going product goals and may be delayed on
better clarification on those and gathering of other use cases /
requirements.
T18691 RFC: Section headings should have a clickable anchor
<https://phabricator.wikimedia.org/T18691> (Timo): Working on better
understanding of the problem space and possible solutions. Volker gathered
various considerations and challenges on the RFC’s talk page at
mediawiki.org. Check them out!
T124504 Transition WikiDev '16 working areas into working groups
<https://phabricator.wikimedia.org/T124504> (RobLa): Highlighting in E152
T66214 Use content hash based image / thumb URLs & define an official thumb
API <https://phabricator.wikimedia.org/T66214> (Brion): No changes in the
last week.
T124792 Service Locator for MediaWiki core
<https://phabricator.wikimedia.org/T124792> (Daniel): Discussed in E150
last week. Daniel is interested in a possible working group; will discuss
at Hackathon.
T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap
<https://phabricator.wikimedia.org/T113034> (Daniel): No update since March
17.
No activity since March 16:
T122825 Service ownership and minimum maintenance requirements
<https://phabricator.wikimedia.org/T122825> (Gabriel)
T128351 RFC: Notifications in core
<https://phabricator.wikimedia.org/T128351> (Brion)
T118517 RFC: Use <figure> for media
<https://phabricator.wikimedia.org/T118517> (Brion)
T88596 Improving extension management
<https://phabricator.wikimedia.org/T88596> (Daniel)
T114444 RFC: Introduce notion of DOM scopes in wikitext
<https://phabricator.wikimedia.org/T114444> (Tim)
T130528 RFC: PSR-6 Cache interface in Mediawiki core
<https://phabricator.wikimedia.org/T130528> (No shepherd)
--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation
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
High: 238
Normal: 399
Low: 728
Lowest: 537
(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 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on iridium at Fri Apr 1 00:00:10 UTC 2016)