W3C home > Mailing lists > Public > www-international@w3.org > July to September 2011

Re: Draft for review: Personal names around the world

From: Richard Ishida <ishida@w3.org>
Date: Thu, 11 Aug 2011 22:25:57 +0100
Message-ID: <4E4448E5.1060904@w3.org>
CC: "www-international@w3.org" <www-international@w3.org>
Cindy, Mark, John, Kuro, Gunnar,

Thanks for your comments.  I included some additional text in the 
article for a number of things, including:

a. an extension to Multiple family names, including references to 
Brazilian names and maternal-paternal vs vice versa

b. a new section called Ambiguity in written forms, that discusses 
ideographic characters in Japanese and kana

c. various small additions to the lower part of the article.

I didn't feel it was appropriate to include in the article all of the 
supplementary information you provided, but I gathered it together at 
http://www.w3.org/International/wiki/Personal_names and pointed to it 
from the Further reading section of the article.


On 04/08/2011 05:10, Cindy Conlin wrote:
> Great job at capturing a lot of information in a very concise article.
> Here are my thoughts:
> 1.Mark suggested including some of the possible tasks a system must
> perform on names.  Here are some of the additional tasks the system I
> work on at the LDS Church performs on names:
> a.Combine the names of multiple individuals for display, such as a
> couple (e.g. “Barak and Michelle Obama”) or a family with children.
> (“Obama: Barak, Michelle, Malia, and Sasha”)
> b.Romanize names using transliteration software.  The ideal is for
> romanizations to be entered by users with the spelling they prefer, but
> in some cases this is not possible.  Sometimes our automated
> Romanization is used for name matching purposes (especially if we need
> to match names across scripts, like government terrorist watch list
> software must do), and at other times it is a starting point for a data
> entry user who will correct the spelling.
> c.Match names with legal documents, such as passports or government
> issued ID cards, which sometimes requires storing multiple variations of
> the name.
> d.Guess at how a person’s name may change upon marriage, based on
> locale-specific rules and the husband and wife’s names before marriage.
> This guess is used as a starting point for data entry users who then
> adjust the name based on the couple’s choices.
> 2.The “Given name and patronymic” section mentions “Other cultures where
> a person has one given name followed by a patronymic include parts of
> Southern India, Malaysia and Indonesia.”  Our data in these cultures has
> a large number of names that consist of a given name only, with no
> patronym.  Some of our less-enlightened software requires family names,
> which creates significant problems in these cultures, as users enter
> garbage data like “.” or “Mr.” in the family name just to escape the
> field.  (We may want to mention the problem of required fields somewhere
> in the “Implications for field design” section.  IMHO, the only name
> field that can be required is a given name, because that is the only
> name that is consistently used across cultures).
> 3.The “Multiple family names” section mentions “Spanish-speaking people
> will commonly have two family names.”  This is also common in
> Portuguese-speaking cultures.  It’s also possible to have up to four
> family names in the name—sometimes people inherit names from all four
> grandparents; other times they have additional names from spouses.
> 4.The “Variant word forms” section gives an example of the
> gender-specific family names in Russia.  Just wanted to mention that
> when you display the family name in a context where you are showing
> multiple people (such as in a display of a couple or a family including
> children), you need to display the plural ending of the family name,
> which can be different from both the masculine and feminine versions.
> 5.The “Inheritance of names” section has a paragraph about Spanish
> names.  It may be helpful to note that Spanish and Portuguese cultures
> vary in the order in which they position the maternal and paternal
> family names.  In general, most of the data I’ve observed has Portuguese
> cultures ordering the names “Maternal Paternal” and Spanish cultures
> ordering the names “Paternal Maternal”, but I understand that this
> varies even within Spanish cultures.
> 6.The 4^th paragraph in the “Strategies for splitting up names” section
> has a typo—“sent” should be “send” in the sentence “Or perhaps it's
> because you want to sent them emails…”
> 7.The “Strategies for splitting up names” has a paragraph stating that
> if you want to sort Japanese names, you need an extra field to type how
> their name is pronounced.  We’ve found that it’s been helpful to store a
> Kana version of names not only for sorting purposes, but also because
> a.The kana name is useful input into Romanization software.
> b.The kana name is helpful to other Japanese readers of the name who may
> not be familiar with the correct pronunciation.  For example, to
> facilitate church members pronouncing each other’s names, we show the
> kana in parentheses after the Kanji name on our congregation lists.  I’m
> not sure if this is a big help or only a little one—Richard, with your
> Japanese experience you’re in a better position than I am to comment on
> this.  If you believe facilitating the pronunciation of the name to
> other Japanese readers is a valid reason a system should store a kana
> name, we may want to include it in the list of questions in after the
> statement “The decision about which is most appropriate will depend to
> some extent on what you are collecting people’s names for, and how you
> intend to use them.“
> 8.The “Implications for character support” section doesn’t mention
> Japanese kana names, but I think it would be very helpful to readers to
> include it there, so readers understand that to fully support Japanese,
> they may actually need THREE script versions of the names.  That section
> currently has an image showing two name fields: Name (in your alphabet)
> and Name (Latin alphabet)—it may be helpful to have an additional image
> showing three name fields:  Name (Kanji), Name (Kana) and Name (Latin
> alphabet).
> *From:*www-international-request@w3.org
> [mailto:www-international-request@w3.org] *On Behalf Of *Mark Davis ?
> *Sent:* Wednesday, August 03, 2011 6:24 PM
> *To:* ishida@w3.org
> *Cc:* www-international@w3.org
> *Subject:* Re: Draft for review: Personal names around the world
>  > http://www.w3.org/International/questions/qa-personal-names
> The overview of personal names is very useful. However, I think there
> are some problems with the guidance given in the section "implications
> for field design".
> Look at this from a functional approach. A particular system may need to
> do some of the following tasks:
>  1. Have a short, personal name, eg "Welcome back, Mark"
>  2. Have a relatively unique, informal name, eg "Mark Davis commented on
>     your post".
>  3. Have a name to use in UIs that have "Sort by: Family Name" (meaning:
>     or best equivalent)
>  4. Have a name to use in UIs that have "Sort by: Given Name" (meaning:
>     or best equivalent)
>  5. Have a name for more formal contexts, such as a postal mailing, eg
>     "Dr. Mark Davis"
>  6. Etc.
> I think having more such tasks listed in the document would help to
> motivate (and test) the recommendations give in the section
> "implications for field design".
> In particular, I think systems are often driven to asking for "Family
> Name" and "Given Name" because they can (or think they can) generate
> each of the forms needed for at least the tasks #1-#4. There is some
> tension, because you don't want to have a UI that asks for 8 different
> forms of a person's name; people find that onerous!
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information.
> Any unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.

Richard Ishida
Internationalization Activity Lead
W3C (World Wide Web Consortium)


Register for the W3C MultilingualWeb Workshop!
Limerick, 21-22 September 2011
Received on Thursday, 11 August 2011 21:26:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:32 UTC