Blog: accept custom reading time options

🚀 Feature

I’m working on the reading-time library renovation, and I plan to add much more options than what are currently available. (e.g. different reading speeds for CJK and Latin languages) It would be cool if we can expose these options to the end users.

Have you read the Contributing Guidelines on issues?

Yes

Has this been requested on Canny?

No

Motivation

To make use of the customizability of reading-time—also, sometimes the default reading time is just not sensical enough.

API Design

A new plugin option readingTimeOptions which is directly passed to the readingTime function. Currently the options only include wordsPerMinute and wordBound, but there will be many more. cf https://github.com/ngryman/reading-time/pull/42#issuecomment-919900955

Have you tried building it?

No

[Josh-Cena]

So you would have to “guess” the locale based on content?

“Guess” the language, sort of. The locale doesn’t really matter. I write some articles that are almost 50/50 Chinese and English. After all, it’s just about the word-counting algorithm, which should really be consistent across locales.

How does the lib (or callback) know the reading speed difference if we don’t provide it per language?

You provide multiple options: CJKCharactersPerMinute, LatinWordsPerMinute, CyrillicWordsPerMinute, etc.

Do you have a similar use-case for enhancing the default reading time?

I just feel like the default reading time function is already very usable, and we just need to inject additional options. Otherwise, the user would need to require readingTime every time, and… that’s unnecessary IMO

[slorber]

Yes, and maybe they want to tweak the options on a per-doc basis as well—we can support that by passing front matter into the callback. No problem.

Yes, that was my idea 😉 custom frontmatter could be used to tweak that algo

I prefer to keep it as number, at least for the callback (we can do the translation in the plugin). We don’t want the user to bear too much implementation burden.

👍

For the callback that makes sense but maybe we should allow providing a frontMatter readingTime as a string as well? Probably overkill, we can add that later if there’s an use-case