Closed Bug 1106380 Opened 10 years ago Closed 9 years ago

Make average word length and reading speed localizable


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

Not set


(firefox36 disabled, firefox37 disabled, fennec+)

Tracking Status
firefox36 --- disabled
firefox37 --- disabled
fennec + ---


(Reporter: aryx, Unassigned)



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.
tracking-fennec: --- → ?
Blocks: 959297, readerv2
No longer blocks: 889351
See Also: → 1093172
Blocks: 889351
No longer blocks: 959297
tracking-fennec: ? → 36+
Depends on: 1110461
tracking-fennec: 36+ → ?
tracking-fennec: ? → +
As I noted in, 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.,


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).
Depends on: 1129242
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:

The implementation of said word counting on DOM distiller, the equivalent of RM in Chromium:

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.
Many thanks for the pointers!
We're not continuing to invest in the reading list, so let's not fix this.
Closed: 9 years ago
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.