+ mobile-l
This is all useful feedback.
That would be ideal if jscs had this capability but an interim
solution would be good in the meantime.
I think it's important to codify our coding conventions across the
project. It will make it much easier for newbies to write code without
having to worry about coding style.
On Fri, Nov 21, 2014 at 11:19 PM, Krinkle <krinklemail(a)gmail.com> wrote:
> Hi Jon,
>
> Just wanted to quickly share my ideas on code formatting.
>
> First off, as long as there are no side effects (e.g. normalising too much),
> any tool will do in the mean-while and it's trivial to switch later on (e.g.
> just change which tasks the "grunt fixup" alias will run). They wouldn't be
> run as part of "grunt test". Instead it's a convenience tool for developers
> to easily reformat code locally before submission (e.g. after jscs pointed
> out one or more errors in their local grunt run). This is among the reasons
> why using a local Grunt is so convenient. It enables individual projects to
> try out new tools without requiring server-side configuration. I try out new
> tasks all the time in oojs-core and VisualEditor. Some stick, some don't.
>
> Having said that, I've used js-beautifier in the past and worry it won't
> work well for us.
>
> esformatter[1] on the other hand seems to have a more stable implementation
> and general approach.
>
> However, any tool other than jscs will come with the down side of having to
> declare your style guide, again. Which will amount to tedious duplication
> and loads of edge cases where the tools declare the style using different
> logical rules and will never match.
>
> jscs ships with a wikimedia preset that saves lots of configuration in the
> first place.
>
> And fortunately, jscs actually plans to ship an "autofixer" utility that
> will correct violations from within jscs itself. Using the solid parser and
> tokeniser that jscs is known for. Thus, even the small jscs rule config we
> do have, won't have to be duplicated.
>
> The jQuery Team also supports this effort for their various javascript
> projects (both as style checker, as we do already, and as code formatter).
> So that's a major player we'll have on our side when it comes to continued
> support for the tool.
>
> https://github.com/jscs-dev/node-jscs/issues/516
>
> Supported by Mike Sherov (mikesherov) and Oleg Gaidarenko (markelog), from
> the jQuery Team (who are also jscs collaborators). And Marat Dulin
> (mdevils), founder of jscs.
>
> Best,
>
> — Krinkle
>
> [1] https://github.com/millermedeiros/esformatter
>
> On 20 Nov 2014, at 23:57, Derk-Jan Hartman <d.j.hartman(a)gmail.com> wrote:
>
> Begin forwarded message:
>
> Date: 20 november 2014 21:19:24 CET
> From: Jon Robson <jrobson(a)wikimedia.org>
> To: Bahodir Mansurov <bmansurov(a)wikimedia.org>
> Cc: mobile-l <mobile-l(a)lists.wikimedia.org>
> Subject: Re: [WikimediaMobile] Using jsbeautify in MobileFrontend
>
> Follow up
> If I run `make jsbeautify` now
> then https://gist.github.com/jdlrobson/a05ddad00175ebceac68 is the result.
>
> Outstanding actions:
> * Need input on rest of the team about which of delete
> this.cache[title]; or delete this.cache[ title ]; is the preferred
> standard.
> * You'll notice jsbeautify and inlne comments need to be ironed out.
> For example:
> https://gist.github.com/jdlrobson/a05ddad00175ebceac68#file-gistfile1-diff-…
>
> Apart from the above 2 jsbeautify makes some adjustments to our
> whitspace which I guess we'll just have to live with.
>
> Please can everyone else let me know how they think we should proceed?
>
>
>
> On Wed, Nov 19, 2014 at 4:12 AM, Bahodir Mansurov
> <bmansurov(a)wikimedia.org> wrote:
>
> As for # Rule 4, it makes sense to add spaces inside square brackets. The
> reasoning is the same as why we add spaces inside parenthesis.
>
> On Nov 18, 2014, at 12:28 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:
>
> I explored running jsbeautify [1] on the MobileFrontend codebase and
> looked at how the output differs from the current styling. It
> introduces various rules that MobileFrontend is currently not adhering
> too. MobileFrontend already uses jscs [2] so we want to make sure the
> outputs of both are compatible. Here is my report on that with the
> recommendation that we should use it.
>
> #Rule 1: object properties defined on a single line.
> e.g.
> {
> foo: 2,
> bar: 3
> }
> NOT { foo: 2, bar: 3 }
>
> I think this would be a good idea to adopt. I will explore if jscs can
> enforce this.
>
> # Rule 2: variables that are initialised must be followed by a new
> line (although I noted a few odd cases e.g. in Page.js after a "?:"
> expression and /MobileWebClickTracking.js
> e.g.
> var Foo, bar = $( 'div' ),
> Baz,
> Bar;
>
> not:
> var Foo, bar = $( 'div' ), Baz, Bar;
>
> This will be fixed if I implement https://trello.com/c/0dkx0ldL
>
> # Rule 3: All chained events should be indented
> e.g.
> foo()
> .bar();
>
> not
> foo().
> bar();
>
> Seems like a no brainer. One that happens naturally most of the time.
>
> # Rule 4: Spacing in object parameters
> e.g.
> foo[ 1 ]
> [ 1, 2, 3, 4 ]
>
> not:
> foo[1]
> [1, 2, 3, 4]
>
> This is different to MediaWiki coding conventions but I can implement
> https://github.com/beautify-web/js-beautify/issues/424 to give us
> this.
> We seem a bit inconsistent ourselves with this convention - let me
> know how you think this rule should work in our codebase...
>
> # Rule 5: New line after variable declarations
>
> var x, y, z;
>
> z();
>
> not:
> var x, y, z;
> z();
>
> Also:
> function foo() {}
>
> function bar() {}
>
> not:
> function foo() {}
> function bar() {}
>
> Seems like a no brainer and shouldn't introduce any major issues with
> code review.
>
> # Rule 6: Comments must respect the current indentation level
>
> if () {
> ...
> // If i is 5 we do something special
> } else if ( i === 5 ){
>
> }
> becomes
> if () {
> ...
> // If i is 5 we do something special
> } else if ( i === 5 ){
>
> }
> We'll have to think about what to do with these comments but I don't
> think this should be a blocker to using jsbeautify. It will only pop
> up occasionally.
>
> # Rule 7: On long if statements the curly brace must be indented.
> And the first condition should be on the same line
>
> if ( enableToc || ...
> ....
> && baz ) {
>
>
> not:
> if (
> enableToc || ...
> ....
> && baz ) {
>
> Again I'm not sure if this will happen too often. This to me is a sign
> that we should be using functions rather than long if statements
> personally. Again not a blocker.
>
> Actions:
> * Implement https://github.com/beautify-web/js-beautify/issues/424
> * You guys need to advise me on how we should handle square brackets
> in our codebase in such a way we respect MediaWiki coding conventions
> and come up with a consistent style we are happy with and can adhere
> to.
> * I'll implement https://trello.com/c/0dkx0ldL in some form
> * I'll explore if jscs can support objects defined on new line
> * When the above are done I recommend we turn on jsbeautify for the project.
>
> I've setup a tracking card for the above work:
> https://trello.com/c/5btWf2JN/90-snakes-on-a-plane
> and will be looking at these problems today.
>
> [1] https://github.com/beautify-web/js-beautify
> [2] https://github.com/jscs-dev/node-jscs
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
>
In the course of examining Opera Mini bugs, I've been talking with Jared
and Maryana and others about different types of browser feature support,
and I needed to run some queries to get a handle on the facts. Results
follow.
Prologue: I ran some queries to gauge <noscript> (no JavaScript support at
all) usage, versus usage of browsers with low-end JavaScript
("ResourceLoader-impaired", or for short, "RLI") precluding them from
things like mobile editing, on the mobile web Wikipedias. I thought I'd
share this information with you.
Caveat Emptor: I am not a Ph.D in maths/stats. And I haven't had the
queries peer reviewed. But I've tried to analyze each OR case for
User-Agent in the queries below to ensure that I actually see results that
are sensible.
Results:
On zero-rated networks accessing mobile web Wikipedia:* About 1.8% of
Wikipedia Zero banners served are to <noscript> browsers. The other 98.2%
of banners are served to browsers with at least some form of JavaScript
support.* About 36% of Wikipedia Zero pageviews (using a dumbed down
definition) are on RLI browsers.
On non-zero-rated networks accessing mobile web Wikipedia:* The percentage
of users on <noscript> browsers is unknown (AFAIK) but if we implemented a
<noscript> tracking pixel akin to the GIF banner on Wikipedia Zero, I
suspect we'd find it's 1.8% or less.* About 6% of overall Wikipedia mobile
web pageviews (using a dumbed down definition) are on RLI browsers.
Even gorier details. SQL/HQL at the end:
1. When browsers request GIF Wikipedia Zero banners, the URL has
zcmd=img-banner in it. When they request JavaScript banners, the URL has
zcmd=js-banner in it. Both banners have a cache lifetime of 300 seconds, so
it's roughly apples to apples when we look at their usage.
2. The simplest definition of a pageview I've found useful is to look at
HTTP 200 (non-cached) HTML responses and JSON responses for well defined
URL paths.
3. Our ResourceLoader bootstrapping code at
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/09c55592a73544cc21e002f…
, which puts things like Opera Mini in the RLI bucket, also puts Google
Glass in the RLI bucket. That doesn't mean Google Glass is incapable of
running high end JavaScript, it just reflects that the screen is really
small. Just wanted to point that out. Expansion into wearables and IoT will
be a theme I'm sure in due time.
4. The other approximately 62% or approximately 92% of user agents for
zero-rated networks and non-zero-rated networks, respectively, in the
non-RLI buckets may in fact lack good JavaScript facilities and we just
don't know any better (actually, we know for a fact at least some have bad
JS support), but these are rough figures, after all.
5. Some of the traffic is definitely from bots and the like, but I didn't
want to overcomplicate these queries any further. On the upside, In the
overall scheme of non-zero-rated mobile web Wikipedia access, bot traffic
such as GoogleBot kind of gets washed out because of the large number of
pageviews. Bot traffic on Wikipedia Zero networks seems to be fairly low
grade at the moment.
6. The queries. These queries could be optimized, but I erred on the side
of clarity, if you can call it that, for people familiar with SQL/HQL. If
we were to explore this more, I might also be interested in tuning the
non-Opera Mini browsers that are still Opera but are at too low of a
version; these non-OM Opera browsers might be slightly undercounted. It may
be the case that the particular two OR cases for the existing queries is
getting those particular rows with sufficient accuracy as is.
Single day requests for GIF Banners on zero-rated networks:74,807 (1.8% of
total)
select count(*)from webrequestwhere uri_host like '%.wikipedia.org'and
uri_query like '%zcmd=img-banner'and year = 2014 and month = 11 and day =
19and webrequest_source = 'mobile'and x_analytics like '%zero=%';
Single day requests for JavaScript Banners on zero-rated networks:4,100,385
(98.2% of total)
select count(*)from webrequestwhere uri_host like '%.wikipedia.org'and
uri_query like '%zcmd=js-banner'and year = 2014 and month = 11 and day =
19and webrequest_source = 'mobile'and x_analytics like '%zero=%';
Single day zero-rated "dumbed down" pageviews on Wikipedia mobile web,
expressly ResourceLoader-impaired UAs:1,099,607 (36% of total)
select count(*)from webrequestwhere year = 2014and month = 11and day =
19and webrequest_source = 'mobile'and uri_host like '%.wikipedia.org'and
http_status = '200' and(content_type like '%text/html%' or content_type
like '%application/json%')and (uri_path like '/wiki/%' or uri_path like
'/w/index.php' or(uri_path like '/w/api.php%' and uri_query like
'%action=mobileview%'))and (coalesce(regexp_extract(user_agent, '(MSIE
*[0-7][^\\d])', 1), '') != ''or coalesce(regexp_extract(user_agent,
'(Firefox\\/ *[0-2][^\\d])', 1), '') != ''or(user_agent like '%Opera/%'and
user_agent not like '%Version/%'and coalesce(regexp_extract(user_agent,
'(Opera\\/[0-9][^\\d])', 1), '') != '')or(user_agent like '%Opera/%'and
user_agent like '%Version/%'and coalesce(regexp_extract(user_agent,
'(Version\\/(11|10|[0-9])[^\\d])', 1), '') != '')or
coalesce(regexp_extract(user_agent, '( Opera *[0-9][^\\d])', 1), '') !=
''or coalesce(regexp_extract(user_agent, '(BlackBerry[^\\/]*\\/[1-5]\\.)',
1), '') != ''or coalesce(regexp_extract(user_agent, '(webOS\\/1\\.[0-4])',
1), '') != ''or lower(user_agent) like '%playstation%'or user_agent like
'%SymbianOS%'or user_agent like '%Series60%'or user_agent like
'%NetFront%'or user_agent like '%Opera Mini%'or user_agent like
'%S40OviBrowser%'or (user_agent like '%Glass%' and user_agent like
'%Android%'))and x_analytics like '%zero=%';
Single day zero-rated "dumbed down" pageviews on Wikipedia mobile web, all
UAs:3,047,700 (100% of total)
select count(*)from webrequestwhere year = 2014and month = 11and day =
19and webrequest_source = 'mobile'and uri_host like '%.wikipedia.org'and
http_status = '200' and(content_type like '%text/html%' or content_type
like '%application/json%')and (uri_path like '/wiki/%' or uri_path like
'/w/index.php' or(uri_path like '/w/api.php%' and uri_query like
'%action=mobileview%'))and x_analytics like '%zero=%';
Single day "dumbed down" pageviews on Wikipedia mobile web (includes both
zero-rated and non-zero-rated), expressly ResourceLoader-impaired
UAs:12,152,389 (6% of total)
select count(*)from webrequestwhere year = 2014and month = 11and day =
19and webrequest_source = 'mobile'and uri_host like '%.wikipedia.org'and
http_status = '200' and(content_type like '%text/html%' or content_type
like '%application/json%')and (uri_path like '/wiki/%' or uri_path like
'/w/index.php' or(uri_path like '/w/api.php%' and uri_query like
'%action=mobileview%'))and (coalesce(regexp_extract(user_agent, '(MSIE
*[0-7][^\\d])', 1), '') != ''or coalesce(regexp_extract(user_agent,
'(Firefox\\/ *[0-2][^\\d])', 1), '') != ''or(user_agent like '%Opera/%'and
user_agent not like '%Version/%'and coalesce(regexp_extract(user_agent,
'(Opera\\/[0-9][^\\d])', 1), '') != '')or(user_agent like '%Opera/%'and
user_agent like '%Version/%'and coalesce(regexp_extract(user_agent,
'(Version\\/(11|10|[0-9])[^\\d])', 1), '') != '')or
coalesce(regexp_extract(user_agent, '( Opera *[0-9][^\\d])', 1), '') !=
''or coalesce(regexp_extract(user_agent, '(BlackBerry[^\\/]*\\/[1-5]\\.)',
1), '') != ''or coalesce(regexp_extract(user_agent, '(webOS\\/1\\.[0-4])',
1), '') != ''or lower(user_agent) like '%playstation%'or user_agent like
'%SymbianOS%'or user_agent like '%Series60%'or user_agent like
'%NetFront%'or user_agent like '%Opera Mini%'or user_agent like
'%S40OviBrowser%'or (user_agent like '%Glass%' and user_agent like
'%Android%'));
Single day "dumbed down" pageviews on Wikipedia mobile web (includes both
zero-rated and non-zero-rated), all UAs:199,764,072 (100% of total)
select count(*)from webrequestwhere year = 2014and month = 11and day =
19and webrequest_source = 'mobile'and uri_host like '%.wikipedia.org'and
http_status = '200' and(content_type like '%text/html%' or content_type
like '%application/json%')and (uri_path like '/wiki/%' or uri_path like
'/w/index.php' or(uri_path like '/w/api.php%' and uri_query like
'%action=mobileview%'));
Hi there -
A lot of people on Wikipedia Zero use browsers ("User Agents", or "UAs" for
short) incompatible with site JavaScript [1]. We want to ensure that
critical functionality is basically functional for these people, and we've
been tracking findings at
https://etherpad.wikimedia.org/p/Lower_end_devices_checkup.
Thus far, we've re-reviewed Search [2] and Login/Account Creation [3], and
we'll be going over the other ones over the next several sprints.
I just added some screenshots from Opera Mini to the two Trello cards
below. To replicate Opera Mini behavior for oneself, if you don't already
have it, you can install Opera Mini on a device like an Android or iOS
device. Then set the app's mode to "Opera Mini" mode. Depending on your OS,
you may or may not need to toggle this "Opera Mini" setting; it might be on
by default. You can also use the emulator as described on the Wikipedia
Zero tech page [4].
-Adam
[1]
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/09c55592a73544cc21e002f…
This shows JavaScript UAs for which it's known that the JavaScript
capabilities are likely insufficient for a number of JavaScript features,
and thus the ResourceLoader technology instructs the UA to not commence
with further JavaScript loading. There are also other UAs with no
JavaScript support or with broken JavaScript implementations.
[2]
https://trello.com/c/blWoHdk8/1-improve-special-search-for-lower-end-device…
Incidentally, there's currently a regression making it impossible to enter
searches, at least on the Android and iOS Opera Mini clients I tested.
[3]
https://trello.com/c/0kKBcmoD/2-improve-login-and-account-creation-experien…
Note: On non-HTML5 browsers, the "placeholder" attribute is not supported.
[4] https://www.mediawiki.org/wiki/Wikipedia_Zero#Tools
I explored running jsbeautify [1] on the MobileFrontend codebase and
looked at how the output differs from the current styling. It
introduces various rules that MobileFrontend is currently not adhering
too. MobileFrontend already uses jscs [2] so we want to make sure the
outputs of both are compatible. Here is my report on that with the
recommendation that we should use it.
#Rule 1: object properties defined on a single line.
e.g.
{
foo: 2,
bar: 3
}
NOT { foo: 2, bar: 3 }
I think this would be a good idea to adopt. I will explore if jscs can
enforce this.
# Rule 2: variables that are initialised must be followed by a new
line (although I noted a few odd cases e.g. in Page.js after a "?:"
expression and /MobileWebClickTracking.js
e.g.
var Foo, bar = $( 'div' ),
Baz,
Bar;
not:
var Foo, bar = $( 'div' ), Baz, Bar;
This will be fixed if I implement https://trello.com/c/0dkx0ldL
# Rule 3: All chained events should be indented
e.g.
foo()
.bar();
not
foo().
bar();
Seems like a no brainer. One that happens naturally most of the time.
# Rule 4: Spacing in object parameters
e.g.
foo[ 1 ]
[ 1, 2, 3, 4 ]
not:
foo[1]
[1, 2, 3, 4]
This is different to MediaWiki coding conventions but I can implement
https://github.com/beautify-web/js-beautify/issues/424 to give us
this.
We seem a bit inconsistent ourselves with this convention - let me
know how you think this rule should work in our codebase...
# Rule 5: New line after variable declarations
var x, y, z;
z();
not:
var x, y, z;
z();
Also:
function foo() {}
function bar() {}
not:
function foo() {}
function bar() {}
Seems like a no brainer and shouldn't introduce any major issues with
code review.
# Rule 6: Comments must respect the current indentation level
if () {
...
// If i is 5 we do something special
} else if ( i === 5 ){
}
becomes
if () {
...
// If i is 5 we do something special
} else if ( i === 5 ){
}
We'll have to think about what to do with these comments but I don't
think this should be a blocker to using jsbeautify. It will only pop
up occasionally.
# Rule 7: On long if statements the curly brace must be indented.
And the first condition should be on the same line
if ( enableToc || ...
....
&& baz ) {
not:
if (
enableToc || ...
....
&& baz ) {
Again I'm not sure if this will happen too often. This to me is a sign
that we should be using functions rather than long if statements
personally. Again not a blocker.
Actions:
* Implement https://github.com/beautify-web/js-beautify/issues/424
* You guys need to advise me on how we should handle square brackets
in our codebase in such a way we respect MediaWiki coding conventions
and come up with a consistent style we are happy with and can adhere
to.
* I'll implement https://trello.com/c/0dkx0ldL in some form
* I'll explore if jscs can support objects defined on new line
* When the above are done I recommend we turn on jsbeautify for the project.
I've setup a tracking card for the above work:
https://trello.com/c/5btWf2JN/90-snakes-on-a-plane
and will be looking at these problems today.
[1] https://github.com/beautify-web/js-beautify
[2] https://github.com/jscs-dev/node-jscs
Hi,
I am raising this issue every once in a while...
Is there any plan to make the app less monolingual? See
https://bugzilla.wikimedia.org/show_bug.cgi?id=34100
Currently, the app shows content only in one language. It's possible to
switch to another language according to the interlanguage link, but the
searching will always be in one language until changed in the preference.
Back when the feedback mailing list was active this was one of the most
requrested features, and I personally strongly support it.
At the very least, searching must work in the language of the currently
displayed article, because seeing content in one language and searching in
another is badly confusing.
Better yet, there should be a way to define several "favorite languages" in
which the user is interested, and to show search results from all of them.
Any chance of that happening soon?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi,
A friendly reminder: please add all new translatable messages to the source
and commit them to Gerrit as early as possible, so that translators will
get a chance to translate them before betas are released.
In the world or Wikimedia / translatewiki localization we strongly believe
that releasing translatable strings as early as possible makes the whole
process of translating and testing much more efficient and prevents bugs
such as
https://bugzilla.wikimedia.org/show_bug.cgi?id=72607
Thank you! :)
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Just throwing this out there:
Would it be possible to have a script that crawls through images on
Commons, detects faces in the images, and embeds the x,y position of the
face(s) into the File page of the image (or into the Exif data of the
image) (and makes this information available via the API)?
For a little context -- in our mobile apps, we'll be featuring images
related to the article that the user is browsing; however, the way that
we're cropping the images sometimes has the side effect of cropping out the
face of the subject (when the face is far from the center of the image).
Even though we can do face detection locally on the user's device, it can
be a bit slow and a bit intensive. It would be great if this task was
offloaded, and the face position was returned right along with the image
itself...
-Dmitry
