docs: fix what the second review round found in the usage.rst fixes

- The facade's initials() asks its vocabulary about particles as well
  as conjunctions, so a spliced "de la" gives no initials there (J. V.
  S. against the core's J. d. l. V. S.); "likewise asks only the
  conjunction question" was the first round's own error.
- "Two or more NAME words, a title not counting" was too narrow: a
  suffix word counts toward the two ("John Jr ma" reads the
  credential) and a nickname does not ('John "Jack" ma' keeps the
  surname). Now "two or more words, not counting a title or a
  nickname", in usage.rst and customize.rst alike.
- "So are particles:" read as "particles are something the parse
  records"; now "Particles are a second exception:".
- "Two more by the script they are written in" was wrong for form 7,
  which the divider carries, not the script; now "by how they are
  written".
- Rewraps two hand-wrapped customize.rst passages left uneven.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Author: derek73

docs/customize.rst

@@ -300,9 +300,9 @@ The full reading of a bare marked acronym, in order:
   the family name even WITH words to spare (``"John Smith Ma"``).
 - **No signal** — all lowercase in a mixed-case name, or any spelling
   in a name written wholly in one case — falls back to the count: a
-  suffix with two or more name words before it, a title not counting
-  (``"John Smith ma"``), the
-  family name otherwise (``"JACK MA"``).
+  suffix with two or more words before it, not counting a title or a
+  nickname (``"John Smith ma"``), the family name otherwise
+  (``"JACK MA"``).
 - **After a comma** the count of name words before the comma decides
   FIRST, and the case is read only where the count leaves the word a
   name. ``"John Smith, Ba"`` reads suffix ``Ba`` on the count alone, and
@@ -578,8 +578,9 @@ Family-first name order
 ``name_order`` is the one most likely to matter for data that is not
 in Western order. Positional input is assigned in the order you
 declare — with the two vocabulary exceptions noted under
-:ref:`order-vocabulary-first` — so a name written family-first — Hungarian, here — parses as
-written instead of needing to be rearranged afterwards:
+:ref:`order-vocabulary-first` — so a name written family-first —
+Hungarian, here — parses as written instead of needing to be
+rearranged afterwards:
 
 .. doctest::
 

docs/usage.rst

@@ -32,8 +32,7 @@ Input shapes
 -------------
 
 Three arrangements are understood by default, two more when you
-declare a family-first order, and two more by the script they are
-written in.
+declare a family-first order, and two more by how they are written.
 
 Understood by default
 ~~~~~~~~~~~~~~~~~~~~~
@@ -914,8 +913,8 @@ Which reading a bare one gets depends on what the writing says:
 - **Any other cased spelling** that is not wholly lowercase leans to
   the surname, even with words to spare (``Jack Ma``, ``John Smith Ma``).
 - **No signal** — all lowercase, or a name written wholly in one
-  case — leaves it to the count: the credential with two or more name
-  words before it (a title does not count), the surname otherwise.
+  case — leaves it to the count: the credential with two or more words
+  before it, not counting a title or a nickname, the surname otherwise.
 
 Either way the choice is recorded:
 
@@ -1034,11 +1033,11 @@ honor, so each view falls back on what it can answer without one:
   capitals wherever the field is the suffix, so ``replace(suffix="mba")``
   repairs to ``MBA`` and ``suffix="vi"`` to ``VI``. A credential
   recognised only by its dotted shape is the exception, since the shape
-  is something the parse records. So are particles: whether a particle
-  is acting as one is a fact about the whole part, and no word of a
-  spliced field carries a reading to derive it from, so a family set to
-  ``de la`` stays lowercase where the same words parsed are repaired to
-  ``De La``.
+  is something the parse records. Particles are a second exception:
+  whether a particle is acting as one is a fact about the whole part,
+  and no word of a spliced field carries a reading to derive it from,
+  so a family set to ``de la`` stays lowercase where the same words
+  parsed are repaired to ``De La``.
 - :meth:`~nameparser.ParsedName.initials` takes no vocabulary at all,
   so every word of a spliced field contributes an initial.
 - ``family_particles`` and ``family_base`` are properties on the
@@ -1048,9 +1047,9 @@ honor, so each view falls back on what it can answer without one:
 
 Of the parsed name's own views, ``capitalized()`` is the only one
 handed a vocabulary. (The v1 :class:`~nameparser.parser.HumanName`
-facade's ``initials()`` is handed one too, and likewise asks it whether
-a spliced word is a conjunction; it is not a method of the parsed
-name.)
+facade's ``initials()`` is handed one too, and asks it whether a
+spliced word is a conjunction or a particle, so a spliced ``de la`` gives
+no initials there; it is not a method of the parsed name.)
 
 .. doctest::