Re: [glib][GDateTime] API and string freeze break request

2018-02-14 Thread Rafal Luzynski
12.02.2018 22:38 mcatanz...@gnome.org wrote:
>
>
> On Mon, Feb 12, 2018 at 1:54 PM, Rafal Luzynski
>  wrote:
> > Thank you. So here I have the feedback from the i18n team, as
> > Alexandre said I don't need an approval yet. What about any feedback
> > from the documentation and release team? Maybe I don't need an
> > approval as well?
>
> You do need two approvals from release-team. This is your first,
> [...]

Again, thank you Michael for your approval and review.

Who will give me a second approval and a second review?
I think this change is necessary because as glibc has introduced
nominative/genitive cases (in those languages which distinguish them)
glib now displays a genitive case everywhere. Which is usually correct
but sometimes not, for those exceptional cases we need "%OB".

Links:

https://bugzilla.gnome.org/show_bug.cgi?id=749206
https://gitlab.gnome.org/GNOME/libdazzle/issues/8
https://gitlab.gnome.org/GNOME/gnome-todo/issues/147

Regards,

Rafal
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [glib][GDateTime] API and string freeze break request

2018-02-12 Thread Rafal Luzynski
12.02.2018 22:38 mcatanz...@gnome.org wrote:
>
>
> On Mon, Feb 12, 2018 at 1:54 PM, Rafal Luzynski
>  wrote:
> > Thank you. So here I have the feedback from the i18n team, as
> > Alexandre said I don't need an approval yet. What about any feedback
> > from the documentation and release team? Maybe I don't need an
> > approval as well?
>
> You do need two approvals from release-team. This is your first,

Thank you.

> because I assume this change is unlikely to break application unless
> they use the new API.

Define "break". Sure, under no condition it causes any crash, sigsegv,
etc. Only makes some applications (dates, calendars) look ugly if this
patch is not applied or if it is applied incorrectly. As much as possible
I'm trying to address all affected places and I hope to manage this task.
Although I'll appreciate any help.

Regards,

Rafal
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [glib][GDateTime] API and string freeze break request

2018-02-12 Thread mcatanzaro
On Mon, Feb 12, 2018 at 1:54 PM, Rafal Luzynski 
 wrote:
Thank you. So here I have the feedback from the i18n team, as 
Alexandre said I don't need an approval yet. What about any feedback 
from the documentation and release team? Maybe I don't need an 
approval as well?


You do need two approvals from release-team. This is your first, 
because I assume this change is unlikely to break application unless 
they use the new API.


Michael

___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [glib][GDateTime] API and string freeze break request

2018-02-12 Thread Rafal Luzynski
12.02.2018 18:11 Piotr Drąg  napisał(a):
>
>
> 2018-02-08 1:22 GMT+01:00 Rafal Luzynski :
> > * String changes: new forms of month names will have to be added.
> > Bad news: for all (really all) languages. Good news: in 90% of languages
> > it will be just a copy of existing month names; also these month names
> > will be actually used only on those systems which do not yet provide
> > them (the latest glibc 2.27 supports all, BSD partially). Does anybody
> > have a superpower to insert the month names if the translators are
> > inactive?
> >
>
> I’m, obviously, very much in favor of this change, as should be other
> translators of affected languages.

Thank you. So here I have the feedback from the i18n team, as Alexandre
said I don't need an approval yet. What about any feedback from the
documentation and release team? Maybe I don't need an approval as well?

> I suppose we could review and push a patch that adds translations for
> month names in less active languages, especially since it should be a
> relatively simple import of glibc/CLDR data.

This would be perfect, if needed.

Regards,

Rafal
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [glib][GDateTime] API and string freeze break request

2018-02-12 Thread Piotr Drąg
2018-02-08 1:22 GMT+01:00 Rafal Luzynski :
> * String changes: new forms of month names will have to be added.
> Bad news: for all (really all) languages. Good news: in 90% of languages
> it will be just a copy of existing month names; also these month names
> will be actually used only on those systems which do not yet provide
> them (the latest glibc 2.27 supports all, BSD partially). Does anybody
> have a superpower to insert the month names if the translators are
> inactive?
>

I’m, obviously, very much in favor of this change, as should be other
translators of affected languages.

I suppose we could review and push a patch that adds translations for
month names in less active languages, especially since it should be a
relatively simple import of glibc/CLDR data.

Best regards,

