diff mbox series

[RFC] Multiple locales: Use the correct date and time formats (bug 10496, 23724).

Message ID 726702465.188131.1541157069943@poczta.nazwa.pl
State New
Headers show
Series [RFC] Multiple locales: Use the correct date and time formats (bug 10496, 23724). | expand

Commit Message

Rafal Luzynski Nov. 2, 2018, 11:11 a.m. UTC 
Hi,

I need an advice.  Recently I've been working on a change which
initially seemed to be a simple one-liner but eventually turned
out to be updating 80 locales.  The change fixes the 12-hour time
formats, adding the AM/PM indicator and changing the hour format.
The locales mostly include those using Arabic language, from India,
and from the region of Eritrea, Ethiopia and Somalia.

My question is: should I treat the CLDR database literally and
change the time formats like "%I:%M:%S" to "%l:%M:%S" whenever CLDR
provides the time format "h:mm:ss"?  I spotted this difference while
importing the time formats from CLDR in order to find those which
should use the AM/PM indicator.

The difference is that "%I" is a zero-padded hour number while "%l"
is a space-padded hour number;  in CLDR format "h" is an hour number
using as many digits as necessary (no additional padding mentioned).

My doubt is because the original complaint here was about missing the
AM/PM indicator, nobody complained about the clock using the zero-padded
hour number.

I am afraid that the change is minor and irrelevant and most people's
answer even from the involved countries is "I don't know/I don't care".
So if the glibc community does not provide any sustained objection I will
prepare and eventually commit this change.

As a sample here please find attached a patch for Albanian language.
I'd like to fix this locale as a separate patch because this also
fixes the date formats and it cannot be separated from the time formats.
If accepted I will commit this patch and move to other locales.

I am consulting this change with the people from Albania and India but
I don't know anyone speaking Arabic or living in Eritrea, Ethiopia
or Somalia.

Regards,

Rafal

Comments

TAMUKI Shoichi Nov. 3, 2018, 4:06 a.m. UTC | #1 
Hello Rafal,

From: Rafal Luzynski <digitalfreak@lingonborough.com>
Subject: [RFC][PATCH] Multiple locales: Use the correct date and time formats (bug 10496, 23724).
Date: Fri, 2 Nov 2018 12:11:09 +0100 (CET)

> It also sets the correct date format because the old "%Y-%b-%d" produced
> rather weird results like "2018-Sht-28".
> 
> (snip)
> 
> diff --git a/localedata/locales/sq_AL b/localedata/locales/sq_AL
> index 9cec37a..a90251f 100644
> --- a/localedata/locales/sq_AL
> +++ b/localedata/locales/sq_AL
> @@ -303,16 +303,19 @@ mon         "janar";/
>  am_pm       "PD";"MD"
>  %
>  % Appropriate date and time representation
> -d_t_fmt     "%Y-%b-%d %I.%M.%S.%p %Z"
> +d_t_fmt     "%a %-d %b %Y %l:%M:%S.%p"

I am afraid that change will unable to keep it a constant width.

How about using "%a %_d %b %Y %l:%M:%S.%p" instead.

> +%
> +% Appropriate date representation for date(1)
> +date_fmt    "%a %-d %b %Y %l:%M:%S.%p %Z"

Likewise, how about using "%a %_d %b %Y %l:%M:%S.%p %Z" instead.

>  %
>  % Appropriate date representation
> -d_fmt       "%Y-%b-%d"
> +d_fmt       "%-d.%-m.%y"

Likewise, how about using "%_d.%_m.%y" instead.

Regards,
TAMUKI Shoichi
Rafal Luzynski Nov. 3, 2018, 7:45 p.m. UTC | #2 
Hello Tamuki Shoichi and thank you for your feedback.

