Re: Best way to format a name string in Folks

[Chris Leonard <cjlhomeaddress gmail com>]

On Sat, Aug 4, 2012 at 9:34 AM, Gabor Kelemen <kelemeng gnome hu> wrote:
> Hi Laurent
>
> 2012-08-04 10:18 keltezéssel, Contzen Laurent írta:
>
>> Hello,
>>
>> I'm currently adding a new display-name property in FolksIndividual as
>> discussed in bug #651672
>> (https://bugzilla.gnome.org/show_bug.cgi?id=651672). One of the possible
>> values we'd like to set this value to would use the given_name and the
>> family_name of the contact. Currently, I'm simply doing
>>
>>      var name = structured_name.given_name + " "
>> + structured_name.family_name;
>>
>> which outputs a string containing exactly "$given_name $family_name".
>>
>> Is this the best way of doing this or should, for example, the string
>> format be translatable?
>>
>
> This should be translatable.
>
> For example, the standard name order in Hungarian is $family_name
> $given_name, so your solution would not work for my language and for a few
> more, see: http://en.wikipedia.org/wiki/Name_order#Name_order
>
> Probably "%s %s" with a comment about their meaning and how to switch the
> order is enough, like:
>
> Translators: first %s is the given name of the contact, the second %s is the
> family name. To change the order, use "%2$s %1$s"

I think if you are going to use variable names as Gabor suggests, I
would go beyond using the simplest string name token "%s".  With mor
ethan one such token in a translatable string is less than ideal,

I would suggest something like

%(givenname)s %(familityname)s.

Yes, it is true that this will inevitably result in some printf errors
when localizers mistakenly translate what is inside the parenthesis,
but these are easy to catch (pofilter printf flag) and easier to fix
(just change the variable name back to English).  I'm not convinced
that this format will result in any more errors than using the
simplest tokens and expecting localizers to add the proper numbering
as suggested by Gabor.

My own point of view on this is that I find it frustrating when
developers to ask a localizer to do a job that the glibc locale should
be capable of addressing all on it's own.  Translating Day and Month
names should be banned in PO files :-)

There is in fact an entire section in glibc locales called LC_NAME in
the glibc locale that has a field for Name format (name_fmt) as
described below.  My argument is that develoeprs should leverage the
information content of the glibc locale to the greatest extent
possible, that is after all the primary purpose of having glibc locale
files.

cjl
Sugar Labs Translation Team Coordinator

>From Claude Paroz's excellent Locale Helper web-app

http://lh.2xlibre.net/values/name_fmt/

LC_NAME

 Name format (name_fmt)

Define the appropriate representation of a person’s name and title.
The operand consists of a string, and can contain any combination of
characters and field descriptors. In addition, the string can contain
field descriptors defined below.

%f
    Family names.
%F
    Family names in uppercase.
%g
    First given name.
%G
    First given initial.
%l
    First given name with latin letters. In some cultures, eg on
Taiwan it is customary to also have a first name written with Latin
letters, although the rest of the name is written in another script.
%o
    Other shorter name, eg. "Bill".
%m
    Additional given names.
%M
    Initials for additional given names.
%p
    Profession.
%s
    Salutation, such as "Doctor"
%S
    Abbreviated salutation, such as "Mr." or "Dr."
%d
    Salutation, using the FDCC-sets conventions, with 1 for the
name_gen, 2 for name_mr, 3 for name_mrs, 4 for name_miss, 5 for
name_ms.
%t
    If the preceding field descriptor resulted in an empty string,
then the empty string, else a .

Each field descriptor may have an after the <%> to specify that the
information is taken from a Romanized version string of the entity. An
initial is any string, normally consisting of one letter and a
punctuation mark; the Dutch "IJ" is an example of a two character
initial.