Page MenuHomePhabricator

Show full IPAs in the Android app article view
Closed, ResolvedPublic

Description

Per @RHo's blessing, the Android app may stop hiding IPAs and replacing them with a button, and can instead show the full IPA as the iOS app and the mobile web site do.

I've submitted patches in the various places required to accomplish this, but there are a few issues with the resulting presentation:

  1. The IPA text links to Help:IPA/{$lang} (maybe this is OK?)

2a. For RESTBase: Clicking the speaker icon loads a speaker thumbnail in the gallery activity rather than playing the audio file. (Also, it's redundant because we have a native pronunciation button next to the article title.)

2b. For mobileview: Clicking the speaker icon launches an "About this sound" preview that results in an error if followed.

  1. Clicking the "listen" text next to the icon opens the chooser for the user to choose an app to play the audio file.

How does the iOS app handle these issues? Are they blockers?

Patches:
https://gerrit.wikimedia.org/r/#/c/419423/ (MobileApp extension)
https://gerrit.wikimedia.org/r/#/c/419443/ (MCS)
https://gerrit.wikimedia.org/r/#/c/419430/ (Android app)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 14 2018, 5:55 PM
Mholloway updated the task description. (Show Details)Mar 14 2018, 9:01 PM
Mholloway updated the task description. (Show Details)
Mholloway updated the task description. (Show Details)Mar 14 2018, 9:03 PM
Mholloway updated the task description. (Show Details)Mar 15 2018, 7:39 PM

Change 419843 had a related patch set uploaded (by Mholloway; owner: Mholloway):
[mediawiki/extensions/MobileApp@master] Add snippet to hide (listen) parenthetical across platforms

https://gerrit.wikimedia.org/r/419843

Change 419845 had a related patch set uploaded (by Mholloway; owner: Mholloway):
[apps/android/wikipedia@master] Hide the (listen) parenthetical in IPA spans

https://gerrit.wikimedia.org/r/419845

Per email discussion, added a cross-platform CSS snippet to hide the (listen) parenthetical in IPA spans. Results:

RHo awarded a token.Mar 15 2018, 8:54 PM
Mholloway added a comment.EditedMar 19 2018, 5:19 PM

There's one complication I want to flag here, without having a great idea how to handle it just yet. MCS currently adds a style of "display: none" to the first part of the IPA span (before the semicolon) such that when the CSS to hide the entire span is removed from the app style bundle, the result still looks like this:

There's a patch in review to stop MCS from forcibly applying that style, but even after it's deployed, it won't immediately reach all pages stored in RESTBase, but will roll out gradually as they are edited and regenerated. In the meantime the content in the IPA span will look funny. In theory the Services team could forcibly regenerate all stored pages but in practice I suspect they'd hesitate to take that step over this issue, especially as we've got a lot of other stuff going on separately that's putting some load on the servers.

Is this an issue you can live with?

RHo added a comment.EditedMar 19 2018, 7:38 PM

hi @Mholloway - in the example the part that is hidden before the semi-colon is (/njuːˈziːlənd/ ( listen) which is the purpose of the pronunciation (pronounciation of the term immediate before the IPA), so this seems not ideal.

Is this a special case where there is a semi-colon after the actual IPA text only because there is an audio file or IPA with multiple languages? What gets hidden in an article where:

  • The entire IPA is shown before a semi-colon like in Eyjafjallajökull
  • There is a "( listen)" but no semi-colon like in Michigan

I guess I would be more willing to live with this temporarily depending on the extent of its weirdness...
Is there a way to detect whether a page is using the IPA template and regenerate only those pages?

Mholloway added a comment.EditedMar 19 2018, 8:05 PM

Yeah, it's actually pretty bad IMO. Eyjafjallajökull manages to escape unscathed but that seems like a fluke. (Note that the missing closing parenthesis is not an MCS content stripping issue but just a problem in the underlying page content.)

I think we could figure out which pages are using IPA templates and then construct page lists for regeneration based on that, but we'll have to discuss it with Services.

Based on some testing it looks like the issue is most readily apparent by far on English Wikipedia. Would you agree? Limiting regeneration to pages on a single wiki (albeit the largest one) would probably help our case here.

@Mholloway I think a single wiki would not be a problem. Enwki is by far the largest. A dump (regenerating) of all mobile-sections content on enwiki would take about 2-3 days.
I'm not convinced that other wikis would not have to be rerendered as well. It'll probably be similar to the summary roll-out. Services would run dump on the top 5 wikis, then we enable the ensure content type version filter some time later.

The private/page-lists/summary-test-pages.json file in the MCS repo has a bunch of example pages that do IPA stripping. There are a bunch of pages on eswiki. You might want to check them out, too.

Mholloway added a comment.EditedMar 19 2018, 10:41 PM

The current behavior won't change for users until https://gerrit.wikimedia.org/r/#/c/419430/ is merged in the app repo and the app is released with it. So long as we have a dump run by then we should be in good shape. It would be nice to have that happen soonish, though, so it's not blocking other work. We can get the dumps started as soon as https://gerrit.wikimedia.org/r/#/c/419443/ is merged and deployed and Services is willing.

@mobrovac @Pchelolo I recently deployed an MCS change (https://gerrit.wikimedia.org/r/#/c/419443/) that stops directly applying a display: none style to certain portions of IPA spans for the mobile-sections endpoints. Would it be possible to do a regeneration of mobile-sections and mobile-sections-lead sometime soon (this week, if possible) so that the IPA display change can be rolled out soon (and gracefully) on the app side?

Is it a breaking change that would require a content-type version bump and enabling a content-type enforcing filter?

@Pchelolo The content-type patch version was bumped in the patch. A content-type enforcing filter would be good if possible, but can wait until later if necessary as long as the top 5 wikis are updated.

Change 419843 merged by jenkins-bot:
[mediawiki/extensions/MobileApp@master] Add snippet to hide (listen) parenthetical across platforms

https://gerrit.wikimedia.org/r/419843

Change 419845 merged by jenkins-bot:
[apps/android/wikipedia@master] Hide the (listen) parenthetical in IPA spans

https://gerrit.wikimedia.org/r/419845

I would prefer to bump the content-type filter version rather than manually dumping the wikis, as that result in a more even increase of load.

LGTM testing on Nexus 5 (6.0.1) on v2.7.231-alpha-2018-04-05

Dbrant closed this task as Resolved.Apr 13 2018, 1:20 PM