3.11.2018 05:06 TAMUKI Shoichi <tamuki@linet.gr.jp> wrote:
> 
> 
> Hello Rafal,
> 
> From: Rafal Luzynski <digitalfreak@lingonborough.com>
> Subject: [RFC][PATCH] Multiple locales: Use the correct date and time
> formats (bug 10496, 23724).
> Date: Fri, 2 Nov 2018 12:11:09 +0100 (CET)
> 
> > [...]
> > @@ -303,16 +303,19 @@ mon         "janar";/
> >  am_pm       "PD";"MD"
> >  %
> >  % Appropriate date and time representation
> > -d_t_fmt     "%Y-%b-%d %I.%M.%S.%p %Z"
> > +d_t_fmt     "%a %-d %b %Y %l:%M:%S.%p"
> 
> I am afraid that change will unable to keep it a constant width.

Is it required to keep the constant width?  In my native locale we use
"%-d" and I think it works fine.

> How about using "%a %_d %b %Y %l:%M:%S.%p" instead.

"_" means "use a space as padding".  If I had to use space padding
I would use "%e" instead which does the same and is less tricky.

> [...]
> >  %
> >  % Appropriate date representation
> > -d_fmt       "%Y-%b-%d"
> > +d_fmt       "%-d.%-m.%y"
> 
> Likewise, how about using "%_d.%_m.%y" instead.

No, additional space before a month number looks definitely bad.
We use dots or other punctuation characters and zero padding to avoid
spaces in a string which normally should have no spaces.

Thank you again and best regards,

Rafal
TAMUKI Shoichi Nov. 4, 2018, 3:07 a.m. UTC | #3 
Hello Rafal,

From: Rafal Luzynski <digitalfreak@lingonborough.com>
Date: Sat, 3 Nov 2018 20:45:56 +0100 (CET)
Subject: Re: [RFC][PATCH] Multiple locales: Use the correct date and time formats (bug 10496, 23724).

> > > [...]
> > > @@ -303,16 +303,19 @@ mon         "janar";/
> > >  am_pm       "PD";"MD"
> > >  %
> > >  % Appropriate date and time representation
> > > -d_t_fmt     "%Y-%b-%d %I.%M.%S.%p %Z"
> > > +d_t_fmt     "%a %-d %b %Y %l:%M:%S.%p"
> > 
> > I am afraid that change will unable to keep it a constant width.
> 
> Is it required to keep the constant width?  In my native locale we use
> "%-d" and I think it works fine.

Although I am no expert in sq_AL locale, if d_t_fmt which is fixed
width suddenly becomes variable width, I just thought that there might
be people in trouble.

I have roughly checked in the current locale data to see which locale
uses a variable width at d_t_fmt.  The result is:

ca_ES:	"%A, %-d %B de %Y, %T %Z"
cs_CZ:	"%a<U00A0>%-d.<U00A0>%B<U00A0>%Y,<U00A0>%H:%M:%S<U00A0>%Z"
hu_HU:	"%Y. %b. %-e., %A, %H:%M:%S %Z"
it_CH:	"%a %-d %b %Y, %T"
it_IT:	"%a %-d %b %Y, %T"
nr_ZA:	"%a %-e %b %Y %T %Z"
pl_PL:	"%a, %-d %b %Y, %T"
ss_ZA:	"%a %-e %b %Y %T %Z"
st_ZA:	"%a %-e %b %Y %T %Z"
szl_PL:	"%a, %-d %b %Y, %T"
tn_ZA:	"%a %-e %b %Y %T %Z"
ts_ZA:	"%a %-e %b %Y %T %Z"
xh_ZA:	"%a %-e %b %Y %T %Z"

> > How about using "%a %_d %b %Y %l:%M:%S.%p" instead.
> 
> "_" means "use a space as padding".  If I had to use space padding
> I would use "%e" instead which does the same and is less tricky.

Yes, indeed.  Since "%e" and "%-d" are equivalent, one byte can be
saved by using "%e".  Thank you for your advice.

> > [...]
> > >  %
> > >  % Appropriate date representation
> > > -d_fmt       "%Y-%b-%d"
> > > +d_fmt       "%-d.%-m.%y"
> > 
> > Likewise, how about using "%_d.%_m.%y" instead.
> 
> No, additional space before a month number looks definitely bad.
> We use dots or other punctuation characters and zero padding to avoid
> spaces in a string which normally should have no spaces.

For example, "LANG=C date" shows a space as padding to keep it a
constant width.

