Making a love calculator work in 11 languages: Unicode names, stable scores and locale routing in Next.js

LoveCalcs — Sun, 25 Oct 2026 21:52:02 +0000

A love calculator looks like the simplest app on the internet: two names in, a percentage out. We run one at LoveCalcs in 11 languages, and doing that properly turned out to have a few interesting edges. Here are the ones that needed most care, with the real code.

1. The same names must always give the same score

If two friends type the same names and get different results, the whole thing feels broken. So there is no randomness: the score is a pure function of the two names.

The main score is what we call the Affinity Quotient. It blends five sub-scores, each from 0 to 100: letter frequency similarity (L), a simplified phonetic match (P), how close the first letters are (S), vowel balance (B) and a numerology-style "destiny number" (N):

  // Apply weights and calculate final score
  // AQ_raw = 0.25·L + 0.20·P + 0.15·S + 0.15·B + 0.10·N + 15
  const rawScore = 0.25 * L + 0.20 * P + 0.15 * S + 0.15 * B + 0.10 * N + 15;

  // Clip to [0,100] and round to 1 decimal place
  const final = Math.round(Math.max(0, Math.min(100, rawScore)) * 10) / 10;

  return { S, L, P, N, B, final };

The weights add up to 0.85, so with the constant 15 a perfect match on every metric lands on exactly 100. Every sub-score is also symmetric: it uses an absolute difference, a cosine similarity or an edit distance. That means swapping the two names never changes the result.

There is also an older, simpler scorer that we kept as a fallback. It is a hash of the two normalised names:

function normalizeString(str: string): string {
  // Use Unicode-aware normalization and keep all Unicode letters
  return keepOnlyUnicodeLetters(normalizeUnicodeName(str));
}

export function hashNamesToScore(name1: string, name2: string): number {
  const str = normalizeString(name1) + normalizeString(name2);
  // Use Unicode-aware hashing
  const hash = hashUnicodeString(str);
  return hash % 101;
}

Using % 101 rather than % 100 is deliberate: it allows every result from 0 to 100, so a perfect 100% is possible.

Unlike the Affinity Quotient, this one is order-sensitive because it hashes a concatenation, so the lookup for special-case name pairs checks both orders.

2. Names are not ASCII

People type names in Arabic, Devanagari, Japanese, Chinese and Cyrillic as well as Latin. If you keep only a-z, every non-Latin name collapses to an empty string and every non-Latin couple gets the same score. So the input check accepts any Unicode letter or combining mark, plus spaces, hyphens and apostrophes, and both scorers then run every name through the same two steps:

export function normalizeUnicodeName(name: string): string {
  return name
    .trim()
    .toLowerCase()
    .normalize('NFKC'); // Use NFKC normalization for better Unicode compatibility
}

// ...

export function keepOnlyUnicodeLetters(name: string): string {
  // Keep Unicode letters (\p{L}) and combining marks (\p{M})
  // Combining marks are essential for proper rendering of many scripts
  return name.replace(/[^\p{L}\p{M}]/gu, '');
}

Why NFKC and not NFC? Both forms fix canonical equivalence: "é" typed as the single code point U+00E9 and "e" followed by the combining accent U+0301 become the same string. NFKC also folds compatibility characters. Full-width Latin letters, which Japanese and Chinese input methods can produce, become ordinary Latin letters. Half-width katakana become standard katakana, and ligatures such as "ﬁ" become two letters. Each is the same name typed on a different keyboard.

What \p{L}\p{M} keeps. \p{L} is every letter in every script: Latin, Cyrillic, Arabic, Devanagari, CJK ideographs, hiragana and katakana. It even covers the katakana long vowel mark "ー", which Unicode classes as a modifier letter. \p{M} keeps combining marks, such as Devanagari vowel signs and Arabic vowel marks. Strip those and you change the name. Everything else goes: spaces, hyphens, apostrophes, digits, punctuation and emoji. So a hyphenated double name scores the same as the same name written with a space.

The u flag matters. Without it, \p{L} is not a Unicode property escape at all.

Count characters, not code units. .length counts UTF-16 code units, so most of the scoring code walks names with Array.from(name), which splits by code point.

3. A 32-bit hash that agrees with itself everywhere

