[v2] localedata: CLDRv29: update LC_ADDRESS.country_num values
Commit Message
This updates a few locales based on CLDR v29 data.
Add missing fields:
as_IN: changing to 356
dv_MV: changing to 462
kk_KZ: changing to 398
my_MM: changing to 104
rw_RW: changing to 646
tt_RU: changing to 643
Update ones that are wrong:
dz_BT: changing BHU to 064
en_PH: changing 360 to 608
km_KH: changing 418 to 116
ky_KG: changing 643 to 417
tr_CY: changing 792 to 196
wo_SN: changing 450 to 686
As a result of fixing these, I had to update country_ab[23]:
dz_BT: changing BHU to BTN
en_PH: changing ID/IDN to PH/PHL
km_KH: changing LA/LAO to KH/KHM
ky_KG: changing KY/KYR to KG/KGZ
tr_CY: changing TR/TUR to CY/CYP
wo_SN: changing MG/MDG to SN/SEN
Pad with leading zeros to match the standard and other locales:
ber_DZ: changing 12 to 012
ca_AD: changing 20 to 020
en_AG: changing 28 to 028
hy_AM: changing 51 to 051
li_BE: changing 56 to 056
wa_BE: changing 56 to 056
I hand checked the first two sets against ISO 3166-1 directly.
---
localedata/ChangeLog | 21 +++++++++++++++++++++
localedata/locales/as_IN | 1 +
localedata/locales/ber_DZ | 2 +-
localedata/locales/ca_AD | 2 +-
localedata/locales/dv_MV | 1 +
localedata/locales/dz_BT | 6 +++---
localedata/locales/en_AG | 2 +-
localedata/locales/en_PH | 6 +++---
localedata/locales/hy_AM | 2 +-
localedata/locales/kk_KZ | 1 +
localedata/locales/km_KH | 6 +++---
localedata/locales/ky_KG | 6 +++---
localedata/locales/li_BE | 2 +-
localedata/locales/my_MM | 1 +
localedata/locales/rw_RW | 1 +
localedata/locales/tr_CY | 8 +++-----
localedata/locales/tt_RU | 1 +
localedata/locales/wa_BE | 2 +-
localedata/locales/wo_SN | 6 +++---
19 files changed, 51 insertions(+), 26 deletions(-)
Comments
Mike Frysinger <vapier@gentoo.org> writes:
> --- a/localedata/locales/ca_AD
> +++ b/localedata/locales/ca_AD
> @@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
> <U004E><U0025><U0063><U0025><U004E>"
> country_ab2 "<U0041><U0044>"
> country_ab3 "<U0041><U004E><U0044>"
> -country_num 20
> +country_num 020
This is a plain number so the leading zero is not significant.
Andreas.
On 12 Apr 2016 09:53, Andreas Schwab wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > --- a/localedata/locales/ca_AD
> > +++ b/localedata/locales/ca_AD
> > @@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
> > <U004E><U0025><U0063><U0025><U004E>"
> > country_ab2 "<U0041><U0044>"
> > country_ab3 "<U0041><U004E><U0044>"
> > -country_num 20
> > +country_num 020
>
> This is a plain number so the leading zero is not significant.
i documented this in the commit message
-mike
Mike Frysinger <vapier@gentoo.org> writes:
> On 12 Apr 2016 09:53, Andreas Schwab wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>> > --- a/localedata/locales/ca_AD
>> > +++ b/localedata/locales/ca_AD
>> > @@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
>> > <U004E><U0025><U0063><U0025><U004E>"
>> > country_ab2 "<U0041><U0044>"
>> > country_ab3 "<U0041><U004E><U0044>"
>> > -country_num 20
>> > +country_num 020
>>
>> This is a plain number so the leading zero is not significant.
>
> i documented this in the commit message
That doesn't make it correct.
Andreas.
On 12 Apr 2016 10:05, Andreas Schwab wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > On 12 Apr 2016 09:53, Andreas Schwab wrote:
> >> Mike Frysinger <vapier@gentoo.org> writes:
> >> > --- a/localedata/locales/ca_AD
> >> > +++ b/localedata/locales/ca_AD
> >> > @@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
> >> > <U004E><U0025><U0063><U0025><U004E>"
> >> > country_ab2 "<U0041><U0044>"
> >> > country_ab3 "<U0041><U004E><U0044>"
> >> > -country_num 20
> >> > +country_num 020
> >>
> >> This is a plain number so the leading zero is not significant.
> >
> > i documented this in the commit message
>
> That doesn't make it correct.
nor does it make it incorrect. i've provided justification for the
change at this point.
-mike
Mike Frysinger <vapier@gentoo.org> writes:
> On 12 Apr 2016 10:05, Andreas Schwab wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>> > On 12 Apr 2016 09:53, Andreas Schwab wrote:
>> >> Mike Frysinger <vapier@gentoo.org> writes:
>> >> > --- a/localedata/locales/ca_AD
>> >> > +++ b/localedata/locales/ca_AD
>> >> > @@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
>> >> > <U004E><U0025><U0063><U0025><U004E>"
>> >> > country_ab2 "<U0041><U0044>"
>> >> > country_ab3 "<U0041><U004E><U0044>"
>> >> > -country_num 20
>> >> > +country_num 020
>> >>
>> >> This is a plain number so the leading zero is not significant.
>> >
>> > i documented this in the commit message
>>
>> That doesn't make it correct.
>
> nor does it make it incorrect. i've provided justification for the
> change at this point.
"Add leading 0 prefix" is not justification.
Andreas.
On 12 Apr 2016 10:17, Andreas Schwab wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > On 12 Apr 2016 10:05, Andreas Schwab wrote:
> >> Mike Frysinger <vapier@gentoo.org> writes:
> >> > On 12 Apr 2016 09:53, Andreas Schwab wrote:
> >> >> Mike Frysinger <vapier@gentoo.org> writes:
> >> >> > --- a/localedata/locales/ca_AD
> >> >> > +++ b/localedata/locales/ca_AD
> >> >> > @@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
> >> >> > <U004E><U0025><U0063><U0025><U004E>"
> >> >> > country_ab2 "<U0041><U0044>"
> >> >> > country_ab3 "<U0041><U004E><U0044>"
> >> >> > -country_num 20
> >> >> > +country_num 020
> >> >>
> >> >> This is a plain number so the leading zero is not significant.
> >> >
> >> > i documented this in the commit message
> >>
> >> That doesn't make it correct.
> >
> > nor does it make it incorrect. i've provided justification for the
> > change at this point.
>
> "Add leading 0 prefix" is not justification.
like i already said, read the *commit message*. you're quoting the
ChangeLog which does *not* include justification. ChangeLog's are
dumb files that only list *what* changed, not *why*.
-mike
Mike Frysinger <vapier@gentoo.org> writes:
> On 12 Apr 2016 10:17, Andreas Schwab wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>> > On 12 Apr 2016 10:05, Andreas Schwab wrote:
>> >> Mike Frysinger <vapier@gentoo.org> writes:
>> >> > On 12 Apr 2016 09:53, Andreas Schwab wrote:
>> >> >> Mike Frysinger <vapier@gentoo.org> writes:
>> >> >> > --- a/localedata/locales/ca_AD
>> >> >> > +++ b/localedata/locales/ca_AD
>> >> >> > @@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
>> >> >> > <U004E><U0025><U0063><U0025><U004E>"
>> >> >> > country_ab2 "<U0041><U0044>"
>> >> >> > country_ab3 "<U0041><U004E><U0044>"
>> >> >> > -country_num 20
>> >> >> > +country_num 020
>> >> >>
>> >> >> This is a plain number so the leading zero is not significant.
>> >> >
>> >> > i documented this in the commit message
>> >>
>> >> That doesn't make it correct.
>> >
>> > nor does it make it incorrect. i've provided justification for the
>> > change at this point.
>>
>> "Add leading 0 prefix" is not justification.
>
> like i already said, read the *commit message*.
I did. No justification.
Andreas.
Hi,
On 2016-04-12 11:30, Andreas Schwab wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
>> On 12 Apr 2016 10:17, Andreas Schwab wrote:
>>> Mike Frysinger <vapier@gentoo.org> writes:
>>>> On 12 Apr 2016 10:05, Andreas Schwab wrote:
>>>>> Mike Frysinger <vapier@gentoo.org> writes:
>>>>>> On 12 Apr 2016 09:53, Andreas Schwab wrote:
>>>>>>> Mike Frysinger <vapier@gentoo.org> writes:
>>>>>>>> --- a/localedata/locales/ca_AD
>>>>>>>> +++ b/localedata/locales/ca_AD
>>>>>>>> @@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
>>>>>>>> <U004E><U0025><U0063><U0025><U004E>"
>>>>>>>> country_ab2 "<U0041><U0044>"
>>>>>>>> country_ab3 "<U0041><U004E><U0044>"
>>>>>>>> -country_num 20
>>>>>>>> +country_num 020
>>>>>>>
>>>>>>> This is a plain number so the leading zero is not significant.
>>>>>>
>>>>>> i documented this in the commit message
>>>>>
>>>>> That doesn't make it correct.
>>>>
>>>> nor does it make it incorrect. i've provided justification for the
>>>> change at this point.
>>>
>>> "Add leading 0 prefix" is not justification.
>>
>> like i already said, read the *commit message*.
>
> I did. No justification.
Please reread it, there was justification.
Thanks,
Marko Myllynen <myllynen@redhat.com> writes:
> Hi,
>
> On 2016-04-12 11:30, Andreas Schwab wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>>> On 12 Apr 2016 10:17, Andreas Schwab wrote:
>>>> Mike Frysinger <vapier@gentoo.org> writes:
>>>>> On 12 Apr 2016 10:05, Andreas Schwab wrote:
>>>>>> Mike Frysinger <vapier@gentoo.org> writes:
>>>>>>> On 12 Apr 2016 09:53, Andreas Schwab wrote:
>>>>>>>> Mike Frysinger <vapier@gentoo.org> writes:
>>>>>>>>> --- a/localedata/locales/ca_AD
>>>>>>>>> +++ b/localedata/locales/ca_AD
>>>>>>>>> @@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
>>>>>>>>> <U004E><U0025><U0063><U0025><U004E>"
>>>>>>>>> country_ab2 "<U0041><U0044>"
>>>>>>>>> country_ab3 "<U0041><U004E><U0044>"
>>>>>>>>> -country_num 20
>>>>>>>>> +country_num 020
>>>>>>>>
>>>>>>>> This is a plain number so the leading zero is not significant.
>>>>>>>
>>>>>>> i documented this in the commit message
>>>>>>
>>>>>> That doesn't make it correct.
>>>>>
>>>>> nor does it make it incorrect. i've provided justification for the
>>>>> change at this point.
>>>>
>>>> "Add leading 0 prefix" is not justification.
>>>
>>> like i already said, read the *commit message*.
>>
>> I did. No justification.
>
> Please reread it, there was justification.
"Other sources doing it wrong, too" is not a justification.
Andreas.
Andreas,
I'm not entirely sure I understand your objection, but I would like to
understand your point.
I don't have access to the full specification of ISO 3166-1
But if you go to this link:
https://www.iso.org/obp/ui/#search/code/
Selecting "Officially assigned codes" displays the numeric codes (with
leading zeros)
Also see here
http://unstats.un.org/unsd/methods/m49/m49alpha.htm
Leading zeros are pretty obviously in the 3166-1 representations that
I can see, and from fairly reliable reference sites, absent a copy of
the full specification.
Is it that you don't think ISO 3166-1 is the appropriate standard to follow?
Is it that you think that either the ISO-3166-1 codes (or some other
variant standard to be followed by glibc) should not have leading
zeros?
Is it that glibc does not implement their representation in a manner
that would capture the leading zero?
Is it that including the leading zero might lead to code failure of some sort?
I'd really like to understand what you think is not correct, what are
"other sources" getting wrong?
Regards,
cjl
On Tue, Apr 12, 2016 at 4:36 AM, Andreas Schwab <schwab@suse.de> wrote:
> Marko Myllynen <myllynen@redhat.com> writes:
>
>> Hi,
>>
>> On 2016-04-12 11:30, Andreas Schwab wrote:
>>> Mike Frysinger <vapier@gentoo.org> writes:
>>>> On 12 Apr 2016 10:17, Andreas Schwab wrote:
>>>>> Mike Frysinger <vapier@gentoo.org> writes:
>>>>>> On 12 Apr 2016 10:05, Andreas Schwab wrote:
>>>>>>> Mike Frysinger <vapier@gentoo.org> writes:
>>>>>>>> On 12 Apr 2016 09:53, Andreas Schwab wrote:
>>>>>>>>> Mike Frysinger <vapier@gentoo.org> writes:
>>>>>>>>>> --- a/localedata/locales/ca_AD
>>>>>>>>>> +++ b/localedata/locales/ca_AD
>>>>>>>>>> @@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
>>>>>>>>>> <U004E><U0025><U0063><U0025><U004E>"
>>>>>>>>>> country_ab2 "<U0041><U0044>"
>>>>>>>>>> country_ab3 "<U0041><U004E><U0044>"
>>>>>>>>>> -country_num 20
>>>>>>>>>> +country_num 020
>>>>>>>>>
>>>>>>>>> This is a plain number so the leading zero is not significant.
>>>>>>>>
>>>>>>>> i documented this in the commit message
>>>>>>>
>>>>>>> That doesn't make it correct.
>>>>>>
>>>>>> nor does it make it incorrect. i've provided justification for the
>>>>>> change at this point.
>>>>>
>>>>> "Add leading 0 prefix" is not justification.
>>>>
>>>> like i already said, read the *commit message*.
>>>
>>> I did. No justification.
>>
>> Please reread it, there was justification.
>
> "Other sources doing it wrong, too" is not a justification.
>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
On 12 Apr 2016 10:36, Andreas Schwab wrote:
> Marko Myllynen <myllynen@redhat.com> writes:
> > On 2016-04-12 11:30, Andreas Schwab wrote:
> >> Mike Frysinger <vapier@gentoo.org> writes:
> >>> On 12 Apr 2016 10:17, Andreas Schwab wrote:
> >>>> Mike Frysinger <vapier@gentoo.org> writes:
> >>>>> On 12 Apr 2016 10:05, Andreas Schwab wrote:
> >>>>>> Mike Frysinger <vapier@gentoo.org> writes:
> >>>>>>> On 12 Apr 2016 09:53, Andreas Schwab wrote:
> >>>>>>>> Mike Frysinger <vapier@gentoo.org> writes:
> >>>>>>>>> --- a/localedata/locales/ca_AD
> >>>>>>>>> +++ b/localedata/locales/ca_AD
> >>>>>>>>> @@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
> >>>>>>>>> <U004E><U0025><U0063><U0025><U004E>"
> >>>>>>>>> country_ab2 "<U0041><U0044>"
> >>>>>>>>> country_ab3 "<U0041><U004E><U0044>"
> >>>>>>>>> -country_num 20
> >>>>>>>>> +country_num 020
> >>>>>>>>
> >>>>>>>> This is a plain number so the leading zero is not significant.
> >>>>>>>
> >>>>>>> i documented this in the commit message
> >>>>>>
> >>>>>> That doesn't make it correct.
> >>>>>
> >>>>> nor does it make it incorrect. i've provided justification for the
> >>>>> change at this point.
> >>>>
> >>>> "Add leading 0 prefix" is not justification.
> >>>
> >>> like i already said, read the *commit message*.
> >>
> >> I did. No justification.
> >
> > Please reread it, there was justification.
>
> "Other sources doing it wrong, too" is not a justification.
the "other sources" in this case are the standards.
sounds fine to me.
-mike
Either country_num is a plain number, then it should be written as a
plain number since the leading zero is ignored, or the leading zero is
significant, then it must be encoded as a string to preserve it.
Andreas.
On 04/13/2016 09:23 AM, Andreas Schwab wrote:
> Either country_num is a plain number, then it should be written as a
> plain number since the leading zero is ignored, or the leading zero is
> significant, then it must be encoded as a string to preserve it.
FWIW, I tend to agree with Andreas here. Maybe a middle-ground would be
to document somewhere that country_num is always to be formatted as a
three-digit decimal value.
(At least POSIX specifies numbers in the locale definition as decimal,
even with a leading zero. :)
Florian
Florian Weimer <fweimer@redhat.com> writes:
> FWIW, I tend to agree with Andreas here. Maybe a middle-ground would be
> to document somewhere that country_num is always to be formatted as a
> three-digit decimal value.
Then `locale country_num' needs to be fixed.
Andreas.
On 13 Apr 2016 09:23, Andreas Schwab wrote:
> Either country_num is a plain number, then it should be written as a
> plain number since the leading zero is ignored, or the leading zero is
> significant, then it must be encoded as a string to preserve it.
it isn't a string, it's a decimal number. the code enforces it.
the leading zero is insignificant here once it's been encoded which
leaves it as a style choice in the source locales. since the files
are meant to match the standards, using the style of the standards
makes sense.
-mike
Mike Frysinger <vapier@gentoo.org> writes:
> On 13 Apr 2016 09:23, Andreas Schwab wrote:
>> Either country_num is a plain number, then it should be written as a
>> plain number since the leading zero is ignored, or the leading zero is
>> significant, then it must be encoded as a string to preserve it.
>
> it isn't a string, it's a decimal number. the code enforces it.
> the leading zero is insignificant here once it's been encoded which
> leaves it as a style choice in the source locales. since the files
> are meant to match the standards, using the style of the standards
> makes sense.
Just because the standard is confusing doesn't mean we have to follow
it.
Andreas.
On 04/13/2016 05:33 AM, Florian Weimer wrote:
> On 04/13/2016 09:23 AM, Andreas Schwab wrote:
>> Either country_num is a plain number, then it should be written as
>> a plain number since the leading zero is ignored, or the leading
>> zero is significant, then it must be encoded as a string to
>> preserve it.
>
> FWIW, I tend to agree with Andreas here. Maybe a middle-ground would
> be to document somewhere that country_num is always to be formatted
> as a three-digit decimal value.
>
> (At least POSIX specifies numbers in the locale definition as
> decimal, even with a leading zero. :)
I have access to ISO 3166-1:2013 as part of my responsibilities within
the Standards Council of Canada. I have reviewed the standard language
with regards to this question, and to see if the standard can be improved
to help clarify this point. This meets my obligation to use the standard
in the development of standards.
My opinion is that glibc is failing to meet the standard by omitting the
leading zero.
The country number in ISO 3166-1:2013 is a three-digit numeric code,
not a two-digit numeric code. Any use of a two-digit numeric code is not
conforming. The valid ranges are 000 to 999.
Therefore writing down the three-digit numeric code in the locale is correct.
The bug is in the representation.
Florian's comment that we should document it as a three-digit decimal value
is a good starting point.
There is actually a numerical representation of the alpha-2 code which
could be used as the country number, and it is a proper number. However,
this is just an informative description and non-normative.
In summary
- To follow ISO 3166-1:2013 we must preserve all leading 0's, it is a
three-digit numeric code.
- We should probably just document that valid codes must be printed
with leading zeros and be 3 digits long.
On 13 Apr 2016 17:18, Andreas Schwab wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > On 13 Apr 2016 09:23, Andreas Schwab wrote:
> >> Either country_num is a plain number, then it should be written as a
> >> plain number since the leading zero is ignored, or the leading zero is
> >> significant, then it must be encoded as a string to preserve it.
> >
> > it isn't a string, it's a decimal number. the code enforces it.
> > the leading zero is insignificant here once it's been encoded which
> > leaves it as a style choice in the source locales. since the files
> > are meant to match the standards, using the style of the standards
> > makes sense.
>
> Just because the standard is confusing doesn't mean we have to follow
> it.
i don't find the standard confusing at all. what i do find confusing is
looking at the standard and all the downstream data stores (including,
but not limited to, CLDR) use zero-padded 3 digits. except glibc. so
then i have to spend time figuring out which is correct only to realize
later that they're both correct in practice -- glibc internally stores
the value as an integer, so leading zeros don't matter. by keeping the
locale files matching the standards, things are clear for people.
-mike
On 04/13/2016 01:38 PM, Mike Frysinger wrote:
> On 13 Apr 2016 17:18, Andreas Schwab wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>>> On 13 Apr 2016 09:23, Andreas Schwab wrote:
>>>> Either country_num is a plain number, then it should be written as a
>>>> plain number since the leading zero is ignored, or the leading zero is
>>>> significant, then it must be encoded as a string to preserve it.
>>>
>>> it isn't a string, it's a decimal number. the code enforces it.
>>> the leading zero is insignificant here once it's been encoded which
>>> leaves it as a style choice in the source locales. since the files
>>> are meant to match the standards, using the style of the standards
>>> makes sense.
>>
>> Just because the standard is confusing doesn't mean we have to follow
>> it.
>
> i don't find the standard confusing at all. what i do find confusing is
> looking at the standard and all the downstream data stores (including,
> but not limited to, CLDR) use zero-padded 3 digits. except glibc. so
> then i have to spend time figuring out which is correct only to realize
> later that they're both correct in practice -- glibc internally stores
> the value as an integer, so leading zeros don't matter. by keeping the
> locale files matching the standards, things are clear for people.
Agreed. The locale files should match the standard, as I noted up-stream
the standard is actually "a three-digit numeric code" and the leading zeros
are important in that definition that it be three-digits. If you were to
write a parser for the numeric codes you could write one that always assumes
there are three digits and you would be right.
A zero means octal everywhere else in the glibc source, locale drops the
zero, it is used as a plain number even though it is a string of digits.
It is confusing no matter how you look at it.
Andreas.
@@ -1,3 +1,24 @@
+2016-04-12 Mike Frysinger <vapier@gentoo.org>
+
+ * locales/as_IN (country_num): Define.
+ * locales/ber_DZ (country_num): Add leading 0 prefix.
+ * locales/ca_AD (country_num): Likewise.
+ * locales/dv_MV (country_num): Define.
+ * locales/dz_BT (country_num): Change to an integer.
+ * locales/en_AG (country_num): Add leading 0 prefix.
+ * locales/en_PH (country_num): Change to 608.
+ * locales/hy_AM (country_num): Add leading 0 prefix.
+ * locales/kk_KZ (country_num): Define.
+ * locales/km_KH (country_num): Change to 116.
+ * locales/ky_KG (country_num): Change to 417.
+ * locales/li_BE (country_num): Add leading 0 prefix.
+ * locales/my_MM (country_num): Define.
+ * locales/rw_RW (country_num): Define.
+ * locales/tr_CY (country_num): Change to 196.
+ * locales/tt_RU (country_num): Define.
+ * locales/wa_BE (country_num): Add leading 0 prefix.
+ * locales/wo_SN (country_num): Change to 686.
+
2016-04-09 Mike Frysinger <vapier@gentoo.org>
* locales/en_AG (LC_PAPER): Copy en_GB instead.
@@ -167,6 +167,7 @@ postal_fmt "<U0025><U007A><U0025><U0063><U0025><U0054><U0025><U0073>/
<U0025><U0062><U0025><U0065><U0025><U0072>"
% IND
country_car "<U0049><U004E><U0044>"
+country_num 356
% অসমীয়া
lang_name "<U0985><U09B8><U09AE><U09C0><U09AF><U09BC><U09BE>"
% as
@@ -293,7 +293,7 @@ postal_fmt "<U0025><U007A><U0025><U0063><U0025><U0054><U0025><U0073>/
%country_post ""
country_ab2 "<U0044><U005A>"
country_ab3 "<U0044><U005A><U0041>"
-country_num 12
+country_num 012
%country_isbn ""
% DZ
country_car "<U0044><U005A>"
@@ -96,7 +96,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
<U004E><U0025><U0063><U0025><U004E>"
country_ab2 "<U0041><U0044>"
country_ab3 "<U0041><U004E><U0044>"
-country_num 20
+country_num 020
% AND
country_car "<U0041><U004E><U0044>"
% catalÃ
@@ -183,6 +183,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
<U0020><U0025><U0068><U0020><U0025><U0065><U0020><U0025><U0072><U0025>/
<U004E><U0025><U0025><U007A><U0020><U0025><U0054><U0025>/
<U004E><U0025><U0063><U0025><U004E>"
+country_num 462
% lang_name FIXME
% Cannot represent Dhivehi in Thaana script
% http://en.wikipedia.org/wiki/Maldivian_language
@@ -663,9 +663,9 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
country_name "<U0F60><U0F56><U0FB2><U0F74><U0F42><U0F0D>"
%FIXME
%country_post ""
-country_ab2 "<U0042><U0054>"
-country_ab3 "<U0042><U0048><U0055>"
-%country_num "<U0042><U0048><U0055>"
+country_ab2 "<U0042><U0054>"
+country_ab3 "<U0042><U0054><U004E>"
+country_num 064
%FIXME
%country_isbn ""
% རྫོང་à½
@@ -92,7 +92,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
<U004E><U0025><U0063><U0025><U004E>"
country_ab2 "<U0041><U0047>"
country_ab3 "<U0041><U0054><U0047>"
-country_num 28
+country_num 028
% English
lang_name "<U0045><U006E><U0067><U006C><U0069><U0073><U0068>"
% en
@@ -197,9 +197,9 @@ LC_ADDRESS
% This is the ISO_IEC TR14652 Locale definition for the LC_ADDRESS category
% generated by IBM Basic CountryPack Transformer.
postal_fmt "<U0025><U007A><U0025><U0063><U0025><U0054><U0025><U0073><U0025><U0062><U0025><U0065><U0025><U0072>"
-country_ab2 "<U0049><U0044>"
-country_ab3 "<U0049><U0044><U004E>"
-country_num 360
+country_ab2 "<U0050><U0048>"
+country_ab3 "<U0050><U0048><U004C>"
+country_num 608
% RP
country_car "<U0052><U0050>"
% English
@@ -189,7 +189,7 @@ country_name "<U0540><U0561><U0575><U0561><U057D><U057F><U0561><U0576>"
% FIXME country_post for Armenia?
country_ab2 "<U0041><U004D>"
country_ab3 "<U0041><U0052><U004D>"
-country_num 51
+country_num 051
country_car "<U0041><U004D>"
country_isbn "<U0039><U0039><U0039><U0033><U0030>"
lang_name "<U0540><U0561><U0575><U0565><U0580><U0565><U0576>"
@@ -266,6 +266,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
<U0020><U0025><U0068><U0020><U0025><U0065><U0020><U0025><U0072><U0025>/
<U004E><U0025><U007A><U0020><U0025><U0054><U0025>/
<U004E><U0025><U0063><U0025><U004E>"
+country_num 398
% KZ
country_car "<U004B><U005A>"
% kk
@@ -1871,9 +1871,9 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
country_name "<U1780><U1798><U17D2><U1796><U17BB><U1787><U17B6>"
%FIXME
%country_post ""
-country_ab2 "<U004C><U0041>"
-country_ab3 "<U004C><U0041><U004F>"
-country_num 418
+country_ab2 "<U004B><U0048>"
+country_ab3 "<U004B><U0048><U004D>"
+country_num 116
country_car "<U004C><U0041><U004F>"
%FIXME
%country_isbn ""
@@ -210,9 +210,9 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
<U0020><U0025><U0068><U0020><U0025><U0065><U0020><U0025><U0072><U0025>/
<U004E><U0025><U007A><U0020><U0025><U0054><U0025>/
<U004E><U0025><U0063><U0025><U004E>"
-country_ab2 "<U004B><U0059>"
-country_ab3 "<U004B><U0059><U0052>"
-%country_num 643
+country_ab2 "<U004B><U0047>"
+country_ab3 "<U004B><U0047><U005A>"
+country_num 417
% KS
country_car "<U004B><U0053>"
% Кыргызча
@@ -52,7 +52,7 @@ country_post "<U0042>"
country_ab2 "<U0042><U0045>"
country_ab3 "<U0042><U0045><U004C>"
country_car "<U0042>"
-country_num 56
+country_num 056
%FIXME country_isbn "2"
% Lèmbörgs
lang_name "<U004C><U00E8><U006D><U0062><U00F6><U0072><U0067><U0073>"
@@ -318,6 +318,7 @@ postal_fmt "<U0025><U0061><U0025><U004E><U0025><U0064><U0025><U004E><U0025><U0
country_name "<U1019><U103C><U1014><U103A><U1019><U102C>"
country_post "<U004D><U0079><U0061><U006E><U006D><U0061><U0072>"
country_ab2 "<U004D><U004D>"
+country_num 104
% BA
country_car "<U0042><U0041>"
lang_ab "<U006D><U0079>"
@@ -143,6 +143,7 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
country_name "<U0052><U0077><U0061><U006E><U0064><U0061>"
country_ab2 "<U0052><U0057>"
country_ab3 "<U0052><U0057><U0041>"
+country_num 646
% RWA
country_car "<U0052><U0057><U0041>"
lang_name "<U004B><U0069><U006E><U0079><U0061><U0072><U0077><U0061><U006E><U0064><U0061>"
@@ -104,11 +104,9 @@ country_post "<U0054><U0052>"
% TR
country_car "<U0054><U0052>"
country_isbn 975
-country_num 792
-% TR
-country_ab2 "<U0054><U0052>"
-% TUR
-country_ab3 "<U0054><U0055><U0052>"
+country_num 196
+country_ab2 "<U0043><U0059>"
+country_ab3 "<U0043><U0059><U0050>"
% Turkish
lang_name "<U0054><U0075><U0072><U006B><U0069><U0073><U0068>"
% tur
@@ -321,6 +321,7 @@ END LC_NAME
LC_ADDRESS
% FIXME
postal_fmt "???"
+country_num 643
% RUS
country_car "<U0052><U0055><U0053>"
% tt
@@ -48,7 +48,7 @@ country_name "<U0042><U0065><U006C><U006A><U0069><U006B><U0065>"
country_post "B"
country_ab2 "BE"
country_ab3 "BEL"
-country_num 56
+country_num 056
country_isbn "2"
% B
country_car "<U0042>"
@@ -179,9 +179,9 @@ postal_fmt "<U0025><U0066><U0025><U004E><U0025><U0061><U0025><U004E>/
<U0020><U0025><U0068><U0020><U0025><U0065><U0020><U0025><U0072><U0025>/
<U004E><U0025><U007A><U0020><U0025><U0054><U0025>/
<U004E><U0025><U0063><U0025><U004E>"
-country_ab2 "<U004D><U0047>"
-country_ab3 "<U004D><U0044><U0047>"
-country_num 450
+country_ab2 "<U0053><U004E>"
+country_ab3 "<U0053><U0045><U004E>"
+country_num 686
% SN
country_car "<U0053><U004E>"
% wo