[WikimediaMobile] Using jsbeautify in MobileFrontend
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] translatable messages in betas
On 17 November 2014 10:39, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: I hope that Niklas or Siebrand don't hit me with a stick now, but I'd say that when we are talking about less then a dozen of messages, as in this case, then maybe you could merge just the messages separately to give them a chance to get translated, and let the actual code wait in whatever state that is good for TestFlight? Are you sure this is a good idea? Firstly, we often iterate on the prose ourselves while it's in alpha, so if those changes were merged then we'd be asking translators to retranslate subtle changes to the strings over and over again while we perfect the prose in English. Secondly, we'd be introducing extra development overhead on our end because now we have to write a patch for the strings first, make subsequent patches depend on that one while it's waiting to get merged, amend the first patch with any changes we make, update the dependent patch, and so on. Overall, that sounds like rather a lot of work to make sure that messages are available in a lot of languages in alpha releases! Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] switching languages
Monte/Dan: Yes, this has been proposed for the Android app in https://bugzilla.wikimedia.org/show_bug.cgi?id=71136 and https://bugzilla.wikimedia.org/show_bug.cgi?id=34100. On Tue, Nov 18, 2014 at 11:06 AM, Dan Garry dga...@wikimedia.org wrote: Hey Amir, Thanks for the email! It's nice to know we have someone so dedicated to internationalisation involved in the app's development. :-) On 18 November 2014 04:03, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Is there any plan to make the app less monolingual? See https://bugzilla.wikimedia.org/show_bug.cgi?id=34100 Considering we support switching to every language Wikipedia out there, I think it is a bit hyperbolic to imply the app is overly monolingual. :-) Back when the feedback mailing list was active this was one of the most requrested features, and I personally strongly support it. We absolutely could handle language support better. However, that work needs to be balanced relative to our other priorities. Right now, what we're working on benefits every single person that uses the app. We're making search better so people can find what they need. We're improving the presentation of the content in articles so that it's more consistent and more beautiful. And we're working on giving people suggestions of what they can read next. Given that this work improves the app for everyone, it has to take priority right now. 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. The current way we do things is confusing, but I actually think what you're suggesting here is *more* confusing in the context of an app. On desktop or mobile web, the way you read an article in another language is to go to another website. The interface changes language (in most cases), the logo at the top right is in a different language, the URL is different, and so on. So, conceptually, it makes sense that search will function in a different language; you're on a different website! In the app, however, you're not actually going anywhere; conceptually, you're not loading a different app, it's the exact same app fetching content in a different language. I'm not convinced that choosing to read a specific article in another language, a feature which works on a page-by-page basis, should change an app-level setting and start searching in a different language. 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. If you've not already, please file a bug for this. It's something we can explore further down the line. However, for the reasons laid out above, our focus is on improving the overall reading experience for everyone. Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Using jsbeautify in MobileFrontend
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 jrob...@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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
