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 750917 - No datetime formats available in l10n in List view.
No datetime formats available in l10n in List view.
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Views: List View
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-06-14 03:55 UTC by Takeshi AIHANA
Modified: 2016-03-03 15:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
a simple solution for getting date as string with l10n. (626 bytes, patch)
2015-06-14 03:55 UTC, Takeshi AIHANA
reviewed Details | Review
file: use _() directly for date formatting (4.73 KB, patch)
2016-03-03 12:57 UTC, Carlos Soriano
committed Details | Review

Description Takeshi AIHANA 2015-06-14 03:55:31 UTC
Created attachment 305222 [details] [review]
a simple solution for getting date as string with l10n.

The strings with localized datetime formats in List view are not available, so always formats in en_US are used even if locale is in ja_JP.
It seems like that lacks a gettext _() macro for in g_date_time_format(). I added a simple solution.
Comment 1 Carlos Soriano 2016-03-02 19:07:40 UTC
Review of attachment 305222 [details] [review]:

The format string is using N_(, so it should just work. Then after that we take the locale appropiated date with g_date_time_format.

Is something wrong on this? can you try with 3.18 since we did some dates handling improvements on it?
Comment 2 Takeshi AIHANA 2016-03-03 12:20:53 UTC
Please refer to the actual implementation of g_date_time_format() and gettext-macro section in GLib reference manual also [1].

The *format variable passed in this function will duplicate to the other variable in UTF-8, so that it should be called gettext() as N_() for new *format variable which stored in other memory in runtime.

And I have no any environment for checking GNOME 3.18 release.

[1]https://developer.gnome.org/glib/stable/glib-I18N.html#gettext-macro
Comment 3 Carlos Soriano 2016-03-03 12:41:10 UTC
I still don't see how a constant var is changed inside g_date_time_format and how applying twice _() would works, because as far as I can see the current code with the patch does this:
format = N_()
_(format)

Which is effectively the same as format = N_();, no?
Comment 4 Carlos Soriano 2016-03-03 12:57:44 UTC
Created attachment 322972 [details] [review]
file: use _() directly for date formatting

We don't need to use N_() since it's not an array, but just a const
char.
This was causing problems with the date format not being translated,
since N_() only marks for translation, but doesn't allow translator to
actually translate.
Comment 5 Carlos Soriano 2016-03-03 12:59:18 UTC
Ok, so I think the problem is that N_() doesn't actually allow the string for translation, but instead mark it for translate, which is the difference with _().

I think what we actually want is to just call _() everywhere, since N_() is not needed since we are just dealing with a const char, not with an array initialization or some sort of handling that doesn't allow calling functions inside, which is the goal of N_().
Comment 6 Takeshi AIHANA 2016-03-03 13:18:50 UTC
Yes, you're right. 
The N_() macro does not have actual effects.

BTW, I patched for my nautilus-3.16.3 with new solution, it works fine in Japanese.

Thank you very much.
Comment 7 Carlos Soriano 2016-03-03 15:52:51 UTC
Thanks for testing!

Attachment 322972 [details] pushed as 9853217 - file: use _() directly for date formatting