Anyway, if people involved in that locale are not particularly
troubled, I think that there is no problem without padding.

Regards,
TAMUKI Shoichi
Rafal Luzynski Nov. 5, 2018, 9:59 p.m. UTC | #4 
4.11.2018 04:07 TAMUKI Shoichi <tamuki@linet.gr.jp> wrote:
> [...]
> Although I am no expert in sq_AL locale,

Sure, neither am I.  That's why I'm trying to approach the actual native
speakers (off-list).

> if d_t_fmt which is fixed
> width suddenly becomes variable width, I just thought that there might
> be people in trouble.

I'm trying to understand the use case where people might be in trouble
if the date width varies.  It it maybe that someone may be trying to extract
pieces of the date (e.g., the current month or the current week day) from
the
output of date finding a substring at specified constant index?  If yes then
there are more reasons why this may not work, especially in non-English
locales,
and better ways to achieve the correct results.

> I have roughly checked in the current locale data to see which locale
> uses a variable width at d_t_fmt.  The result is:
> 
> ca_ES:	"%A, %-d %B de %Y, %T %Z"
> cs_CZ:	"%a<U00A0>%-d.<U00A0>%B<U00A0>%Y,<U00A0>%H:%M:%S<U00A0>%Z"
> hu_HU:	"%Y. %b. %-e., %A, %H:%M:%S %Z"
> it_CH:	"%a %-d %b %Y, %T"
> it_IT:	"%a %-d %b %Y, %T"
> nr_ZA:	"%a %-e %b %Y %T %Z"
> pl_PL:	"%a, %-d %b %Y, %T"
> ss_ZA:	"%a %-e %b %Y %T %Z"
> st_ZA:	"%a %-e %b %Y %T %Z"
> szl_PL:	"%a, %-d %b %Y, %T"
> tn_ZA:	"%a %-e %b %Y %T %Z"
> ts_ZA:	"%a %-e %b %Y %T %Z"
> xh_ZA:	"%a %-e %b %Y %T %Z"

Thank you for this survey!  Yes, this is an evidence that variable width
date formats may be acceptable.

> > > [...]
> > > >  %
> > > >  % Appropriate date representation
> > > > -d_fmt       "%Y-%b-%d"
> > > > +d_fmt       "%-d.%-m.%y"
> > > 
> > > Likewise, how about using "%_d.%_m.%y" instead.
> > 
> > No, additional space before a month number looks definitely bad.
> > We use dots or other punctuation characters and zero padding to avoid
> > spaces in a string which normally should have no spaces.
> 
> For example, "LANG=C date" shows a space as padding to keep it a
> constant width.

This is a different case.  When you execute "date" with no arguments
it uses the date format which consists of numbers and words: day number,
abbreviated month name, abbreviated weekday name, etc.  It is correct
to separate them with spaces, and not so bad to add more spaces, when
needed.  In my case I was referring to a string which consists exclusively
of digits and punctuation characters (like 5.11.2018 or 11/5/18) which
should not contain spaces.  That's why zero-padding exists.  (e.g.,
05.11.18 or 11/05/18). " 5.11.2018" may not be so bad but "11/ 5/18"
is rather weird.

> Anyway, if people involved in that locale are not particularly
> troubled, I think that there is no problem without padding.

Yes, thank you for helping me formulate my question more precisely
and more clearly for native speaker.  I will ask them if they expect
the formatted dates to have a constant width and if making the width
variable will cause a trouble for them.

Regards,

Rafal
TAMUKI Shoichi Nov. 8, 2018, 12:05 p.m. UTC | #5 
Hello Rafal,

From: Rafal Luzynski <digitalfreak@lingonborough.com>
Subject: Re: [RFC][PATCH] Multiple locales: Use the correct date and time formats (bug 10496, 23724).
Date: Mon, 5 Nov 2018 22:59:05 +0100 (CET)

> > if d_t_fmt which is fixed
> > width suddenly becomes variable width, I just thought that there might
> > be people in trouble.
> 
> I'm trying to understand the use case where people might be in trouble
> if the date width varies.  It it maybe that someone may be trying to extract
> pieces of the date (e.g., the current month or the current week day) from the
> output of date finding a substring at specified constant index?  If yes then
> there are more reasons why this may not work, especially in non-English locales,
> and better ways to achieve the correct results.

