Re: New article draft: Personal names around the world

It is a very nice article. I have a couple of suggestions/comments.

A. The implications for design are a bit buried at the end, when for a lot
of people that is the main focus. What I'd suggest is:

   1. Move the material before that to the end, under a heading like Details
   2. Preface the design section with a short intro, just enough to
   understand what the design section needs. Something short and sweet, like
   the following (but a bit expanded).

Across languages, names are complicated. For example, the given and family
name may be reversed; members of the same family may not share the same
family name; people may have multiple family names; and so on. For more
information and examples, see Details.

Design Implications

In this section, use subsubheaders for each issue that has a YOUR PROFILE
example in it, for clarity. Also add a subsubheader before "Be careful,
also, about assumptions built into algorithms that pull out the parts of a
name automatically.", something like Algorithmic Issues.

> *In some cases you want to identify part of a name, such as the family
name, so that you can sort a list of names alphabetically, contact them,
etc. Consider whether it would make sense to have an extra field where you
ask the user to enter the part of their name that you need to use for a
specific purpose.*

This is a bit tricky. In general, I agree with you. However, the example
doesn't work well. I supply my full name as "Dr. Mark E. Davis", and I give
you my family name "Davis" on a separate field as requested. But you will
still not sort correctly. The problem is that if you sort just those two
fields, you will end sorting my name among the Davis's, but then you won't
sort correctly by the first name. That is, if you sort first by the last
name, then by the full name, you'll get:

Dr. Mark E. Davis < John Davis < Rev. Aaron Davis

Good sorting would require at least 2 fields. You might make more explicit
mention also that correctly sorting Japanese names requires having a
separate "pronunciation" field.

> *try to avoid using the labels ‘first name’ and ‘last name’*, since these
can be confusing for people who normally write their family name followed by
given names.

Strictly speaking, there is no solution. If you use the label "Family" name,
that doesn't apply to people who don't have family names (those with just
patronymics). However, you end up having to go with what is most customary
for the language, and in English, "Family Name" is as good as we can do.

Also, the following seems misplaced.

> Bear in mind that names in some cultures can be quite a lot longer than
your own. Make input fields long enough to make it easy to enter long names,
and ensure that if the name is displayed on a web page later there is enough
space for it. Also avoid limiting the field size for names in your database.

 It is a general issue that applies to all forms. I realize you're using it
as a lead-in, but it would be better either at the top or bottom of this

> Other/given names

This is too vague. What does the form-writer want? For "Rocco ("Rocky")
Francis Marchegiano", does he want "Rocco, Rocky, Francis, Frank", just
"Rocky", just ....

Often what is just needed is what the computer will call "you". For example,
on Amazon, the web page will use "Mark" or "Mark’s" for me. What is really
wanted is a Nickname field, and it might be worth calling that out as a
prominent usage: a short name that will be used by the system to refer to
you, either to you yourself, or to other users of the system.
*Other issue.*
People who work in a different language than their native tongue often want
to have two forms of their names, so that people can find them under either
name. Example, "Claire Ho (賀靜蘭)". That works fine for the "just enter in
your full name". It doesn't work well when the name is split. It can also
run afoul of security checks (for cross-script spoofing). One recommendation
we've made is that different scripts be allowed if they are in () or().

> implications for character encoding
This title seems odd. It is not so much about character encoding as it is
about repertoire restrictions, and should be stated that way.

> If you are designing an English form you need to decide whether you are
expecting people to enter names in their own script or in an ASCII-only
transcription, or both. What people will type into the form will often
depend on whether the form and its page is in their language or not. If the
page is in their language, don’t be surprised to get back non-Latin or
accented Latin characters.

I would make this clearer, more like:

To deal with people's names correctly you need to handle non-ASCII
characters even in English, such as Zoë. There are some circumstances, such
as a log-in name, where you can't permit non-ASCII characters.

> If so, you may want to ask for a Latin transcription.
A Latin transcription may also include non-ASCII. Are you meaning this
section to refer to ASCII issues alone? The issue of asking for a Latin
transcription is not an "implication for character encoding", and would to
go better in the previous section.

You should also look over all of the problem cases that you discuss at the
start, and see if you are give clear guidance on how to deal with the
problem in your design section. For example, you mention that sorting in
some languages is done by given name. In the design section, you'd have in
the Algorithmic Issues a recommendation to allow users who sort names to be
able to pick whether to sort by given name or family name.


*— Il meglio è l’inimico del bene —*

On Mon, May 30, 2011 at 22:40, Richard Ishida <> wrote:

> Hi Martin,
> Thanks for your suggestions.
> On 30/05/2011 02:54, "Martin J. Dürst" wrote:
>> Hello Richard,
>> Just a few comments:
>> Background
>> "People who create web forms, databases, or ontologies in
>> English-speaking countries are often unaware how different people’s
>> names can be in other countries."
>> Why is this specific to English-speaking countries? It can easily happen
>> in any country. In some places, people may be aware of two or three
>> (rather than just one) convention, but they'll still just miss most of
>> the others.
> Thanks. Missed that. Was text from the original blog post, where i did call
> out English-speaking developers in particular.
>> "Don't forget to allow people to use hyphens, apostrophes, etc. in
>> names. Don't require names to be entered in upper case - this can be
>> difficult on a mobile device.": These two advices don't seem to be
>> related, better to take them apart. Re. upper case, why would anybody
>> want to force that? What exactly does it mean: All upper case, or just
>> partially upper case? All upper case is a bad idea because casing is
>> often part of the name.
> Both of these are based on comments Timbl made to me this year while we
> were travelling.  I added 'all' before 'upper case'.
> > Also, you should probably say something about
>> prefixes and suffixes (de,... in French, von in German, jr. in the
>> US,...).
> I added "Allow the user to enter a name with spaces, eg. to support
> prefixes and suffixes such as de in French, von in German, and Jnr. in
> American names.".
>> "ask the user to submit their name": to avoid gender complications
>> without being ungrammatical, why not "ask the users to submit their names"
> It is grammatical English in the version that I speak.
>> "Name (in your alphabet)" doesn't work for scripts that are not alphabets.
> True in a strict sense. Can you think of a better way to put it for the
> general user?
>> "Herr Doktor Profesor Schmidt" would sound weird, "Herr Professor Doktor
>> Schmidt" is correct.
> Fixed. Thanks.
> Cheers,
> RI
>> Regards, Martin.
>> On 2011/05/29 19:54, Richard Ishida wrote:
>>> Folks,
>>> A while back we agreed in a telecon that it would be a good idea to
>>> convert my blog post on personal names to a w3c article. In my free time
>>> this weekend I have produced a first draft (that extends the blog
>>> post) at
>>> Please take a look at it with a view to whether we should send for wide
>>> review at this point.
>>> Thanks,
>>> RI
>>> PS: Addison, can we agenda+ this for the next meeting?
> --
> Richard Ishida
> Internationalization Activity Lead
> W3C (World Wide Web Consortium)

Received on Tuesday, 31 May 2011 23:00:47 UTC