I am attaching a patch that does the following:

  1. Rewrites the theme_availability_calendars_month to use the theme_table function and be more drupal-proof
  2. Add the days of the week as a header for each availability_calendar table, this coincides with the users' specified first day of week in the node edit form
  3. Add a 'key' as the first table in the availability calendar node view, this comes with a preference to turn the key on/off under the Availability calendar settings section of the node edit form.
  4. Moved the 'Month name/edit link' into a div above the table to make room for the new header row with the days of the week.

this is patched against todays version of the 6.x-dev. I hope you guys find that these features are useful and make it into the module. I can help troubleshoot code and make changes if needed, let me know.

Comments

nicholas.alipaz’s picture

StatusFileSize
new10.03 KB

attaching patch.

Additionally see a running version of this patch here:
http://sorkbeachrentals.regencyweb.info/lower-unit-availability.html

nicholas.alipaz’s picture

Title: Add Days of Week and use theme_table() Function » Add Days of Week and use theme_table() Function [patch attached]

Any testers for this? I did a lot of work on it and was hoping for any input on the changes.

avpaderno’s picture

Title: Add Days of Week and use theme_table() Function [patch attached] » Add week days and use theme('table')
geodaniel’s picture

Thanks for the patch. I've tried it out a little, and generally I'd say it looks good, though I have two comments about it. First, great that there is a key generated by the module now, but I'm not sure I'd always want it grouped in with the calendars, so could this perhaps be made into a block? Second, I don't think we can just wrap the single letter representations for days in the t() function, as they won't be properly translatable like that (e.g. T could be Tuesday or Thursday).

avpaderno’s picture

I don't think we can just wrap the single letter representations for days in the t() function.

Also, the letter T is always the letter T in all the languages that use the Latin alphabet; it's more probable you are interested in translating the week days.

nicholas.alipaz’s picture

That sounds reasonable. what about doing something like

  $days = array(
        13 => t('Monday'),
        12 => t('Tuesday'),
        11 => t('Wednesday'),
        10 => t('Thursday'),
        9 => t('Friday'),
        8 => t('Saturday'),
        7 => t('Sunday'),
        6 => t('Monday'),
        5 => t('Tuesday'),
        4 => t('Wednesday'),
        3 => t('Thursday'),
        2 => t('Friday'),
        1 => t('Saturday'),
        0 => t('Sunday'),
  );

Then just doing something like:

$day = substr(0, 1, $days[$i]);
array_push($headers, array('data' => $day, 'class' => 'dayofweek'));

That would get us the first letter and allow for better translation. If you like it then I can repatch later this week.

For the key, that is a nice idea for adding it to a block, but I still think the option to include it within the page is nice too. Perhaps we could leave it there with the flag for turning it off/on of course. Then we could add an option for a block in a future change?

Let me know what you guys think.

avpaderno’s picture

That would not actually work for languages like Hebrew, Chinese; doing like you suggest, you will get the last character of the word, not the first (the last character because they write from right to left).

A better way is to use the short name of the week day ("Mon", "Tue", "Wed"); in this way, who translates the module understand what the words to translate are, and he will translate them correctly (in example, in Italian they become "Lun", "Mar", "Mer").

nicholas.alipaz’s picture

hhmm, I kind of wondered about that when I wrote it... I will think some more.

nicholas.alipaz’s picture

Another option would be to use the first three letters as the archive module does:
http://drupal.org/files/issues/archieve.JPG

avpaderno’s picture

It still preferable to let the translator people decide the short name of the week days; in reference to languages like Hebrew, it's not possible to programmatically get a valid abbreviation for the week days.

What the module does is to use a function call like t('Mon').

nicholas.alipaz’s picture

Actually, what you said is exactly what I am suggesting. Just use t('Mon') as the header then let translators do what they like. no substr() parsing or anything.

avpaderno’s picture

I didn't correctly understand what you mean by "to use the first three letters".
What you suggested is the only way to proceed, I think.

nicholas.alipaz’s picture

Ok, glad we agree, I will repatch that part. Do you or anyone have any input on the suggestion regarding the key as Dan mentioned?

avpaderno’s picture

I actually didn't understand that reference to a key; I would be glad to give a suggestion, if somebody would tell me what it is exactly. :-)

nicholas.alipaz’s picture

Take a look at http://sorkbeachrentals.regencyweb.info/lower-unit-availability.html

Notice the "Key" (also known as a "Legend" to some folks), Dan is suggesting it not be listed within the area for the calendars. Put it in a block instead.

My opinion differs in that I think the option to show it among the calendars should remain, but the addition of a block should be an added feature. Of course the node edit form contains a flag to turn this key on/off on a per node basis.

Thanks.

avpaderno’s picture

In cases like this one, it is better to let the users decide what they like better.
I would add a setting so the user can decide if the key must appear or not, and I would also add a block for the key.

nicholas.alipaz’s picture

OK, I agree and that is precisely what I had suggested. I am going to open another issue for adding that feature. I will not be adding it in this patch, it is too large as is.

avpaderno’s picture

It is also better to keep feature requests separated.

nicholas.alipaz’s picture

Issue fixed. The changes have been commited (guess I didn't need the brackets in the commit :blush:):
http://drupal.org/cvs?commit=245738

I promise future changes will be better separated.

nicholas.alipaz’s picture

Status: Needs review » Fixed

marking fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.