The scoring runs in the browser, but the functions are plain TypeScript with no DOM or Node dependencies. The fallback hash is the classic multiply-by-31 string hash:

export function hashUnicodeString(str: string): number {
  let hash = 0;
  const chars = Array.from(str); // Handle multi-byte Unicode

  for (let i = 0; i < chars.length; i++) {
    hash = chars[i].charCodeAt(0) + ((hash << 5) - hash);
    hash = hash & hash; // Convert to 32bit integer
  }

  return Math.abs(hash);
}

Shifting left by five bits and subtracting the original value is the same as multiplying by 31. The reason this is stable across every browser and Node is that JavaScript's bitwise operators are defined in the language spec to convert their operands to signed 32-bit integers. So << and & hash wrap overflow in exactly the same way in every engine, and the intermediate values stay well inside the range where JavaScript numbers hold integers exactly. Math.abs then makes the result non-negative before the % 101.

The case folding is stable for a similar reason. toLowerCase() uses Unicode's default case mapping, not the user's locale, so a browser set to Turkish produces the same result as a server in a data centre. toLocaleLowerCase() would not.

One caveat if you adapt it: charCodeAt(0) reads a single UTF-16 code unit, so for characters outside the Basic Multilingual Plane it sees only the first half of the surrogate pair. That is still deterministic, but codePointAt(0) would tell them apart.

4. One codebase, 11 locales, predictable URLs

Every tool exists in English, Spanish, French, German, Italian, Portuguese, Russian, Chinese, Japanese, Arabic and Hindi, and the middleware, layout and sitemap all import one shared locales array. We use the Next.js App Router with a [locale] segment and the next-intl middleware:

export default createMiddleware({
  // A list of all locales that are supported
  locales,

  // Used when no locale matches
  defaultLocale: 'en',

  // Disable automatic locale detection to always default to English
  localeDetection: false,

  // Never use locale prefix for English, always for other languages
  localePrefix: {
    mode: 'as-needed',
    prefixes: {
      'en': ''
    }
  }
});

With as-needed and an empty English prefix, English lives at the root (/love-calculator) and every other language has a prefix, as with the Japanese version of the love calculator. A request for an /en/ URL redirects to the unprefixed one, so each page has exactly one English address.

Turning localeDetection off means nobody is redirected based on their browser's language or a cookie. The URL alone decides the language. That keeps behaviour predictable: a shared link opens in the language the sender saw, and crawlers get the same content as people.

The middleware's matcher skips API routes, Next.js internals and any path containing a dot, which is what lets files such as robots.txt and ads.txt be served as they are rather than treated as locale paths. Below it, the [locale] layout pre-renders one version per language with generateStaticParams, calls notFound() for anything not in the list and sets <html lang> to the current locale.

5. A page that changes daily, without rendering on every request

The home page and the calculator page show a Daily Love Insight (a tip, a fact and a quote) that rotates each day in every language. Rendering per request would be wasteful; a fully static build would freeze it. Incremental Static Regeneration sits in between:

// Regenerate at most hourly so the date-based Daily Love Insight rotates each
// day while pages stay statically cached (fast) the rest of the time.
export const revalidate = 3600;

The insight is chosen from the number of whole UTC days since the Unix epoch. Using UTC rather than local time keeps the server render and the browser in agreement. That number seeds a deterministic shuffle, so every render on the same day picks the same items and nothing repeats until the whole pool has been shown. The pick happens on the server and is passed down as props, so crawlers read the same HTML that the browser hydrates. The sitemaps use the same hourly revalidate, so their dates move forward with the content.

Testing tips

Use names in at least three scripts from day one, including one with combining marks (Hindi is a good choice) and one from a script with no upper and lower case (Japanese or Chinese).
Type the same accented name two ways, precomposed and with a combining accent, and check that the scores match. That is NFKC doing its job.
Swap the order of the names. With a symmetric scorer the result must not change.
Run the pure functions in Node too, and compare with what the browser shows.

Takeaway

Decide what "the same input" means before you score anything. The normalisation is the real logic; the maths on top is a detail.

To see it working, try the free love calculator that works with any script. It needs no sign-up, and the same two names will give the same score every time.

DEV Community: LoveCalcs