-- 
Piotr Drąg
https://piotrdrag.fedorapeople.org
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [glib][GDateTime] API and string freeze break request

2018-02-08 Thread Rafal Luzynski
8.02.2018 11:08 Alexandre Franke  wrote:
>
> [...] We would appreciate if you could give us an idea of the
> number of new strings.

24 strings, which is the number of months in year in Gregorian calendar
multiplied by 2 (full names and abbreviated names) while in most of
the languages they will be just a copy of existing month names.
Although as the patch is not yet accepted and can be discussed I'd prefer
an option where due to the context change 24 existing strings are split
into 48 strings to avoid the confusion why the translators having provided
"month names" must again provide "month names as used in dates".

> > This freeze break request will be followed by more freeze break
> > requests (string only):
>
> Depending on when that happens, you may still not be in string freeze yet.

I'm currently reviewing my old patches and indeed it seems that some
of them do not need to wait for glib2 patches and can be accepted as
soon as the maintainers agree.

Regards,

Rafal
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [glib][GDateTime] API and string freeze break request

2018-02-08 Thread Alexandre Franke
Hi,

On Thu, Feb 8, 2018 at 1:22 AM, Rafal Luzynski
 wrote:
> * String changes: new forms of month names will have to be added.
> Bad news: for all (really all) languages. Good news: in 90% of languages
> it will be just a copy of existing month names; also these month names
> will be actually used only on those systems which do not yet provide
> them (the latest glibc 2.27 supports all, BSD partially). Does anybody
> have a superpower to insert the month names if the translators are
> inactive?

Thanks for the heads up. We are currently in string change
announcement period and the freeze has not started yet, so you don’t
need approval. We would appreciate if you could give us an idea of the
number of new strings.

> This freeze break request will be followed by more freeze break
> requests (string only):

Depending on when that happens, you may still not be in string freeze yet.


-- 
Alexandre Franke
GNOME Hacker & Foundation Director
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


[glib][GDateTime] API and string freeze break request

2018-02-07 Thread Rafal Luzynski
I'd like to ask for the freeze break approval in order to add
a missing functionality as described in bug 749206. [1]

Also, as the patches are not yet accepted and committed, I'd
like to ask for more reviews and to commit.


Planned changes
===

* API: g_date_time_format() function will support the new format
specifiers: %OB, %Ob, and %Oh. Also the meaning of %B, %b, %h will
be slightly changed (actually: will be specified more precisely).

* String changes: new forms of month names will have to be added.
Bad news: for all (really all) languages. Good news: in 90% of languages
it will be just a copy of existing month names; also these month names
will be actually used only on those systems which do not yet provide
them (the latest glibc 2.27 supports all, BSD partially). Does anybody
have a superpower to insert the month names if the translators are
inactive?


Why this change is important and why it is so late
==

This change follows the latest change in glibc strftime() function.
[2] [3] The aim of the change is to support two grammatical cases
of month names, as required by some eastern European languages.
This is included in the most recent glibc 2.27 released on February 1
(1 week ago) while the change has been finally accepted and applied
upstream only on January 22 (2.5 weeks ago). As a result,
g_date_strftime() (being just a wrapper for stftime() ) supports the
new format specifiers already if its underlying platform's C library
is glibc 2.27. g_date_time_format() currently does not support %OB,
%Ob, and %Oh format specifiers while it has already switched to
displaying %B, %b, %h in a genitive case (in selected languages only)
which is correct in most cases but incorrect in few, and that's why
we need this change. The patch falls back to the underlying platform
if it supports all forms of the month names correctly (glibc 2.27 only)
and provides a correct implementation for the platforms which support
the feature incompletely (BSD) or incorrectly (older glibc). There is
also another patch which provides the same functionality for MS Windows.

If these patches are not applied GNOME will remain in the middle of
transition.


Followups
=

This freeze break request will be followed by more freeze break
requests (string only):

* in gnome-shell (calendar widget), [4] [5]
* in gnome-calendar, [6]
* in shotwell (not yet reported anywhere)

Thanks in advance,

Rafal


[1] https://bugzilla.gnome.org/show_bug.cgi?id=749206
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=10871
[3] https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
[4] https://bugzilla.gnome.org/show_bug.cgi?id=781329
[5] https://bugzilla.gnome.org/show_bug.cgi?id=780957
[6] https://gitlab.gnome.org/GNOME/gnome-calendar/issues/125
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n