[RFC][PATCH v8 08/16] Let alternative month names be a copy of regular ones (bug 10871).

[RFC][PATCH v8 08/16] Let alternative month names be a copy of regular ones (bug 10871).

[Rafal Luzynski]

If alt_mon definition is missing from a locale then let it be
a copy of mon array.  Majority of languages do not need this feature
so let us accept the locale definition file without alt_mon and
provide the same content as mon when software requires alt_mon.

[BZ #10871]
* locale/programs/ld-time.c: alternative month names are a copy of
mon if not provided explicitly.
---
 locale/programs/ld-time.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/locale/programs/ld-time.c b/locale/programs/ld-time.c
index 66a9e30..a6bf2b1 100644
--- a/locale/programs/ld-time.c
+++ b/locale/programs/ld-time.c
@@ -960,6 +960,14 @@ time_read (struct linereader *ldfile, struct localedef_t
*result,
 	    lr_error (ldfile, _("\
 %1$s: definition does not end with `END %1$s'"), "LC_TIME");
 	  lr_ignore_rest (ldfile, now->tok == tok_lc_time);
+
+	  /* If alt_mon is missing then let it be a copy of mon.  */
+	  if (!ignore_content && !time->alt_mon_defined)
+	    {
+	      memcpy (time->alt_mon, time->mon, sizeof (time->mon));
+	      memcpy (time->walt_mon, time->wmon, sizeof (time->wmon));
+	      time->alt_mon_defined = 1;
+	    }
 	  return;
 
 	default:
-- 
2.7.5

Re: [RFC][PATCH v8 08/16] Let alternative month names be a copy of regular ones (bug 10871).

[Zack Weinberg]

On 06/28/2017 06:05 AM, Rafal Luzynski wrote:
> If alt_mon definition is missing from a locale then let it be
> a copy of mon array.  Majority of languages do not need this feature
> so let us accept the locale definition file without alt_mon and
> provide the same content as mon when software requires alt_mon.

This seems a reasonable policy, but it should be documented.

> +	  /* If alt_mon is missing then let it be a copy of mon.  */

"Let it be <thing>" is unusual in English, although it does get used in
formal mathematical writing.  Instead

  /*  If alt_mon was not specified, make it a copy of mon.  */

zw

Re: [RFC][PATCH v8 08/16] Let alternative month names be a copy of regular ones (bug 10871).

[Joseph Myers]

On Mon, 3 Jul 2017, Zack Weinberg wrote:

> On 06/28/2017 06:05 AM, Rafal Luzynski wrote:
> > If alt_mon definition is missing from a locale then let it be
> > a copy of mon array.  Majority of languages do not need this feature
> > so let us accept the locale definition file without alt_mon and
> > provide the same content as mon when software requires alt_mon.
> 
> This seems a reasonable policy, but it should be documented.

It's essentially *required* (by the fact that we suppose building locale 
definition sources that follow existing versions of POSIX, which won't use 
a feature that's only added in a bug tagged issue8, i.e. for the next 
major revision of POSIX), and putting any other text in there clearly be 
worse than copying mon.  (It still makes sense to document this 
consequence of supporting existing POSIX versions, if there's somewhere 
suitable to document it.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC][PATCH v8 08/16] Let alternative month names be a copy of regular ones (bug 10871).

[Rafal Luzynski]

Hello,

It's time to get my hands dirty with this again:

4.07.2017 01:12 Joseph Myers <joseph@codesourcery.com> wrote:
>
>
> On Mon, 3 Jul 2017, Zack Weinberg wrote:
>
> > On 06/28/2017 06:05 AM, Rafal Luzynski wrote:
> > > If alt_mon definition is missing from a locale then let it be
> > > a copy of mon array. Majority of languages do not need this feature
> > > so let us accept the locale definition file without alt_mon and
> > > provide the same content as mon when software requires alt_mon.
> >
> > This seems a reasonable policy, but it should be documented.
>
> It's essentially *required* (by the fact that we suppose building locale
> definition sources that follow existing versions of POSIX, which won't use
> a feature that's only added in a bug tagged issue8, i.e. for the next
> major revision of POSIX), and putting any other text in there clearly be
> worse than copying mon. (It still makes sense to document this
> consequence of supporting existing POSIX versions, if there's somewhere
> suitable to document it.)

Zack, Joseph, please explain where should I document:

* that if alt_mon is missing from the locale definition file then its
  contents is copied from mon (and ab_alt_mon is copied from abmon as well)
* all other changes?

Regards,

Rafal

Re: [RFC][PATCH v8 08/16] Let alternative month names be a copy of regular ones (bug 10871).

[Rafal Luzynski]

3.07.2017 23:33 Zack Weinberg <zackw@panix.com> wrote:
>
>
> On 06/28/2017 06:05 AM, Rafal Luzynski wrote:
> > If alt_mon definition is missing from a locale then let it be
> > a copy of mon array. Majority of languages do not need this feature
> > so let us accept the locale definition file without alt_mon and
> > provide the same content as mon when software requires alt_mon.
>
> This seems a reasonable policy, but it should be documented.

OK but where is the documentation of the locale data file?
I can't find it.

> > + /* If alt_mon is missing then let it be a copy of mon. */
>
> "Let it be <thing>" is unusual in English, although it does get used in
> formal mathematical writing. Instead
>
> /* If alt_mon was not specified, make it a copy of mon. */

Thank you.  If I didn't say it before then I must say now that as
a non-English native speaker I will need some proofreading of the
natural language texts, for example the documentation.

While at this, I'm not sure if I named the symbols for the abbreviated
alternative month names correctly:

locale data source file label: "ab_alt_mon"
macros in locale/langinfo.h: _NL_ABALTMON_1 ...12, _NL_WABALTMON_1 ...12

Compare this with alternative month names (my new feature) and abbreviated
month names (already existing):

locale data source file label: "alt_mon", "abmon"
macros in locale/langinfo.h: ALTMON_1 ...12, _NL_WALTMON_1 ...12,
ABMON_1 ...12, _NL_WABMON_1 ...12

Sorry if it looks nit-picky again but I'm aware that once the decision
is made it will be difficult to undo it.

Regards,

Rafal