GNOME Bugzilla – Bug 781329
[PATCH] Make month and month-year formats translatable
Last modified: 2018-02-08 16:49:43 UTC
Created attachment 349879 [details] [review] Make month and month-year formats translatable Currently when displaying a month for a different year the code tries to figure out the correct month-year order from gtk+. As a result it can display the month name and the year number in one of only two formats: month-space-year or year-space-month. This may be insufficient because: - some languages (Friulian? Spanish? Catalan? Italian? Portuguese?) may require some preposition between them rather than just a space, e.g., "dal", "de", "di", etc. - some languages don't use spaces (East Asian?), - some languages don't have month names and prefer numbers, etc. So my suggestion is to leave the choice of the format to the translators. As a side effect the code is simpler.
Review of attachment 349879 [details] [review]: Is there a corresponding patch in GTK+? IMHO we should be consistent with our toolkit here. ::: js/ui/calendar.js @@ -379,3 @@ - // Find the ordering for month/year in the calendar heading - this._headerFormatWithoutYear = '%B'; - switch (gtk30_('calendar:MY')) { Both that method and the Gettext_gtk30 import are now unused, so please remove them
Thank you for your review. (In reply to Florian Müllner from comment #1) > Review of attachment 349879 [details] [review] [review]: > > Is there a corresponding patch in GTK+? IMHO we should be consistent with > our toolkit here. I'm not sure what part of GTK+ you are talking about. AFAIK there is nothing in GTK+ which formats a month name standalone or a month name with a year number, both without a day number. Otherwise if there was I would have filed a bug report and submitted a patch already. :-) > ::: js/ui/calendar.js > @@ -379,3 @@ > - // Find the ordering for month/year in the calendar heading > - this._headerFormatWithoutYear = '%B'; > - switch (gtk30_('calendar:MY')) { > > Both that method and the Gettext_gtk30 import are now unused, so please > remove them Do you mean that since this patch removes the gtk30_ call then it should also remove Gettext_gtk30 import and gtk30_ alias?
Created attachment 365609 [details] [review] Make month and month-year formats translatable (v2) I hope this is what you meant.
Comment on attachment 365609 [details] [review] Make month and month-year formats translatable (v2) That's what he meant :). But FWIW, GTK+ does define these calendar:MY/YM strings for a reason, more nominally letting translators specify whether the GtkCalendar UI should present year before month or the opposite: https://git.gnome.org//browse/gtk+/tree/gtk/gtkcalendar.c#n773 Even though it's good to have consistence (and it's left up to the translator(s) this way), we're definitely not forced to a binary option here. I will set as "reviewed" and let fmuellner make up his mind.
Thank you, Carlos. (In reply to Carlos Garnacho from comment #4) > [...] > But FWIW, GTK+ does define these calendar:MY/YM strings for a reason, more > nominally letting translators specify whether the GtkCalendar UI should > present year before month or the opposite: > https://git.gnome.org//browse/gtk+/tree/gtk/gtkcalendar.c#n773 That's what I meant: it's more for the order of widgets rather than the display format. It's insufficient to say that the month should be before the year (or the other way round) because, for example, AFAIK for Spanish language the format should be "%B de %Y" eventually rendering something like "enero de 2018". (Sorry if I'm wrong, I can't speak Spanish, but maybe that's required in other languages.) Japanese may prefer numbers ("%m %Y") etc.
Now taking the freeze period into account I think that we should mark this patch obsolete and merge it with bug 780957 immediately. "%B %Y" is no longer a correct format, "%OB %Y" is required now.
I’d probably be best if you opened a merge request at https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests for this.
(In reply to Rafal Luzynski from comment #6) > I think that we should [...] merge it with bug 780957 Sounds good to me.