1106380 - Make average word length and reading speed localizable

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: Reader View, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Bug 889351 implemented an approximate reading time for items on the reading list.

The average length of the words and the reading speed are hardcoded but should be localizable:

    1.33 +    private static final int AVERAGE_READING_SPEED = 250;
    1.34 +
    1.35 +    // Length of average word.
    1.36 +    private static final float AVERAGE_WORD_LENGTH = 5.1f;

The reading speed can also vary strong between people (e.g. one person reads twice as fast as someone else).

Getting input from CJK and other languages with more complex characters expressing more content would also be helpful.

Comment 1

[Richard Newman [:rnewman]]

As I noted in https://github.com/mozilla-services/readinglist/issues/3, there are two separate uses for something like a word count: accurately calculating and tracking scroll/read position (where the only thing that matters is consistency), and calculating an estimated reading time.

We'll definitely need the former. That is probably best addressed by using display-oriented concepts: either a character count or a word count (in the 'split on spaces and punctuation' sense).


The rails that this bug is on for the latter are -- 

  characters / avg_char_per_word / words_per_minute

but for ideographic languages this gets difficult.

So switch to characters / characters_per_minute?

That gets hairy when you have compound texts: what do you do for a blog post that's part Hiragana, part kanji, and part English quotes? Take a look at, e.g.,

  http://www.mozilla.jp/blog/entry/10439/

or

  http://googlejapan.blogspot.jp/2014/10/1-game-week-with-google-play.html

which both contain a good mix of Japanese scripts and English -- three different densities. Your effective reading speed will be shifted by the percentages that each text contains.


Kindle figures out your reading speed as you read. It has the luxury of doing so, because you're typically reading book-length works. It'll switch from "15%" to "20% -- 1 hour remaining" as it learns.


So a simpler approach for us might be: make a guess at layout and use a 'traffic light' model instead of 'X minutes': one screen (blog post), a few screens (news piece), lots of screens (essay).

Comment 2

[Richard Newman [:rnewman]]

Oh, and there are interesting parallels here with translation, which typically bills by the word -- so what's a word?

http://www.proz.com/forum/localization/229393-word_count_when_source_language_is_korean_chinese_japanese_arabic.html

http://www.proz.com/forum/business_issues/220408-how_to_count_source_words_in_an_asian_text_into_eng.html

Comment 3

[Wei-Yin Chen]

For reading speed estimation on pages with mixed languages, one easy approximation is to use space-delimited words as the baseline, and count characters for languages that don't use space to separate "words", specifically Chinese and Japanese. Hangul does us space, even though it's in the CJK group. Thai, Myanmar, Tibetan, and Lao might also need special handling, too.

More related descriptions on:
https://code.google.com/p/chromium/issues/detail?id=484750

The implementation of said word counting on DOM distiller, the equivalent of RM in Chromium:
https://github.com/chromium/dom-distiller/search?q=FullWordCounter

As for reading position, remembering which element is at the center, and also where the screen center is relative to the vertical percentage of that element might be enough.

The pinch-to-zoom implementation for Chrome on Android uses this logic to keep the same reading progress after zooming.
https://code.google.com/p/chromium/codesearch#chromium/src/components/dom_distiller/core/javascript/dom_distiller_viewer.js&q=pincher&type=cs&l=179

Comment 4

[Richard Newman [:rnewman]]

Many thanks for the pointers!

Comment 5

[:Margaret Leibovic]

We're not continuing to invest in the reading list, so let's not fix this.