I propose we remove the Wikimedia Commons app from the store.
Clearly there is no time available to work on it, there is no one maintaining it or following up on the problems that have been reported since 2013.
Yann is just brining it up on wikimedia-l and I think that it is bad to have an app out there that no on is taking care of. So we should pull it and whoever wants to continue with it can release it under a name of this own.
DJ
Hi, just wanted to give people a heads up about language-sensitive
redirects on the m.wikipedia.org/ (and zero.wikipedia.org/) webroot:
https://www.mediawiki.org/wiki/Wikipedia_Zero/Accept-Language_Aware_Redirec…
Dan Foy, Maryana, and I spoke on this stuff, and we thought it would be
best to see how this works in Wikipedia Zero land, and then if it works
well, continue dialog for the mobile web Wikipedia webroot afterward for
the non-Wikipedia Zero use case.
Usually we don't like to vary the cache on Accept-Language, but this is one
place where we're exploring the concept. It's possible to try to figure out
the language prefix in Varnish, but for now we're trying this as a pure
MediaWiki thing.
-Adam
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
I've gotten some great review feedback from Gilles on the desktop-web
integration of my ogv.js JavaScript & Flash compatibility layers for Ogg
Theora/Vorbis media files -- thanks Gilles!
* libraries: https://gerrit.wikimedia.org/r/#/c/165477/
* desktop integration: https://gerrit.wikimedia.org/r/#/c/165478/
These are getting pretty close to ready to land, I think.
I would love to get some review on the mobile overlay I've whipped up as
well. This supports both native WebM playback (Android Chrome, Android
Firefox, Firefox OS) and ogv.js playback (iOS 7/8 Safari).
* mobile overlay: https://gerrit.wikimedia.org/r/#/c/165479/
* Live demo: https://ogvjs-testing.wmflabs.org/
A few open questions:
1) Is this the right way to do mobile overlay code? (It's basically a rip
of the existing photo viewer overlay in MobileFrontend, but lives in
TimedMediaHandler.) Is the overlay interface stable enough for other
extensions to use it for mobile-specific features? (I had to make updates
for object-model and template things that changed since this summer.)
2) Is the inline icon too huge/ugly here for audio files? Should it be
arranged differently, or display the player inline instead of as an overlay
for audio?
3) Should more controls be added to the overlay's bottom toolbar, such as
manual resolution selection or an 'Open in VLC' link to support HD playback
on iOS?
4) Should we autoplay when opening the overlay, or require a second tap?
5) How should we handle devices with no native playback that are either too
slow (iOS 6 Safari) or lack necessary features needed for the player
(Windows Phone)?
Current known bugs in the mobile overlay:
* CPU speed check not yet integrated to force to lowest resolution for old
iPhones/iPads (this exists on the desktop integration, just needs to be
moved to common code)
* autoplay doesn't seem to work with native playback right now
-- brion
Hey guys!
So it seems like we don't use a linter on the iOS side of things. On the
Android side, Jenkins runs Maven Checkstyle against all patches that touch
Java files and it's quite helpful. A quick search shows that there are
quite a few open source Objective C linters out there, like OCLint
<http://oclint.org/>.
Let's explore this a bit more and see if we can get something like this set
up on the iOS side to catch the silly little mistakes.
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Greetings,
As it is the last Thursday of the month, the Mobile Apps Team submitted [1]
its latest work to production. This month the majority of the work was
backend work.
On iOS, the primary user-facing change is that we redesigned the "Credits"
screen to instead by an "About the Wikipedia app" screen. On the back-end,
our network operations code, migrating from a home-baked solution to an
open source networking library called AFNetworking
<https://github.com/AFNetworking/AFNetworking>, which should increase
stability, reduce random crashes and freezes, and reduce the amount of time
we have to spend in the weeds of networking.
On Android, the primary user-facing change is that our app is now more in
line with Google's standards for the look and feel of Android apps. On the
back end, we transformed almost all of our Activities
<http://developer.android.com/reference/android/app/Activity.html> into
Fragments <http://developer.android.com/reference/android/app/Fragment.html>,
which allowed us to also transition away from our custom-baked
pseudoactionbar to using the actual ActionBar
<http://developer.android.com/guide/topics/ui/actionbar.html>, and is also
a requirement for the app to be featured in Google Play.
We're hoping that next month's releases will contain improvements to search
so that users can find what they need, and on Android we're also hoping to
ship improvements to the styling of the lead of articles so that it's more
consistent, usable, and beautiful.
Stay tuned for future updates!
Thanks,
Dan
[1]: As always, the discrepancy between iOS and Android here means that the
Android update is now live, and the iOS update will be at some point in the
future when Apple is done reviewing the update.
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Dear Android app users,
I just published a new beta release, which should be available through the
store in a couple of hours. Here are the changes:
* Search improvements:
** Tab for full text search ("Within articles")
** Full text search results have descriptions from wikidata.org if available
** Cache recent search terms (can be cleared from the menu)
** Fix issue where search icon was sometimes invisible in dark mode
* You can delete individual history entries
* Fix visibility of dismiss button in ToC tutorial
* Fix directionality of edit preview and hamburger icon for RTL languages
* Wikipedia Zero banner colors are customizable by carriers
* Crash fixes:
** Check for "internal error" when fetching styles from server
** Catch possible exception when clicking on privacy policy or Terms of Use
and no browser is installed
** Catch remaining cases of SecurityException
** Catch exception when app was opened from Facebook link
** Fix possible crash when fetching Edit token
** Fix intermittent NullPointerException in DrawerLayout
Please report any issues you find.
Enjoy,
Bernd
Hi!
A little tip about writing message documentation ("qqq"): When you are
writing this documentation for Android and iOS apps, you can easily link to
other messages from qqq by using the MediaWiki template {{msg-wikimedia}}.
The documentation is conveniently shown to translators at translatewiki.net,
where this template is available.
I used it to improve the documentation of the "A product of the Wikimedia
Foundation" message for the iOS app:
https://translatewiki.net/wiki/Wikimedia:Wikipedia-ios-about-product-of/qqqhttps://translatewiki.net/wiki/Wikimedia:Wikipedia-ios-about-wikimedia-foun…
These qqq messages will be automatically exported to Gerrit during the next
translatewiki.net sync, so nothing more needs to be done about them, but
you should use this template in the future when relevant.
Note that you need to add the "Wikipedia-ios-" or
"Wikipedia-android-strings-" prefixes.
You can also do a similar thing for messages in MediaWiki core and
extensions (such as MobileFrontend) using the {{msg-mw}} template.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
I know we just pushed it to stable but on hindsight I wish I fought
more against it and we didn't.
The code was supposed to remove the 300ms delay on certain devices for
clicking to make the device feel more responsive.
I would now like to propose we kill it.
It has rendered IE8 unusable as well as any device which supports both
touch events and mouse events (e.g. BlackBerry Bold 9900)
Modern browsers are abandoning this sort of code however.
ios8 [1] has no need for it, neither does Chrome mobile [2]
I've drafted a patch to remove this [3] but first I need your okay about that.
At very least we should punt it back to beta and make this code better.
Thoughts?
[1] https://github.com/ftlabs/fastclick/issues/262#issuecomment-56023175
[2] http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away
[3] https://gerrit.wikimedia.org/r/169582
Hallo together,
(i've added some of you already to the related bug report[1], but now this E-mail for information)
Nemo has started a bug report/request in bugzilla/site-requests[1] with the result of a RfC on itwiki (i interpreted "sondaggio" to be like an RfC in english wikipedia or a "Meinungsbild" in dewiki). There is already a change for it in mediawiki-config [2]. I'm happy to see the effort of itwiki community to help us to make editing without login better and get some more input for a limited testing phase on a big wikipedia version with the backup of the community.
This is just an information, that there is a bug and a change, but opinions are welcome :)
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=72541
[2] https://gerrit.wikimedia.org/r/#/c/168915/
Freundliche Grüße
Florian Schmidt