My locale short date/time preference is set as follows (English - Canada):
2024-06-04
10:40:31
Nautilus list view of files and folders shows the date format as follows:
05/17/2024 15:52
Please make nautilus respect my regional GNOME settings or at least provide an option in preferences where this can be modified by the user.
Thank you.
How the date_to_str () code in src/nautilus-date-utilities.c works, it temporarily switches the locale to your date/time locale and that makes the code use the translated format strings for that locale. The issue is there is no Canadian English translation for these format strings; the translation is incomplete.
For example looking at the Slovanian translation (the only one 100% complete), it has translations for the format strings in the src/nautilus-date-utilities.c code: po/sl.po · main · GNOME / Files · GitLab
The Canadian English translation does not: po/en_CA.po · main · GNOME / Files · GitLab
I’m not sure how translation is done but it’s documented here: TranslationProject - GNOME Wiki!. AFAIK the fix for this issue is to add translation for the format strings in src/nautilus-date-utilities.c code.
Thank you for this comprehensive response. I’ll try to submit an updated translation for this project.
Correct me if I’m wrong, but it seems that if the “Detailed” preference is chosen, the nautilus-date-utilities.c file explicitly defines the format as %m/%d/%Y %H:%M. If this is the case, Nautilus is in fact not respecting the date & time format from the users locale preference.
From src/nautilus-date-utilities.c · main · GNOME / Files · GitLab
if (use_short_format && detailed_date)
{
if (use_24_hour)
{
/* Translators: date and time in 24h format,
* i.e. "12/31/2023 23:59" */
/* xgettext:no-c-format */
format = _("%m/%d/%Y %H:%M");
}
else
{
/* Translators: date and time in 12h format,
* i.e. "12/31/2023 11:59 PM" */
/* xgettext:no-c-format */
format = _("%m/%d/%Y %I:%M %p");
}
}
Here is a screenshot showing my locale settings and system preferences, as well as Nautilus’ explicit format.
The extent of my development experience is Python scripting for my role as a network engineer, so I’m quite non-savvy in this context. That being said, previous discussions on this topic suggest that Nautilus is not using locale settings because the time often contains seconds (%S), which has been determined undesirable. Is there a constraint that would prevent Nautilus from using just the short date format (d_fmt) and ignoring the time format (t_fmt) from locale settings?
So, you’ve locally modified your locale to use ISO dates?
What nautilus does is take the LC_TIME locale and look up the message catalog for that locale. Nautilus needs translators for each language to provide their own format strings. You’re apparently using en_US for LC_TIME, so it uses the US English translation of the string (which is the original).
I’m not entirely sure why the original format string doesn’t use %x, but that’s why your change doesn’t take effect. This normally isn’t an issue (beyond extra work for translators), except when you want a date format isn’t provided by an existing locale.
Related issue: The "Detailed" Date and Time doesn't follow Locale (#3352) · Issues · GNOME / Files · GitLab
Yes, I customize my locale to adjust the first weekday to be Monday and my date formats to be ISO.
I saw your response here and your comment on the Gitlab issue after I had just edited my previous response, where I added a statement that effectively echoes your suggestion on the Gitlab issue. Great suggestion, and I hope it gets some traction.
but it’s using the _ function which looks up the string in the translation file
That’s right. And additionally it doesn’t just take any translation, but specifically the translation for the LC_TIME locale, if the user explicitly set a different locale for time than for regular text.
@antoniof - since this is a more appropriate medium for support, I am going to mirror/echo my latest post from the github discussion.
You stated…
But, you can always create a custom locale and even provide custom translations.
So, in that sense, you can already, today, do whatever, without any change required on our side.
For those of us who aren’t quite savvy enough with how the code-base or translations work, how can we obtain a %Y-%m-%d $H:$M detailed format in Nautilus?
I have made changes to my /usr/share/i18n/locales/en_US files as outlined below.
%d_fmt "%m//%d//%Y"
d_fmt "%Y-%m-%d"
%date_fmt "%a %b %e %r %Z %Y"
date_fmt "%Y-%m-%d %T %Z"
My Control Center Region & Language > Formats reflects this…
However, Nautilus is not using this format.
You need to change nautilus’s translation file, not your system locale. The detailed format string is written with format modifiers that completely ignore your system locale.
You need to change nautilus’s translation file, not your system locale.
Would you mind pointing me in the right direction to accomplish this? Does this entail cloning the repo, making changes to the translation file, and building it from my now modified local source?
The detailed format string is written with format modifiers that completely ignore your system locale.
That’s the crux of the issue here. Gnome’s Control Center region/locale settings are intentionally mutable/configurable by the user to set/determine the preferred formats, but Gnome Files (Nautilus) is not honoring the user chosen format(s) in this scenario… which seems quite counter-intuitive, in my very humble opinion.
You need to download the translation file .po (Not .pot) from Module Statistics: nautilus for the version and language you want. Then open it with a translation editor or a text editor to change the respective line, then compile the .po file to .mo with gettext (google it), then copy it to the installation place, something like /usr/share/locale/en/LC_MESSAGES/ or /usr/share/locale-langpack/en/LC_MESSAGES/
This is because there’s only one default date and time formats but the entire feature hinges upon having different levels of details. Neither Glibc or GLib can provide different lengths or variants of date/time formats and thus the strings has to be translated manually. The proper solution that requires less manual translation is to bring an ICU dependency, but that’s unlikely to be added just to support the translation of a few strings.
TLDR; Thanks for pointing me in the right direction, I figured it out.
I didn’t see a relevant translation file there initially because I was looking for en_US, so I created a nautilus-iso-date.po file with the following contents. I took a stab at what was needed based on looking at another translation file (Swedish), wasn’t sure if this would actually work.
#. Translators: date and time in 24h format,
#. * i.e. "2023-12-31 23:59"
#: src/nautilus-date-utilities.c:83
#, no-c-format
msgid "%m/%d/%Y %H:%M"
msgstr "%Y-%m-%d %H:%M"
#. Translators: date and time in 12h format,
#. * i.e. "2023-12-31 11:59 PM"
#: src/nautilus-date-utilities.c:90
#, no-c-format
msgid "%m/%d/%Y %I:%M %p"
msgstr "%Y-%m-%d %I:%M %p"
I opened it with Translator Editor to see if it threw any errors. None seen, so I converted it, changing the file name to just nautilus.mo…
NOTE: I originally converted it to a file of the same name (
nautlius-iso-date.mo) but it didn’t work. I found a thread somewhere suggesting that the.mofile needs to be named after the app its intended for and found that it worked if I named it simplynautilus.mo.
msgfmt nautilus-iso-date.po -o nautilus.mo
I then copied it…
sudo cp nautilus.mo /usr/share/locale/en/LC_MESSAGES/
After a reboot I’m happy to report that Nautilus is now showing the ISO date format as the custom translation provides.
I agree with this statement.
Which is why I disagreed with the design and implementation on the Detailed format. I believe the newly introduced “Detailed” time format doesn’t satisfy the needs of the people who kept asking for such option.
The design goal was good, but the technical limitations of the locale make it fall short.
And that’s why I wish to keep the GitLab issue open and tidy, as evidence that the design must be revisited. (If it gets too long and noisy no designer is going to find the time to read it through.)
Oh. My. God. THANK YOU!
It’s been literally 5 years that people have been trying to get ISO format dates and times into the Files columns. Thank you for providing a solution.
