After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 658686 - allow capitalized weekday on calendar popup
allow capitalized weekday on calendar popup
Status: RESOLVED WONTFIX
Product: gnome-shell
Classification: Core
Component: calendar
3.1.x
Other Linux
: Normal minor
: ---
Assigned To: David Zeuthen (not reading bugmail)
gnome-shell-maint
Depends on: 658807
Blocks:
 
 
Reported: 2011-09-09 23:40 UTC by Luc Pi
Modified: 2020-04-24 15:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Luc Pi 2011-09-09 23:40:12 UTC
in 

#. Translators: This is the date format to use when the calendar popup is
#. * shown - it is shown just below the time in the shell (e.g. "Tue 9:29 AM").
#.
#: ../js/ui/dateMenu.js:213
msgid "%A %B %e, %Y"


strftime allows %a (abbreviated) %A (full weekday) %^A (full weekday all uppercase), but not full weekdays capitalized. English weekdays are always capitalized, but not in French for example. It seems this is missing from strftime.


Suggestion:

- allow a new a '*' identifier: "%*A %B %e, %Y"
- parse it out
- expand the format string
- turn the first char to upper case if requested


or just:

- capitalize the first char of the resulting string
Comment 1 André Klapper 2011-09-12 08:48:58 UTC
Why not fix strftime instead of working around?
Comment 2 Luc Pi 2011-09-12 09:09:17 UTC
Good question André! :) I am unsure what happened in my brain at that time, I am feeling confused now.

Where strftime comes from? Is it glibc?
Comment 3 Florian Müllner 2011-09-12 10:08:46 UTC
(In reply to comment #2)
> Where strftime comes from? Is it glibc?

Yes, but we are not using strftime :-)

We us g_date_time_format() (from glib) for both the clock and date strings.
Comment 4 Rui Matos 2011-09-12 10:38:46 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Where strftime comes from? Is it glibc?
> 
> Yes, but we are not using strftime :-)
> 
> We us g_date_time_format() (from glib) for both the clock and date strings.

Which in turn uses the glibc translations since this commit:

http://git.gnome.org/browse/glib/commit/?h=glib-2-30&id=527dc867225ae815356d2d1a72213abe981bd067
Comment 5 Florian Müllner 2011-09-12 10:54:59 UTC
Yes, but that's irrelevant for the parsing of the format string (which is done in glib)
Comment 6 Luc Pi 2011-09-12 11:15:01 UTC
OK I open a new report against glib, that blocks this one.

Thank You!
Comment 7 Luc Pi 2011-09-12 11:17:04 UTC
btw, Florian,


it would be a good thing if there was translator comments to refer to the right format documentation. At least this one makes explicit reference to strftime

#. Translators: this is a time format string followed by a date.
#. If applicable, replace %X with a strftime format valid for your
#. locale, without seconds.

Can you handle it, or do you want a separate report?
Comment 8 Florian Müllner 2011-09-12 12:36:29 UTC
(In reply to comment #7)
> it would be a good thing if there was translator comments to refer to the right
> format documentation. At least this one makes explicit reference to strftime
> 
> #. Translators: this is a time format string followed by a date.
> #. If applicable, replace %X with a strftime format valid for your
> #. locale, without seconds.
> 
> Can you handle it, or do you want a separate report?

To be honest, I'm not convinced that this is a good idea. We us the Date.toLocaleFormat[0] Javascript function to format time and date (which is documented to use strftime - the comment was correct at the time of writing); however, mozilla's implementation is buggy when handling unicode characters[1], so we replaced it under the hood with our own implementation (which uses g_date_time_format()). It is by all means an implementation detail, and might change again when mozilla fixes their implementation - having translators rely on a specific implementation sounds a bit scary ;-)

If we think that the clock and date should use sentence capitalization (for the record: I think they should), then modifying the returned string from code does not sound too bad ...


[0] https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/toLocaleFormat
[1] https://bugzilla.gnome.org/show_bug.cgi?id=643350
Comment 9 Luc Pi 2011-09-13 18:09:51 UTC
(In reply to comment #8)

> If we think that the clock and date should use sentence capitalization (for the
> record: I think they should), then modifying the returned string from code does
> not sound too bad ...

So should this issue continues this way?

At [1] Dan Winship suggests to add a string "translate this string to 'yes' if we should capitalize the first letter of the date string" 

[1] https://bugzilla.gnome.org/show_bug.cgi?id=658807#c3
Comment 10 Bastien Nocera 2014-11-07 13:55:32 UTC
I think it should be fixed in glib instead, otherwise we'll keep reinventing the wheel (say, in gnome-calendar, Evolution, etc.).
Comment 11 André Klapper 2020-04-24 15:10:21 UTC
If this is still a valid issue (cannot find that string in gnome-shell git master), then it should be filed as a new ticket against glib: https://gitlab.gnome.org/GNOME/glib/issues/ - thanks a lot!