For example, user-oriented software implemented to output logs using
%c, the preferred calendar time representation for the current locale
for the sake of clarity, will be inconvenient if the date and time
width varies.

> > I have roughly checked in the current locale data to see which locale
> > uses a variable width at d_t_fmt.  The result is:
> > 
> > ca_ES:	"%A, %-d %B de %Y, %T %Z"
> > cs_CZ:	"%a<U00A0>%-d.<U00A0>%B<U00A0>%Y,<U00A0>%H:%M:%S<U00A0>%Z"
> > hu_HU:	"%Y. %b. %-e., %A, %H:%M:%S %Z"
> > it_CH:	"%a %-d %b %Y, %T"
> > it_IT:	"%a %-d %b %Y, %T"
> > nr_ZA:	"%a %-e %b %Y %T %Z"
> > pl_PL:	"%a, %-d %b %Y, %T"
> > ss_ZA:	"%a %-e %b %Y %T %Z"
> > st_ZA:	"%a %-e %b %Y %T %Z"
> > szl_PL:	"%a, %-d %b %Y, %T"
> > tn_ZA:	"%a %-e %b %Y %T %Z"
> > ts_ZA:	"%a %-e %b %Y %T %Z"
> > xh_ZA:	"%a %-e %b %Y %T %Z"
> 
> Thank you for this survey!  Yes, this is an evidence that variable width
> date formats may be acceptable.

These are only 13 locales out of the total 353 locales.  Please note
that there are fixed-width date and time formats for almost all other
locales (96.3%) except the above.

> > For example, "LANG=C date" shows a space as padding to keep it a
> > constant width.
> 
> This is a different case.  When you execute "date" with no arguments
> it uses the date format which consists of numbers and words: day number,
> abbreviated month name, abbreviated weekday name, etc.  It is correct
> to separate them with spaces, and not so bad to add more spaces, when
> needed.  In my case I was referring to a string which consists exclusively
> of digits and punctuation characters (like 5.11.2018 or 11/5/18) which
> should not contain spaces.  That's why zero-padding exists.  (e.g.,
> 05.11.18 or 11/05/18). " 5.11.2018" may not be so bad but "11/ 5/18"
> is rather weird.

I agree.  If you do not have any problems using zero-padding (e.g.,
05.11.18 or 11/05/18), I think it is a good choice.

By the way,

	"9:00 a.m. - 5:00 p.m."

in English is translated as

	"9:00 e paradites - 5:00 e pasdites"

in Albanian.

So, should we include such a representation?

Regards,
TAMUKI Shoichi
Rafal Luzynski Nov. 27, 2018, 10:26 p.m. UTC | #6 
Hello,

I'm sorry for this delayed reply.  Please see my answers inline:

8.11.2018 13:05 TAMUKI Shoichi <tamuki@linet.gr.jp> wrote:
> [...]
> For example, user-oriented software implemented to output logs using
> %c, the preferred calendar time representation for the current locale
> for the sake of clarity, will be inconvenient if the date and time
> width varies.

This is a good point and I don't know what to say.  Indeed, for the log
files it is convenient to display constant width dates and times.
On the other hand, most of the time I was thinking about displaying just
one date and/or time, for the purposes of user interface.

Therefore I'm asking community here.  Please provide your feedback:
should the date and time formats provided by glibc locale data keep the
constant width of the output (because it makes easier to display lists of
dates and times in vertical columns, like in log files) or should it be
allowed to provide variable width formats as well (because it follows
the local conventions of displaying single dates, standalone, like in
the user interface)?  Or maybe we should not worry about log files because
they should not be localized and use only the default C locale for date and
time format?  Mike, Carlos, others?

