GNOME Bugzilla – Bug 402399
clock-applet needs an option to disable GNU extensions for strftime()
Last modified: 2020-11-06 20:20:24 UTC
Currently there are many .po files use GNU extensions in strftime() so those messages don't work on Solaris. % cd gnome-panel/po % egrep "%-m|%-d" *.po it.po:msgstr "%A %-d %B" it.po:msgstr "%A, %-d %B %Y" th.po:msgstr "%a %-d %b" th.po:msgstr "%A犖犖朽 %-d %B" th.po:msgstr "犖о険犖%A犖犖朽 %-d %B %EY" zh_CN.po:msgstr "%-m%-d%A" zh_CN.po:msgstr "%-m%-d%A" zh_CN.po:msgstr "%-m%-d" zh_CN.po:msgstr "%Y綛%-m%-d%A" 順? zh_HK.po:msgstr "%-m%-d(%a)" %-d GNU extension, *BSD 筝 zh_HK.po:msgstr "%-m%-d(%A)" zh_HK.po:msgstr "%-d/%-m" zh_HK.po:msgstr "%Y綛%-m%-d(%A)" 順? zh_TW.po:msgstr "%-m%-d(%a)" %-d GNU extension, *BSD 筝 zh_TW.po:msgstr "%-m%-d(%A)" zh_TW.po:msgstr "%-d/%-m" zh_TW.po:msgstr "%Y綛%-m%-d(%A)" strftime in GNU libc has the GNU extension; "_", "-", "0" and "^". http://www.gnu.org/software/libc/manual/html_node/Formatting-Calendar-Time.html Now we try to use community messages as many as possible so I'ld like to have the option to disable GNU extensions. To reproduce: 1. Right click on the clock-applet and choose [Preferences] menu on zh_CN.UTF-8. 2. Enable "Display Date" in the dialog. Then clock-applet shows "%-m %-d" instead of the localized string. I'm attaching the patch.
Created attachment 81504 [details] [review] Patch for applets/clock/clock.c and configure.in Added the patch to have the disable option.
While I can see how this is useful, I'm really not fond of this. IIRC, last time this topic was discussed, it was agreed that translators should not use GNU extensions. cc'ing Danilo who's the wise guy for this kind of stuff :-)
There are two problems at present. Firstly the fix depends on lots of translators and this problem is happened eventually. Secondary this problem is not gnome-panel only but also other modules and AFAIK, some module has the GNU extensions in C messages. I think the problem needs to be prevented by module maintainers not translators because we want to avoid the regression bugs. I have three options to resolve this. 1. Maintainers remove all GNU extensions in CVS and checks if any .po files has no GNU extensions whenever the official tarballs are released. 2. Maintainers remove all GNU extensions in CVS and modify the commit script not to integrate any .po files with GNU extensions in CVS. 3. Fixes this problem in the code base likes my patch. The patch is lower costs to fix this problem and I have also noticed gnome-search-tool also strips GNU extensions in the codes. I guess some translators want to use GNU extensions. What do you think? Do you have any ideas? Currently many people argued this problem since it's high visible so I'ld like to fix this asap. Thanks.
If GNU-extensions are used for non-essential features, such as different padding (which seems to be the case here), I think you should simply file bugs against translations using l10n product. I think there's no sense in adding code to ignore GNU extensions for every module which might get some of them used through translations: it's better to make translators aware of the portability issues, so they won't make the same mistakes, and they'll appreciate that they are helping the greater good. If they are used for providing something unavailable in other systems, yet useful for l10n purposes (eg. localized digits; I am not sure how well they are supported outside GNU), fix those systems instead (like Sun did with adding ngettext support :). Or convince the appropriate module maintainer to cater for both cases (like you are doing here). So, that's my two nickles (devaluation hurts :).
OK, bug 404898 was filed. Would you ask the translators to change the messages? Yes, we also has the request for Solaris libc supports GNU extensions but it's not a bug for Solaris and currently there are no plans. My suggestion will work even thought none GNU platform will support GNU exntesions in the future because we just enable the configure option. My understanding is this problem also effects BSD. I think this fix does not effect any GNU platforms.
Hi Vincent, Can I integrate this fix? I also think another way is to use eel_strdup_strftime() and it's the same idea.
I also noticed the thread. http://mail.gnome.org/archives/gnome-i18n/2003-December/msg00003.html
# ping Vincent. I think it would be very nice if you could integrate this patch. It seems to be difficult for the translators to fix this problem because of the message compatibilities since they have already applied that method in many .po files. I'ld like to fix this in GNOME 2.18 timeframe.
I'm sort of divided in this case. Indeed I see the problem will arise for OSes without GNU extension, but OTOH message appear in an ugly way with no GNU extension. Probably the best way for linux is to apply fix to glibc instead, but it seems that route is notoriously difficult. Probably accepting Takao's patch is the quickest way to fix things within current timeframe. Yelling at every translators to apply their own fix (as well as educating other future translators to do the same) can take quick a while, most likely well after 2.18 is released.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.