reopen 197469 thanks On Sat, Feb 28, 2009 at 03:03:02PM +0000, Debian Bug Tracking System wrote: > As I got no objection against the arguments in my last email three weeks > ago, I would like to declare this bug as an intentional feature and close > it. > > Feel free to reopen if needed.
You sent that message to the bug address, which does NOT reach the submitter, so I'm reopening this out of principle. Please remember to actually contact the submitter next time you want to communicate something to them... But secondly, I'm reopening based on my response to that email which follows: > the author of gcal decided (according to general practice) to look for the > following environment variables: > $LANGUAGE > $LC_ALL > $LC_MESSAGES > $LANG > If one of those is defined, the value is further examined. There are only > two options: the value starts with "en_" or something different. > The first case means some kind of American style calendar where the days of > the week are written in a top row and the week starts with Sunday. > The second case means some kind of ISO calendar with days on the left side > and the week starts with Monday. So the logic of choosing is hardcoded into the program, even though it's initially based on locale data. It doesn't differentiate between en_US and en_UK, and I do seem to recall that US and UK differ in this matter in general practice. > According to ISO/IEC TR 14652 usage of $LC_TIME is problematic and might > result in unintended behaviour. I've googled that and found http://www.open-std.org/JTC1/SC22/WG20/docs/n972-14652ft.pdf There I see a detailed description of LC_TIME, including: first_weekday Define the first day to be displayed, for example in a calendar display utility. The operand is an integer specifying the day number (1 = first) according to the information specified with the "day" keyword. The keyword may be omitted, and then the value 1 is taken, corresponding to Sunday for a week beginning Sunday, or to Monday for a week beginning Monday. Granted, the section is marked with "(controversial)", and there are a few notes about problems, including: 7. The LC_TIME section includes some changes that are incompatible with POSIX.2. Some week definitions that have depended on Sunday being considered the first day of the week are changed in this TR to use Monday as the first day of the week. This would break existing implementations. However, I do not see exactly where the unintended behaviour would arise with regard to the issue of using this variable to determine the first day of the week - gcal already has its own logic of choosing, it's just the fine-grained variable choice that would be affected. Based on the description of that logic, I see two potential pitfalls: * American calendar users with (LANGUAGE|LC_ALL|LC_MESSAGES) = en_* and LC_TIME != en_* - if the logic was changed to cater to LC_TIME before LC_MESSAGES, they wouldn't get American calendar format if they didn't also have LANGUAGE or LC_ALL set to en_* * ISO calendar users with (LANGUAGE|LC_ALL|LC_MESSAGES) != en_* and LC_TIME = en_* - if the logic was changed to cater to LC_TIME before LC_MESSAGES, they wouldn't get ISO calendar format if they didn't also have LANGUAGE or LC_ALL set to something other than en_* Regarding our users, the description in locale(7) seems most pertinent LC_TIME changes the behavior of the strftime(3) function to display the current time in a locally acceptable form; for example, most of Europe uses a 24-hour clock versus the 12-hour clock used in the United States. I can't be sure, but I doubt that there are many users in any of the aforementioned two groups, because it would mean that: * they are an American calendar user with LC_TIME set so that local time shows European-style clock * they are an ISO calendar user with LC_TIME set so that local time shows US-style clock > Further it is correct to use $LC_MESSAGE to decide upon the language of > the output. Please keep in mind that gcal does not only output a calendar > but also holidays and events. That's fine, but I'm not talking about changing message handling, just the calendar (week) format handling. Don't you agree that calendar format is something different from normal message text? > In any case, if you want to avoide -s1, you could still set $LANGUAGE. I'm not sure to which value to set it if I don't want to alter the behaviour of LC_MESSAGES. locale(7) says: LC_MESSAGES changes the language messages are displayed in and what an affirmative or negative answer looks like. The GNU C-library contains the gettext(3), ngettext(3), and rpmatch(3) functions to ease the use of these information. The GNU gettext family of functions also obey the environment variable LANGUAGE. So I wouldn't actually want LANGUAGE=hr_HR because that would conflict with my existing LC_MESSAGES=en_*. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
