vagrant now has a "zero" role:
$ vagrant enable-role zero
Also,JsonConfig has also received a role:
$ vagrant enable-role jsonconfig
Ping me if you have any questions.
We need proper support for plurals in some string translations on the
Wikipedia native mobile apps; I'm currently looking at the AndroidFFS
import/export module and trying to figure out how ready that is, and
looking into how to improve the AppleFFS import/export module for iOS/OSX
projects.
Android has native plural strings support allowing for a separate complete
string for each plural form. AndroidXmlFFS in Translate has some sort of
import/export conversion into something like
'{{PLURAL|one=foo|others=bar}}' in the messages exposed to translators, but
plurals are not used in the new Wikipedia Android app yet so I see no live
examples. There are a few plural strings in the Android version of the
Commons app we did last year, but those strings do not appear in any of the
localizations and I can't find them in TWN, so I'm worried that the import
of plural strings from the 'strings.xml' doesn't actually work.
Also, the format the AndroidXmlFFS module uses doesn't quite seem the same
as what MediaWiki uses ('{{PLURAL:$1|foo|bar}}'). Is that going to be
confusing for translators, or should we change it to look more like the
MediaWiki form? (Does this require mapping positional parameters to plural
form names, or are they always in a known order?)
iOS 7/OS X 10.9 also has a 'native' way of handling plurals which requires
a second '.stringdict' output file alongside the '.strings' file; or there
are CLDR-powered compatibility libraries like
https://github.com/Smartling/ios-i18n which embed multiple message
alternates in the main '.strings' file.
I could rig up an import/export filter similar to the Android one (or maybe
share the actual list<->parser function conversion code), but first I want
to check if it works and if it's what the translators expect to work
with...
-- brion
Juliusz suggested I email out details to mobile-l on the following.
The question arose during an Opera discussion today whether hiding the
Watchlist icon (which is the case on non-HTTPS supporting UX on Wikipedia
Zero) on mobile web in the page menubar (not the same as the flyout
"hamburger" menu) might make sense generally for <noscript> or lower JS
devices? The Watchlist star on the page menubar takes up a lot of space,
and as it's the only thing there at the moment (on en.m at least, icons
like Edit and Add Photo aren't shown), hiding that menubar icon would free
up some valuable screen real estate.
On <noscript> or lower JS devices (or browsers where RL suppresses JS due
typically to challenges around timing of Deferreds and the like), using the
Opera traffic as an example of such a browser, it seems like Watchlist
usage is sort of low (this is at 1% sampling resolution).
$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz |
grep 'proxy=Opera' | grep 'action=watch' | wc -l
3
In other words, it seems users make it to the point of using the feature,
but only about 300 times per day total. Meanwhile, the Watchlist start
takes up valuable screen real estate for every pageview.
The usage of the feature is about 1/10 of the Opera usage involving
submission of the login form (a prerequisite of watchlist usage).
$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz |
grep 'proxy=Opera' | grep -i 'Special:UserLogin' | grep 'POST' | wc -l
31
Which is about 1/10 of Opera usage of the login feature in any capacity
(GETting the form or POSTing the form)
$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz |
grep 'proxy=Opera' | grep -i 'Special:UserLogin' | wc -l
331
Which is maybe 1/270 of an oversimplified "pageview" metric on Opera Mini,
using text/html response types as a rough guide.
$ zcat /a/squid/archive/mobile/mobile-sampled-100.tsv.log-20140409.gz |
grep 'proxy=Opera' | grep 'text/html' | wc -l
89403
The relatively low usage of the Watchlist feature is probably symptomatic
of the multiscreen flow on such devices.
-Adam