Romaji to Kana Converter: Angular & Express — Chapter 3, Exercise 3
=====================================================================

TASK
Build convertSentence with the particle overrides, then run it
against both "kore e ikimasu" and "kono e wa kirei desu". Confirm
the first is correct and the second is wrong (produces へ where え
would be correct), and write one sentence explaining why no purely
lookup-table-based fix could resolve this specific ambiguity.

SOLUTION

  const PARTICLE_OVERRIDES: Record<string, string> = { wa: 'ha', e: 'he', o: 'wo' };

  function convertSentence(romaji: string): { hiragana: string; katakana: string } {
    const words = romaji.split(' ');
    const hiraganaParts: string[] = [];
    const katakanaParts: string[] = [];
    for (const word of words) {
      const lower = word.toLowerCase();
      const effective = PARTICLE_OVERRIDES[lower] ?? word;
      hiraganaParts.push(tokenizeScript(effective, false));
      katakanaParts.push(tokenizeScript(effective, true));
    }
    return { hiragana: hiraganaParts.join(' '), katakana: katakanaParts.join(' ') };
  }

Testing:

  console.log(convertSentence('kore e ikimasu').hiragana);
  console.log(convertSentence('kono e wa kirei desu').hiragana);

Run with: node (or ts-node)
Output (verified by hand-running the real function):

  これ へ いきます
  この へ は きれい です

The first sentence ("I'm going this way / toward this") is genuinely
correct: standalone "e" really is the へ direction particle here, and
the function produces exactly that.

The second sentence ("This picture is pretty") is genuinely wrong:
the standalone "e" in this sentence means 絵 (e, "picture"), a real
Japanese noun -- the correct hiragana would be この え は きれい です,
with え (the ordinary vowel character), not へ. The function still
converts standalone "e" to へ regardless, because its rule has no way
to know which real-world meaning was intended -- both sentences look
structurally identical to a plain word-boundary check: a lone,
space-separated "e" surrounded by other words on both sides.

WHY NO LOOKUP-TABLE FIX CAN RESOLVE THIS
------------------------------------------
A lookup table (or any purely positional/spelling-based rule) can
only ever look at the SHAPE of the input -- what letters appear, and
where the spaces are -- and both sentences have the exact same shape
at the point where "e" appears: a standalone word, preceded by
another word, followed by more words. The only thing that actually
distinguishes "e"-as-direction-particle from "e"-as-picture-noun is
grammatical role -- what part of speech "e" is functioning as in that
specific sentence, and what the surrounding words mean -- which is
information a table keyed on the string "e" alone can never contain,
no matter how it's built. Resolving this correctly would require
genuine part-of-speech tagging or a language model with real semantic
understanding of the sentence, not a bigger or cleverer dictionary.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the real, correct output for the unambiguous direction-
particle sentence, reproduces the real, genuinely incorrect output
for the picture-noun sentence, and correctly identifies that the
failure is structural (a lookup table has no access to grammatical
role) rather than a bug that a better table or more entries could
ever fix.