#7639 closed enhancement (fixed)
Add options to change week start for both, per environment and per macro call
Reported by: | Roger John E. Ragasa | Owned by: | Steffen Hoffmann |
---|---|---|---|
Priority: | normal | Component: | WikiCalendarMacro |
Severity: | normal | Keywords: | calendar localization first-day-of-week |
Cc: | Ryan J Ollos | Trac Release: | 0.11 |
Description
Make start day of the week modifiable. By default Monday is used as the start of the week. However our Trac users are more at ease viewing their calendar with Sunday set as the start of each week.
Attachments (1)
Change History (14)
comment:1 Changed 14 years ago by
Cc: | Ryan J Ollos added; anonymous removed |
---|---|
Keywords: | calendar localization first-day-of-week added |
Status: | new → assigned |
comment:2 Changed 14 years ago by
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
I played around with your code and attached what I came up with. To use this you must use the "Advanced use" method to add your calendars. Add the following parameter:
[firstweekday=<integer-value>]
where <integer-value>
is one of the following:
0 - Monday 1 - Tuesday 2 - Wednesday 3 - Thursday 4 - Friday 5 - Saturday 6 - Sunday
I also changed the default value to Sunday. If no valid value is detected, it reverts to the default value.
Hope this helps.
comment:3 Changed 14 years ago by
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Sorry for closing. I noticed that you have a habit of keeping tickets open for a couple of weeks for discussion.
comment:4 Changed 14 years ago by
Well spotted, thanks for taking care about our development habits here.
It's true, I do value discussion a lot, since I need someone to get corrected where I'm not able to cover knowledge and demands of whole mankind. ;-) Being Christian by birth is another reason, why I consider this very topic of what-is-first-day-of-week an important thing to think and talk about. [1] I.e., do we really need to be ruled by ISO-8601?
Personally I think, Sunday is a good candidate. Don't hide preferences as well es respect for our as well as others religious background, that suggests or supports such a calendar view. But we need to respect international business as well, and there ISO rules as a matter of fact. And Trac is not for childplay but doing serious business, right?
So what can we to do now? There should be a good default. Historically with respect to this plugin as well as WikiCalendarMacro, that I'm about to merge in, it is Mo as 1st-day-of-week. This is what rules business according to ISO-8601 as well. Another good rule is not to break backwards compatibility, what I'd like to extend even to (default) configuration. Until now all maintainers took care to allow for seamless upgrades. No need to touch configuration or even all the macro invocations in all wiki pages, and this is maybe the strongest point for me. So let's go on with default 1st-day-of-week = Monday. For the record: This is equal to current hard-coded setting.
That said it should be really easy(TM) to not only change this default for a single instance but switch it globally for all instances in that Trac environment. A I saw evidence that this is a global setting anyway, I tend to even move this option to [trac] or a similar more central place. I've not finished investigation on the matter yet.
To allow for a per-instance setting is the last, but nevertheless important piece.
Some personal notes to you while you're asking:
Providing a patch against latest stable release or trunk
would allow for quicker review in the future.
Second, you prevent unmaintained releases, since everyone can just copy your version now, and even I'm unable to delete the attachment while being the current maintainer. Some months ago, when I started development of this almost unmaintained plugin, there was a real mess of patches, a big number of working versions attached to the plugin page as well as to some open tickets. It took me weeks of evening work to sort it out, extract the unique features in between all criss-cross inheritance etc.
So please, please with a cherry on top, stick to patches as often as possible. You may send me a complete version for discussion anytime - by private email, ok?
comment:5 follow-up: 6 Changed 14 years ago by
Severity: | trivial → normal |
---|---|
Status: | reopened → new |
Summary: | Add option to change week start. → Add options to change week start for both, per environment and per macro call |
I'll incorporate all additional configuration options as commented before
- global pre-set
- per instance keyword-argument
while preserving default behavior as before for good measure as explained in detail before as well.
Ryan, would do me a favor and delete the attachment here, please? I've saved a copy locally and will provide a corresponding patch for retaining the core of reporters information for reference. This is even a big improvement on readability for all fellow developers here. Thanks in advance.
comment:6 Changed 14 years ago by
Changed 14 years ago by
Attachment: | wikiticketcalendarmacro_1st-day-of-week.patch added |
---|
diff replacement for full file attached 07-Sep-2010 by ragasa
comment:8 follow-ups: 9 10 Changed 14 years ago by
First thank you for all your help. Sorry about the attachment. I will stick to patches next time. :D
I'd like to point out a possible problem with localized versions. Weekend detection. Since Monday was by default the first day of the week, setting the last two days as weekends before work well enough. With this patch however, "Su" and "Sa" are used to detect the index for the weekends. I'm not sure if this will work for localized versions where "Su" (Sunday) and "Sa" (Saturday) does not equate to weekend.
comment:9 Changed 12 years ago by
Component: | WikiTicketCalendarMacro → WikiCalendarMacro |
---|---|
Priority: | low → normal |
Replying to ragasa:
I'd like to point out a possible problem with localized versions. Weekend detection. Since Monday was by default the first day of the week, setting the last two days as weekends before work well enough. With this patch however, "Su" and "Sa" are used to detect the index for the weekends. I'm not sure if this will work for localized versions where "Su" (Sunday) and "Sa" (Saturday) does not equate to weekend.
Hm, I feel, that this issue has hold-up the implementation of that feature for much too long, sorry. And I'd like to make this feature available for both macros in the united code base.
comment:10 Changed 12 years ago by
Replying to ragasa:
First thank you for all your help. Sorry about the attachment. I will stick to patches next time. :D
I'd like to point out a possible problem with localized versions. Weekend detection. Since Monday was by default the first day of the week, setting the last two days as weekends before work well enough. With this patch however, "Su" and "Sa" are used to detect the index for the weekends. I'm not sure if this will work for localized versions where "Su" (Sunday) and "Sa" (Saturday) does not equate to weekend.
Different weekend start and end days may be provided by Babel, that we utilize much more because of work done for #10992. Whoever is longing for proper localization will install Babel for Trac anyway, so this dependency should be fine.
comment:11 Changed 12 years ago by
While for WikiTicketCalendarMacro this will be an enhancement, for WikiCalendarMacro could be seen as regression fix, because it already got basic week start adjustment capability in [7324], in fact years before both macros got bundled together lately in [10203] (see #1145).
comment:12 Changed 12 years ago by
(In [12989]) WikiCalendarMacro: Add optional week numbers, refs #1145, #7639 and #8175.
Rationale and constraints of current implementation:
- support any calendar per instance (use 'w' key-word) - no dependencies
- use basic start-of-week negotiation, if Babel is not installed
- use auto-negotiation for locale-aware Trac versions (since Trac 0.12)
- use advanced locale detection (similar to Trac 1.0.2)
Because I've found an issue with week number calculation in Babel, this plugin does it on its own for now.
comment:13 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(In [12991]) WikiCalendarMacro: Releasing current, tested macro package as final product, closes #7639, #8175, #9718, #10991, #10992 and #10993.
Special thanks to Jun Omae for pushing development by testing and providing valuable hints in our discussion about utilizing Babel for better localization and for making macro execution thread-safe as well.
As this was already mentioned before in #7473 I'll happily accept this enhancement request right away, to keep tracking it. Let's see, what could be done. Thanks for your interest in WikiTicketCalendarMacro development.