Bug 11484 - bg_BG: updated locale
Summary: bg_BG: updated locale
Status: WAITING
Alias: None
Product: glibc
Classification: Unclassified
Component: localedata (show other bugs)
Version: 2.11
: P2 normal
Target Milestone: ---
Assignee: GNU C Library Locale Maintainers
URL:
Keywords:
: 9865 13949 (view as bug list)
Depends on:
Blocks: 5599 9865 13237
  Show dependency treegraph
 
Reported: 2010-04-09 19:59 UTC by Roumen Petrov
Modified: 2016-04-22 04:37 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2010-06-01 02:47:43
fweimer: security-


Attachments
new Bulgarian locale (4.81 KB, text/plain)
2010-04-09 20:03 UTC, Roumen Petrov
Details
version 3.0.3 with license update (5.09 KB, text/plain)
2011-05-10 20:11 UTC, Roumen Petrov
Details
C program to test locale (694 bytes, text/x-csrc)
2011-05-13 19:47 UTC, Roumen Petrov
Details
simple shell script to test locale (475 bytes, application/x-sh)
2011-05-13 19:53 UTC, Roumen Petrov
Details
perl script to test cyrillic sort (93 bytes, application/x-perl)
2011-05-13 19:57 UTC, Roumen Petrov
Details
shell script to test sort of punctuation+latin+cyrillic characters (209 bytes, application/x-sh)
2011-05-13 19:59 UTC, Roumen Petrov
Details
version 3.0.4 (5.06 KB, text/plain)
2011-11-11 00:04 UTC, Roumen Petrov
Details
update 'Bulgarian translators team' email (5.07 KB, patch)
2012-04-06 21:13 UTC, Roumen Petrov
Details | Diff
restore previous copyrights (5.13 KB, text/plain)
2012-12-01 16:19 UTC, Roumen Petrov
Details
version 3.0.7 (5.13 KB, text/plain)
2013-11-04 20:02 UTC, Roumen Petrov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roumen Petrov 2010-04-09 19:59:07 UTC
To this issue will be attached file with new locale settings for Bulgarian. This
is new work intended non-maintained file.
Comment 1 Roumen Petrov 2010-04-09 20:03:49 UTC
Created attachment 4714 [details]
new Bulgarian locale

I would like to propose existing file (bg_BG) to be removed first from
repository and after this new work to be added to repository.
Comment 2 Ulrich Drepper 2010-04-11 04:21:37 UTC
You have to get the previous maintainer to agree with that.
Comment 3 Petr Baudis 2010-04-21 21:26:05 UTC
It would be great to have at least some general summary of changes compared to
the original locale.

It seems it would be good idea to remove the generic comments about formats of
various attributes and keep only locale-specific comments. The same goes for
comments containing plaintext versions of attribute values.

Your weekday abbreviations are wrong - if you specify Monday in week directive,
the first day in the list must be Monday.
Comment 4 Roumen Petrov 2010-04-21 22:49:49 UTC
If I understand  ISO/IEC TR14652:2002 properly if week start with Monday the
lists with weekday names should start with Monday, but for GNU libc the lists
must start with Sunday.
Comment 5 Petr Baudis 2010-04-22 05:10:51 UTC
Hmm, you are right that strftime() does not honor week[2], I will have to fix
that sometime *sigh*. In that case, it would probably be better to keep
week[2]==19971130 and set first_weekday to 2, to have everything set up
consistently.

Anyway, trying to compile the locale throws a huge bunch of warnings.
Comment 6 Roumen Petrov 2010-04-22 21:25:36 UTC
About warnings no idea as my GNU glibc is ld version (2.7) and on other locales
result is same as example:
bg_BG:27: non-symbolic character value should not be used
but line 27 is:
title      "Bulgarian locale for Bulgaria"

About:
LC_NAME: field `name_gen' not defined
  No salutation to all persons in Bulgarian. So what is correct : do not define
or to define to empty string with comment "No salutation ..." ?

LC_IDENTIFICATION: field `abbreviation' not defined
  What to set to this field BG-<VERSION> ? I don't know . It is defined only for
