Re: [BZ#16078] [COMMITTED] New-locale-for-anp_IN

[Marko Myllynen <myllynen at redhat dot com>]

Hi,

On 2013-10-30 14:47, Chris Leonard wrote:
> On Wed, Oct 30, 2013 at 6:59 AM, Marko Myllynen <myllynen@redhat.com> wrote:
>> On 2013-10-29 14:34, Chris Leonard wrote:
>>> +
>>> +LC_IDENTIFICATION
>>> +title      "Angika language locale for India"
>>> +source     ""
>>> +address    ""
>>> +contact    ""
>>> +email      "bhashaghar@googlegroups.com"
>>> +tel        ""
>>> +fax        ""
>>> +language   "Angika"
>>> +territory  "India"
>>> +revision   "1.0"
>>> +date       "2013-10-24"
>>> +%
>>> +category  "anp_IN:2013";LC_IDENTIFICATION
>>> +category  "anp_IN:2013";LC_CTYPE
>>> +category  "anp_IN:2013";LC_COLLATE
>>> +category  "anp_IN:2013";LC_TIME
>>> +category  "anp_IN:2013";LC_NUMERIC
>>> +category  "anp_IN:2013";LC_MONETARY
>>> +category  "anp_IN:2013";LC_MESSAGES
>>> +category  "anp_IN:2013";LC_PAPER
>>> +category  "anp_IN:2013";LC_NAME
>>> +category  "anp_IN:2013";LC_ADDRESS
>>> +category  "anp_IN:2013";LC_TELEPHONE
>>> +
>>> +END LC_IDENTIFICATION
>>
>> LC_MEASUREMENT is missing.
> 
> I don't think so, please look again at the bottom of the locale file.

no, it is missing from the LC_IDENTIFICATION category quoted above.

>> Should country_isbn included as well?
> 
> country_ISBN is subject to some uncertainty as to whether it should be
> simple numeric or converted to Unicode points.  I'd like a definitive
> answer to that question before adding more country_isbn entries.  I
> have been passing through adding language fileds to LC_ADDRESS and
> have left country_isbn for later consideration.

I've used de_DE as reference in cases like this since it's written by
the same author as most of the i18n code in glibc but now that you
mention it, locale/programs/ld-address.c actually contains the following:

/* The real definition of the struct for the LC_ADDRESS locale.  */
struct locale_address_t
{
  const char *postal_fmt;
  const char *country_name;
  const char *country_post;
  const char *country_ab2;
  const char *country_ab3;
  uint32_t country_num;
  const char *country_car;
  const char *country_isbn;
  const char *lang_name;
  const char *lang_ab;
  const char *lang_term;
  const char *lang_lib;
};

So perhaps it would actually be better to use Unicode points instead of
simple numbers after all.

Cheers,

-- 
Marko Myllynen