> > > I have roughly checked in the current locale data to see which locale
> > > uses a variable width at d_t_fmt.  The result is:
> > > 
> > > ca_ES:	"%A, %-d %B de %Y, %T %Z"
> > > cs_CZ:	"%a<U00A0>%-d.<U00A0>%B<U00A0>%Y,<U00A0>%H:%M:%S<U00A0>%Z"
> > > hu_HU:	"%Y. %b. %-e., %A, %H:%M:%S %Z"
> > > it_CH:	"%a %-d %b %Y, %T"
> > > it_IT:	"%a %-d %b %Y, %T"
> > > nr_ZA:	"%a %-e %b %Y %T %Z"
> > > pl_PL:	"%a, %-d %b %Y, %T"
> > > ss_ZA:	"%a %-e %b %Y %T %Z"
> > > st_ZA:	"%a %-e %b %Y %T %Z"
> > > szl_PL:	"%a, %-d %b %Y, %T"
> > > tn_ZA:	"%a %-e %b %Y %T %Z"
> > > ts_ZA:	"%a %-e %b %Y %T %Z"
> > > xh_ZA:	"%a %-e %b %Y %T %Z"
> > 
> > Thank you for this survey!  Yes, this is an evidence that variable width
> > date formats may be acceptable.
> 
> These are only 13 locales out of the total 353 locales.  Please note
> that there are fixed-width date and time formats for almost all other
> locales (96.3%) except the above.

I assume that maybe other maintainers and/or translators were not aware
of "-" format modifiers, or maybe they did not care, or maybe there were
no maintainers at all.  Or maybe, simply, these are the correct
requirements of other locales.

Additionally, please note that "%-m" format (month number without any
padding) is used in 36 locales, mostly in d_fmt, many of them added only
recently (in September if I remember correctly).  I'm trying to get
some feedback whether it is problematic or not but still I don't get
any therefore I assume it is correct.

> [...]
> By the way,
> 
> 	"9:00 a.m. - 5:00 p.m."
> 
> in English is translated as
> 
> 	"9:00 e paradites - 5:00 e pasdites"
> 
> in Albanian.
> 
> So, should we include such a representation?

It is not in glibc, is it?  I think that glibc is correct regarding this.

Best regards,

Rafal
Rafal Luzynski Dec. 4, 2018, 11:48 p.m. UTC | #7 
27.11.2018 23:26 Rafal Luzynski <digitalfreak@lingonborough.com> wrote:
> [...]
> Therefore I'm asking community here.  Please provide your feedback:
> should the date and time formats provided by glibc locale data keep the
> constant width of the output (because it makes easier to display lists of
> dates and times in vertical columns, like in log files) or should it be
> allowed to provide variable width formats as well (because it follows
> the local conventions of displaying single dates, standalone, like in
> the user interface)?  Or maybe we should not worry about log files because
> they should not be localized and use only the default C locale for date
> and
> time format?  Mike, Carlos, others?

PING

Any feedback about it?

If there is no further feedback then I'll assume consensus and I'll push
the patches [1] in less than one week.  Thank you Tamuki Shoichi for your
feedback. [2] I understand that variable width dates may look bad in tabular
output like a log listing but also I assume that enforcing constant width
in date and time formats when they are displayed standalone (that means:
only one date or time) may make them unnatural.  As we can't satisfy
both requirements then I'd rather make the standalone formats look better.

Regards,

Rafal

Links:

[1] https://sourceware.org/ml/libc-alpha/2018-11/msg00164.html
[2] https://sourceware.org/ml/libc-alpha/2018-11/msg00175.html
[3] https://sourceware.org/ml/libc-alpha/2018-11/msg00041.html
[4] https://sourceware.org/ml/libc-alpha/2018-11/msg00728.html
TAMUKI Shoichi Dec. 8, 2018, 12:35 p.m. UTC | #8 
Hello Rafal,

I am sorry for this delayed reply.

From: Rafal Luzynski <digitalfreak@lingonborough.com>
Subject: Re: [RFC][PATCH] Multiple locales: Use the correct date and time formats (bug 10496, 23724).
Date: Tue, 27 Nov 2018 23:26:13 +0100 (CET)

> > By the way,
> > 
> > 	"9:00 a.m. - 5:00 p.m."
> > 
> > in English is translated as
> > 
> > 	"9:00 e paradites - 5:00 e pasdites"
> > 
> > in Albanian.
> > 
> > So, should we include such a representation?
> 
> It is not in glibc, is it?  I think that glibc is correct regarding this.

