Hi, Alice,

Looks quite good. Code-wise, only few minor comments.

Main issue is - this looks rather scary for 11.8,
let's try to reduce incompatibility as much as possible:

* do it in 12.3 only
* do not change %M, introduce %B for formatting names
* I don't know what to do with sr_RS, it's an incompatibility,
  but it's a strictly a bug. Let's keep your solution.

otherwise - all good, only minor stylisic changes.

Regards,
Sergei
Chief Architect, MariaDB Server
and [email protected]

On Feb 06, Alice Sherepa wrote:
> commit 2d033939e0f
> Author: Alice Sherepa <[email protected]>
> Date:   Tue Feb 3 09:35:31 2026 +0100
> 
>     MDEV-38520 Add month name formatting (%M shows month names in genitive 
> case)

explain here where the names are coming from. that unicode.org
distinguishes between "formatting" and "standalone" names,
and that the data are taken from <this url>

> 
> diff --git a/mysql-test/main/locale.test b/mysql-test/main/locale.test
> index a0224fe072a..597428dfdc6 100644
> --- a/mysql-test/main/locale.test
> +++ b/mysql-test/main/locale.test
> @@ -241,3 +241,20 @@ SET lc_messages=DEFAULT;
>  --echo #
>  --echo # End of 10.11 tests
>  --echo #
> +
> +
> +#
> +# MDEV-38520 Add month name formatting (%M shows month names in genitive 
> case) 
> +#

let's have a header in the result file too,
that is, please use --echo #

> +
> +SET lc_time_names=uk_UA;
> +SELECT monthname('2001-10-01'), monthname('2001-02-15'), 
> monthname('2001-03-30');
> +SELECT date_format('2026-10-01','%d %M %Y'), date_format('2026-08-24','%d %M 
> %Y'), date_format('2026-01-22','%d %M %Y');
> +
> +SET lc_time_names=be_BY;
> +SELECT date_format('2026-10-01','%d %M %Y'), date_format('2026-08-24','%d %M 
> %Y'), date_format('2026-01-22','%d %M %Y');
> +
> +SET lc_time_names=eu_ES;
> +SELECT date_format('2026-04-16','%d %M %Y'), date_format('2026-08-24','%d %M 
> %Y'), date_format('2026-01-22','%d %M %Y');
> +
> +SET lc_time_names=DEFAULT;
> diff --git a/sql/sql_locale.cc b/sql/sql_locale.cc
> index 706d819ddc3..3117510b663 100644
> --- a/sql/sql_locale.cc
> +++ b/sql/sql_locale.cc
> @@ -250,7 +255,9 @@ MY_LOCALE my_locale_ar_SY
>  
>  /***** LOCALE BEGIN be_BY: Belarusian - Belarus *****/
>  static const char *my_locale_month_names_be_BY[13] = 
> - 
> {"Студзень","Люты","Сакавік","Красавік","Травень","Чэрвень","Ліпень","Жнівень","Верасень","Кастрычнік","Лістапад","Снежань",
>  NullS };
> + 
> {"студзень","люты","сакавік","красавік","травень","чэрвень","ліпень","жнівень","верасень","кастрычнік","лістапад","снежань",
>  NullS };
> +static const char *my_locale_month_names_be_BY_formatting[13] = 
> + 
> {"студзеня","лютага","сакавіка","красавіка","траўня","чэрвеня","ліпеня","жніўня","верасня","кастрычніка","лістапада","снежня",
>  NullS };
>  static const char *my_locale_ab_month_names_be_BY[13] = 
>   {"Стд","Лют","Сак","Крс","Тра","Чэр","Ліп","Жнв","Врс","Кст","Ліс","Снж", 
> NullS };
>  static const char *my_locale_day_names_be_BY[8] = 

try `git show` in this branch, you'll see a lot of red at the end of
many lines meaning invisible end-of-line spaces. please, remove them.

> @@ -367,6 +381,8 @@ static const char *my_locale_ab_day_names_cs_CZ[8] =
>   {"Po","Út","St","Čt","Pá","So","Ne", NullS };
>  static TYPELIB my_locale_typelib_month_names_cs_CZ = 
>   CREATE_TYPELIB_FOR(my_locale_month_names_cs_CZ);
> +static TYPELIB my_locale_typelib_month_names_cs_CZ_fomrmatting = 

fomrmatting

> + CREATE_TYPELIB_FOR(my_locale_month_names_cs_CZ_formatting); 
>  static TYPELIB my_locale_typelib_ab_month_names_cs_CZ = 
>   CREATE_TYPELIB_FOR(my_locale_ab_month_names_cs_CZ);
>  static TYPELIB my_locale_typelib_day_names_cs_CZ = 
> @@ -1582,7 +1657,9 @@ MY_LOCALE my_locale_ru_RU
>  
>  /***** LOCALE BEGIN ru_UA: Russian - Ukraine *****/
>  static const char *my_locale_month_names_ru_UA[13] = 
> - 
> {"Январь","Февраль","Март","Апрель","Май","Июнь","Июль","Август","Сентябрь","Октябрь","Ноябрь","Декабрь",
>  NullS };
> + 
> {"январь","февраль","март","апрель","май","июнь","июль","август","сентябрь","октябрь","ноябрь","декабрь",
>  NullS };
> +static const char *my_locale_month_names_ru_UA_formatting[13] = 
> + 
> {"января","февраля","марта","апреля","мая","июня","июля","августа","сентября","октября","ноября","декабря",
>  NullS };

do they even need to be defined separately?
e.g. my_locale_es_PY (Spanish - Paraguay)
uses &my_locale_typelib_month_names_es_ES
and does not define my_locale_typelib_month_names_es_PY
which would've been identical to my_locale_typelib_month_names_es_ES.

>  static const char *my_locale_ab_month_names_ru_UA[13] = 
>   {"Янв","Фев","Мар","Апр","Май","Июн","Июл","Авг","Сен","Окт","Ноя","Дек", 
> NullS };
>  static const char *my_locale_day_names_ru_UA[8] = 
> diff --git a/sql/sql_locale.h b/sql/sql_locale.h
> index 6bde0f5e000..f0ab2d6bef4 100644
> --- a/sql/sql_locale.h
> +++ b/sql/sql_locale.h
> @@ -45,14 +46,14 @@ class MY_LOCALE
>    MY_LOCALE(uint number_par,
>              const Lex_ident_locale &name_par,
>              const char *descr_par, bool is_ascii_par,
> -            TYPELIB *month_names_par, TYPELIB *ab_month_names_par,
> +            TYPELIB *month_names_par, TYPELIB *month_names_par_formatting, 
> TYPELIB *ab_month_names_par,

please, reformat to avoid lines longer than 80 chars

>              TYPELIB *day_names_par, TYPELIB *ab_day_names_par,
>              uint max_month_name_length_par, uint max_day_name_length_par,
>              uint decimal_point_par, uint thousand_sep_par,
>              const char *grouping_par, MY_LOCALE_ERRMSGS *errmsgs_par) :
>      number(number_par),
>      name(name_par), description(descr_par), is_ascii(is_ascii_par),
> -    month_names(month_names_par), ab_month_names(ab_month_names_par),
> +    month_names(month_names_par), 
> month_names_formatting(month_names_par_formatting), 
> ab_month_names(ab_month_names_par),

and here.

>      day_names(day_names_par), ab_day_names(ab_day_names_par),
>      max_month_name_length(max_month_name_length_par),
>      max_day_name_length(max_day_name_length_par),
_______________________________________________
developers mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to