uk_UA (ULU-2.1.12) and and en_ZA("Translate.org.za).
Comment 7 Petr Baudis 2010-06-01 02:47:54 UTC
*** Bug 9865 has been marked as a duplicate of this bug. ***
Comment 8 Ulrich Drepper 2011-05-10 03:26:11 UTC
Again, why should the existing locale be replaced?  You have to get the author of the existing locale to agree.
Comment 9 Roumen Petrov 2011-05-10 20:11:15 UTC
Created attachment 5713 [details]
version 3.0.3 with license update

Updated license following recent discussion on libc-locales mailing list with subject "Many locale definitions need license change"
Comment 10 Roumen Petrov 2011-05-10 20:13:43 UTC
(In reply to comment #8)
> Again, why should the existing locale be replaced?  You have to get the author
> of the existing locale to agree.

Please see post http://sourceware.org/bugzilla/show_bug.cgi?id=9865#c3 .
About attachments to this issue - it is new work and I would like to maintain in the future.
Comment 11 Roumen Petrov 2011-05-10 22:23:50 UTC
It seems to me I forgot to post what's new . 

The new version follow up http://zver.fsa-bg.org/pipermail/dict/2010-March/004652.html - a long discussion about some issues with Bulgarian locale .

For public discussion version 3.0.1 was posted here http://zver.fsa-bg.org/pipermail/dict/2010-March/004743.html :

A) brief description of updates.
а) new author, copyright and contacts
b)  LC_IDENTIFICATION
- new contacts
- category compatible with IEC_TR_14652/2002
c) LC_CTYPE
- no change
d) LC_COLLATE
- removed all extra collating sequences. Version 3.0.2 add "Capital letters go before small" on request.
d) LC_MONETARY
- no grouping, no thousand separator
- currency with dot at end
е) LC_NUMERIC
- no grouping, no thousand separator . БДС ISO 31-0:1994 allow groping but is is not common
f) LC_TIME
- rewritten. see below for details
g) LC_MESSAGES
- no change
h) LC_PAPER
- no change
i) LC_NAME
- names with abbreviated profession, i.e. %S instead %s
- abbreviation correspondind for mr. is with correct representation.
j) LC_ADDRESS
- country_name and lang_name in Bulgarian
- postal address accordind to the norm of "Bulgarian Post"
k) LC_TELEPHONE
- without brace for domestic and international calls
l) LC_MEASUREMENT
- no change

B) date and time description (LC_TIME)
- description of era format
- colon instead comma as time separator (preferred  format discussed in the first link above)
- clock time is in 24h format. Current version is ambiguous as describe 12h format without corresponding abbreviation for am/pm.



New time output (for  1h 2m and 3s  and for 13h 2m и 3s. for the flag %r):
--------------------------------------------------------------------------------
01:02:03 and 13:02:03
--------------------------------------------------------------------------------
Current is:
--------------------------------------------------------------------------------
   1,02,03 and  1,02,03
--------------------------------------------------------------------------------