There is not such a usage in glibc, indeeed, but according to CLDR,
it seems to be used the indicator above.

http://www.unicode.org/cldr/charts/28/verify/dates/sq.html

Also, it seems that such expressions are commonly used.  For example:

https://www.chess.com/sq/al/tv

On the other hand, there is PD/MD indicator as am_pm in sq_AL locale
in glibc.  I do not know whether this is commonly used, but parhaps
this may not be a problem.

Regards,
TAMUKI Shoichi
TAMUKI Shoichi Dec. 8, 2018, 12:35 p.m. UTC | #9 
Hello Rafal,

From: Rafal Luzynski <digitalfreak@lingonborough.com>
Subject: Re: [RFC][PATCH] Multiple locales: Use the correct date and time formats (bug 10496, 23724).
Date: Wed, 5 Dec 2018 00:48:23 +0100 (CET)

> If there is no further feedback then I'll assume consensus and I'll push
> the patches [1] in less than one week.  Thank you Tamuki Shoichi for your
> feedback. [2] I understand that variable width dates may look bad in tabular
> output like a log listing but also I assume that enforcing constant width
> in date and time formats when they are displayed standalone (that means:
> only one date or time) may make them unnatural.  As we can't satisfy
> both requirements then I'd rather make the standalone formats look better.

I think that it is difficult to judge this issue unless asking the
people who develop applications with that locale, and/or who use them.

Regards,
TAMUKI Shoichi
Rafal Luzynski Dec. 21, 2018, 9:58 a.m. UTC | #10 
8.12.2018 13:35 TAMUKI Shoichi <tamuki@linet.gr.jp> wrote:
> 
> Hello Rafal,
> 
> I am sorry for this delayed reply.

Same here, I am sorry for my delay, too.

> From: Rafal Luzynski <digitalfreak@lingonborough.com>
> Subject: Re: [RFC][PATCH] Multiple locales: Use the correct date and time
> formats (bug 10496, 23724).
> Date: Tue, 27 Nov 2018 23:26:13 +0100 (CET)
> 
> > > By the way,
> > > 
> > > 	"9:00 a.m. - 5:00 p.m."
> > > 
> > > in English is translated as
> > > 
> > > 	"9:00 e paradites - 5:00 e pasdites"
> > > 
> > > in Albanian.
> > > 
> > > So, should we include such a representation?
> > 
> > It is not in glibc, is it?  I think that glibc is correct regarding
> > this.
> 
> There is not such a usage in glibc, indeeed, but according to CLDR,
> it seems to be used the indicator above.
> 
> http://www.unicode.org/cldr/charts/28/verify/dates/sq.html

I am looking at this page:

http://st.unicode.org/cldr-apps/v#/sq/Gregorian/

and indeed, this does not mention PD and MD but does mention "p.d." and
"m.d.".  So I believe these shortcuts are known in Albania, this is not
anything artificially invented by glibc developers.

> Also, it seems that such expressions are commonly used.  For example:
> 
> https://www.chess.com/sq/al/tv

Thank you, this is a valuable feedback.

> On the other hand, there is PD/MD indicator as am_pm in sq_AL locale
> in glibc.  I do not know whether this is commonly used, but parhaps
> this may not be a problem.

Yes.  I believe it has been added for good reasons.  Also nobody
complained about it so I am not going to touch this.  Also I think
that PD and MD are good for clock widgets, "e paradites" and "e pasdites"
may be too long to fit in the limited screen space.

The bugs I am trying to fix are about the missing AM/PM indicator and
about wrong date format (that's spotted by myself, mixing numerical
format with words looks very suspicious), there was no complain about how
the AM/PM indicator looks.

I have few Albanian friends and I have asked them for some feedback.
They are generally OK with these changes I'm proposing here regarding
their language.  Also I hope that if I do anything wrong they will
contact me quickly.

Regards,

Rafal
TAMUKI Shoichi Dec. 22, 2018, 10:43 a.m. UTC | #11 
Hello Rafal,

