Back to the journal

Your library is miscounting Persian reading time

Content libraries often count words with /[a-zA-Z]+/. For Persian text, the result is almost zero, with no error to warn you.

Parsa5436
1 min read

Every blog puts “5 min read” above a post. The number comes from a word counter, and nobody questions it. Until the text is Persian.

What we found in the source

While setting up this journal, we used Velite’s s.metadata(). Its documentation promises readingTime and wordCount, and it does return them. But the installed source tells us how:

var wordLength = (str) => {
  const reWord = /['’]?([a-zA-Z]+(?:['’]?[a-zA-Z]+)*)/g;
  const words = str.match(reWord) || [];
  return words.length;
};

The counter recognizes only a-zA-Z words. There is a separate path for Chinese, Japanese, and Korean, but Persian and Arabic fall into neither group. For a two-thousand-word Persian article, wordCount is almost zero and readingTime becomes one minute, every time.

The worst part is the silence. No error or warning appears. The incorrect number is rendered with complete confidence.

The fix, in three lines

Persian also separates words with whitespace. Counting whitespace-separated tokens gives us a practical reading-time estimate:

const plain = context().file.plain ?? '';
const words = plain.split(/\s+/u).filter(Boolean).length;
const minutes = Math.max(1, Math.round(words / WORDS_PER_MINUTE));

A small detail matters: the zero-width non-joiner (U+200C) in «می‌کنند» is not whitespace and does not match \s. The word therefore stays together, as it should.

The lesson

The documentation said what the function returned, not how it calculated it. When a feature touches a non-Latin script, the installed source is the final reference.

If you run a Persian blog, check the reading times. They may all say “1 min”.