GNOME Bugzilla – Bug 750917
No datetime formats available in l10n in List view.
Last modified: 2016-03-03 15:52:55 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.
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?
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
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?
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.
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_().
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.
Thanks for testing! Attachment 322972 [details] pushed as 9853217 - file: use _() directly for date formatting