From: Rafal Luzynski <digitalfreak@lingonborough.com>
Subject: Re: [RFC][PATCH] Multiple locales: Use the correct date and time formats (bug 10496, 23724).
Date: Fri, 21 Dec 2018 10:58:39 +0100 (CET)

> > There is not such a usage in glibc, indeeed, but according to CLDR,
> > it seems to be used the indicator above.
> > 
> > http://www.unicode.org/cldr/charts/28/verify/dates/sq.html
> 
> I am looking at this page:
> 
> http://st.unicode.org/cldr-apps/v#/sq/Gregorian/
> 
> and indeed, this does not mention PD and MD but does mention "p.d." and
> "m.d.".  So I believe these shortcuts are known in Albania, this is not
> anything artificially invented by glibc developers.

OK.  I agreed.

> > On the other hand, there is PD/MD indicator as am_pm in sq_AL locale
> > in glibc.  I do not know whether this is commonly used, but parhaps
> > this may not be a problem.
> 
> Yes.  I believe it has been added for good reasons.  Also nobody
> complained about it so I am not going to touch this.  Also I think
> that PD and MD are good for clock widgets, "e paradites" and "e pasdites"
> may be too long to fit in the limited screen space.
> 
> The bugs I am trying to fix are about the missing AM/PM indicator and
> about wrong date format (that's spotted by myself, mixing numerical
> format with words looks very suspicious), there was no complain about how
> the AM/PM indicator looks.
> 
> I have few Albanian friends and I have asked them for some feedback.
> They are generally OK with these changes I'm proposing here regarding
> their language.  Also I hope that if I do anything wrong they will
> contact me quickly.

Agreed.

Regards,
TAMUKI Shoichi
diff mbox series

Patch

From 3ad4684e4546d89d85c9434090b3950db95e34de Mon Sep 17 00:00:00 2001
From: Rafal Luzynski <digitalfreak@lingonborough.com>
Date: Tue, 9 Oct 2018 01:15:33 +0200
Subject: [PATCH] sq_AL: Use the correct date and time formats (bug 10496,
 23724).

Albanian locale uses the 12-hour clock but some time formats did not
use any AM/PM indicator making the time ambiguous.  This commit adds
"%p" wherever it was missing.

It also sets the correct date format because the old "%Y-%b-%d" produced
rather weird results like "2018-Sht-28".

All time formats come from CLDR but as few changes have been introduced
by this commit as possible.  Some articles from MSDN and other available
online sources have been also taken into account.

	[BZ #10496]
	[BZ #23724]
	* localedata/locales/sq_AL (t_fmt): Set to "%l:%M:%S.%p %Z".
	(t_fmt_ampm): Likewise.
	(d_t_fmt): Set to "%a %-d %b %Y %l:%M:%S.%p".
	(date_fmt): Add, set to "%a %-d %b %Y %l:%M:%S.%p %Z".
	(d_fmt): Set to "%-d.%-m.%y".
---
 localedata/locales/sq_AL | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/localedata/locales/sq_AL b/localedata/locales/sq_AL
index 9cec37a..a90251f 100644
--- a/localedata/locales/sq_AL
+++ b/localedata/locales/sq_AL
@@ -303,16 +303,19 @@  mon         "janar";/
 am_pm       "PD";"MD"
 %
 % Appropriate date and time representation
-d_t_fmt     "%Y-%b-%d %I.%M.%S.%p %Z"
+d_t_fmt     "%a %-d %b %Y %l:%M:%S.%p"
+%
+% Appropriate date representation for date(1)
+date_fmt    "%a %-d %b %Y %l:%M:%S.%p %Z"
 %
 % Appropriate date representation
-d_fmt       "%Y-%b-%d"
+d_fmt       "%-d.%-m.%y"
 %
 % Appropriate time representation
-t_fmt       "%I.%M.%S. %Z"
+t_fmt       "%l:%M:%S.%p %Z"
 %
 % Appropriate 12 h time representation (%r)
-t_fmt_ampm  "%I.%M.%S.%p %Z"
+t_fmt_ampm  "%l:%M:%S.%p %Z"
 week 7;19971130;1
 first_weekday 2
 END LC_TIME
-- 
2.7.5