- rearranged days and month is date format 
New date output:
--------------------------------------------------------------------------------
2010-04-01 13:02:03:    четвъртък  1 април 2010 13:02:03 EEST
+%c                     чт  1 апр 2010 13:02:03 EEST
+%x (date)               1.04.2010
+%X (time)              13:02:03
+%y (s-year)            10
+%Y (year)              2010
+%Ec (+era)             чт  1 апр 2010 сл.н.е. 13:02:03 EEST
+%Ex (date+era)          1.04.2010 сл.н.е.
+%EX (time+era)         13:02:03
+%Ey (s-year+era)       2010
+%EY (year+era)         2010 сл.н.е.
--------------------------------------------------------------------------------
Current is:
--------------------------------------------------------------------------------
2010-04-01 13:02:03:    чт апр  1 13:02:03 EEST 2010
+%c                      1.04.2010 (чт) 13,02,03 EEST
+%x (date)               1.04.2010
+%X (time)              13,02,03
+%y (s-year)            10
+%Y (year)              2010
+%Ec (+era)              1.04.2010 (чт) 13,02,03 EEST
+%Ex (date+era)          1.04.2010
+%EX (time+era)         13,02,03
+%Ey (s-year+era)       10
+%EY (year+era)         2010
--------------------------------------------------------------------------------
Comment 12 Ulrich Drepper 2011-05-10 22:53:43 UTC
(In reply to comment #11)
> +%EY (year+era)         2010 сл.н.е.

And there is already a problem.  You're completely overdoing it.  Eras are pretty much only for Japan and nothing else.


There are drastic changes.  I understand you cannot get the previous maintainer to comment.  But I need assurance.  Did you announce the availability of the locale, have people test it, and report back?  I have nothing else to get by.
Comment 13 Roumen Petrov 2011-05-13 19:47:46 UTC
Created attachment 5718 [details]
C program to test locale

The post for version 3.0.1(see link above) contain some tests. This is first test.
Comment 14 Roumen Petrov 2011-05-13 19:53:54 UTC
Created attachment 5719 [details]
simple shell script to test locale

second test from above post
Comment 15 Roumen Petrov 2011-05-13 19:57:23 UTC
Created attachment 5720 [details]
perl script to test cyrillic sort

I'm not perl expert and script will warn "Wide character in print at ./test-sort.pl line 4."  but the last line is expected result.
Comment 16 Roumen Petrov 2011-05-13 19:59:45 UTC
Created attachment 5721 [details]
shell script to test sort of punctuation+latin+cyrillic characters
Comment 17 Roumen Petrov 2011-05-13 20:08:47 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > +%EY (year+era)         2010 сл.н.е.
> 
> And there is already a problem.  You're completely overdoing it.  Eras are
> pretty much only for Japan and nothing else.

Why ? But AIX according to the internet pages define christian era (search for  ibm aix localdef lctime). The definition look like:
era "+:0:0000/01/01:+*:AD:%o %N";\
"+:1:-0001/12/31:-*:BC:%o %N"
era_year ""
era_d_fmt "" 

Many Bulgarian prefer neutral definition for New(Common) Era the file contain neutral abbreviations.
Comment 18 Roumen Petrov 2011-11-11 00:04:30 UTC
Created attachment 6048 [details]
version 3.0.4

day in month and month without leading zero or space
Comment 19 Roumen Petrov 2012-04-06 20:33:18 UTC
*** Bug 13237 has been marked as a duplicate of this bug. ***
Comment 20 Roumen Petrov 2012-04-06 20:37:27 UTC
*** Bug 13949 has been marked as a duplicate of this bug. ***
Comment 21 Roumen Petrov 2012-04-06 21:13:56 UTC
Created attachment 6329 [details]
update 'Bulgarian translators team' email

"Bulgarian translators team"  use new list address.
Post to dict@fsa-bg.org(old one)  are redirected  to dict@ludost.net (new one).
Comment 22 Petr Baudis 2012-04-13 18:06:42 UTC
I think Ulrich's questions are valid - these are very significant changes and you should get endorsement by the Bulgarian user community first.
Comment 23 Roumen Petrov 2012-04-14 11:24:02 UTC
I get consensus from bulgarian community  . Since mail list was changed (moved to new host) , link to arhive  http://zver.fsa-bg.org/pipermail/dict/2010-March/004652.html is not valid.
The discussions related to bg locale  are still available on list-mirrors.

Quick review show that content of non existing 
  "http://zver.fsa-bg.org/pipermail/dict/2010-March/004652.html"
 could be found on
  "http://bulgarian-translators-of-free-software.1048928.n5.nabble.com/3-0-1-tt4356742.html#none"
 (13 posts) -  version 3.0.1. 
Version is based on discussion from :
  "http://bulgarian-translators-of-free-software.1048928.n5.nabble.com/-tt4356508.html"
 (63 posts) and some earlier posts.
Comment 24 Roumen Petrov 2012-12-01 16:19:59 UTC
Created attachment 6768 [details]
restore previous copyrights
Comment 25 Roumen Petrov 2013-11-04 20:02:09 UTC
Created attachment 7265 [details]
version 3.0.7

uploaded v3.0.7 with correct specification of category

( also include useless upstream fix for lang_lib as by definition if is not set is used  value of lang_term )
Comment 26 Mike Frysinger 2016-04-22 04:37:41 UTC
there's a ton going on here, and bg_BG has been updated since.  let's distill the changes down.  we really don't want to see fully new locale files with tons of extraneous noise (like specs in the comments) added.

some of these updates we'll just have to go with for now until we can get the details out of CLDR.

* LC_COLLATE ... i'll just go with this one.

* LC_MONETARY
  -mon_thousands_sep         "<U00A0>"
  +mon_thousands_sep         ""
  -mon_grouping              3;3
  +mon_grouping              -1
  -grouping                  3;3
  +grouping                  -1

* LC_TIME
  -d_t_fmt "%x (%a) %X %Z"
  +d_t_fmt "%a %-d %b %Y %T %Z"

  -d_fmt "%e.%m.%Y"
  +d_fmt "%-d.%-m.%Y"

  -t_fmt "%k:%M:%S"
  +t_fmt "%T"

  +era "+:0:0/1/1:+*:сл.н.е.:%Ey %EC";/
  +    "+:0:-1/12/31:-*:пр.н.е.:%Ey %EC"
  +date_fmt   "%A %-d %B %Y %T %Z"
  +era_d_t_fmt    "%a %-d %b %EY %T %Z"
  +era_d_fmt      "%-d.%-m.%EY"

  +cal_direction 2

These LC_TIME settings are wrong for sure:
  -week 7;19971130;4
  +week 7;19971201;1
  -first_weekday 2
  +first_weekday 1
  +first_workday 1

* LC_NAME
  -name_fmt  "%s%t%g%t %m%t%f"
  +name_fmt  "%S%t%g%t %m%t%f"
  -name_mr   "г-дин"
  +name_mr   "г-н"

* LC_ADDRESS
  -postal_fmt "%f%N%a%N%d%N%b%N%sN%h, %e, %r%N%z %T%N%c%N"
  +postal_fmt "%a%N%f%N%d%N%b%N%s %h, %e, %r%N%z %T%N%c%N"

* LC_TELEPHONE
  -tel_int_fmt "(+%c %a) %l"
  +tel_int_fmt "+%c %a %l"
  -tel_dom_fmt "(0%a) %l"
  +tel_dom_fmt "0%a %l"