Restructure the East Asian names section: background before behavior

Lead with how the names are built (order, unspaced writing, closed
surname sets), then the two automatic behaviors, then the boundaries
-- replacing the casual 'come out right' / 'a step further' framing
that assumed the reader already knew the conventions.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: derek73

docs/usage.rst

@@ -140,12 +140,22 @@ merging two, and is covered next.
 East Asian names
 -----------------
 
-A name written wholly in Han (Chinese and Japanese characters) or
-Hangul needs no configuration to come out right: the script settles the
-convention by itself, so those names read family-first by default.
-Chinese and Japanese differ in most things but not this one — both put
-the family name first in native script — so nothing has to guess which
-language it is looking at.
+How these names are built, first, because the parsing rules follow
+from it. A Chinese, Japanese, or Korean name written in its own script
+puts the family name first: 毛泽东 is MAO Zedong, 山田太郎 is YAMADA
+Taro, 김민준 is KIM Minjun. The family name is short — one Han
+character or one hangul syllable, occasionally two — and comes from a
+small closed set, while given names are open-ended. And in native
+writing the parts are usually not separated at all: the whole name is
+one unbroken run of characters. A parser therefore has two distinct
+jobs here: assign family and given to the right fields, and, when the
+name arrives as a single token, find the boundary inside it.
+
+Field assignment is automatic. A name written wholly in Han characters
+or hangul is assigned family-first, because every language written in
+those scripts orders names that way — Chinese and Japanese share
+little else, but they agree on this — so the assignment requires no
+knowledge of which language the name is in:
 
 .. doctest::
 
@@ -154,39 +164,47 @@ language it is looking at.
     >>> parse("山田 太郎").family
     '山田'
 
-Korean names go a step further, because they are usually written with
-no space in them at all. The census surname list ships as default
-vocabulary, so an unspaced hangul name is split into its two parts:
+Splitting an unspaced name is also automatic, but only for Korean.
+Hangul is written by exactly one language, and Korean family names are
+a closed set small enough to ship: the census surname list is part of
+the default vocabulary, and the longest listed surname at the start of
+an unspaced hangul token becomes the family name:
 
 .. doctest::
 
     >>> minjun = parse("김민준")
     >>> minjun.family, minjun.given
     ('김', '민준')
 
-That works out of the box because nothing but Korean is written in
-hangul. The same trick on Han characters would have to know Chinese
-from Japanese first — a Chinese surname list splits ``高橋一郎`` after
-``高``, wrecking an ordinary Japanese name — so unspaced *Chinese* is
-opt-in through the ``zh`` locale pack, and Japanese waits on a
-segmenter of its own (`#272
-<https://github.com/derek73/python-nameparser/issues/272>`_):
+The same split is not automatic for Han text, because there the script
+does not identify the language: 高橋一郎 is a Japanese name whose
+family name is 高橋, but 高 alone is a common Chinese surname, so a
+Chinese surname list would split it in the wrong place. Declaring the
+language is up to you. When you know the data is Chinese, apply the
+``zh`` locale pack; Japanese needs a dictionary-backed segmenter and
+is tracked as `#272
+<https://github.com/derek73/python-nameparser/issues/272>`_ — until
+then an unspaced Japanese name stays whole, in the family field per
+the assignment rule above:
 
 .. doctest::
 
     >>> from nameparser import locales, parser_for
     >>> parser_for(locales.ZH).parse("毛泽东").family
     '毛'
 
-A comma switches both behaviors off, on the reasoning ``name_order``
-already follows: someone who wrote one has said where the family name
-ends. When the vocabulary supported more than one split — ``남궁민수``
-is 남궁 + 민수 by the compound surname but 남 + 궁민수 by the
-single-syllable one — the longest match wins and the parse reports the
-choice as an ``AmbiguityKind.SEGMENTATION``, described under `When the
-parser had to guess`_; a name with only one possible split decided
-nothing and reports nothing. :doc:`customize` covers turning either
-behavior off.
+Three boundaries on all of the above. Romanized names ("Kim Min-jun")
+are Latin script and follow the ordinary positional rules — order
+genuinely varies in romanized data, so nothing script-based applies.
+A comma disables both behaviors, on the reasoning ``name_order``
+already follows: whoever wrote the comma has already said where the
+family name ends. And when an unspaced name has more than one
+vocabulary-supported split — ``남궁민수`` is 남궁 + 민수 by the
+two-syllable surname but 남 + 궁민수 by the single-syllable one — the
+longest surname wins and the parse records the decision as an
+``AmbiguityKind.SEGMENTATION``, described under `When the parser had
+to guess`_; a name with only one possible split reports nothing.
+:doc:`customize` covers turning either behavior off.
 
 Aggregate views
 ----------------