lincolnuniltl/calibr

A simple bilingual opening hours calendar loading and rendering system

calibr's Issues

Add scope for attaching visible comments to opening times

Allow comments for dates or date ranges to be loaded into the database and rendered in some way for users. Could use the existing Notes column in CSV but would need to add a database field as well.

Add semantic markup (eg RDFa) to calendar table

Provide more language flexibility

Currently only bilingual in en and mi. Allow setting any first language and any optional subsequent translation languages.

This would make calibr a whole lot more useful.

Opening hours should be able to straddle midnight

There's no way in the load file to indicate that opening hours might not apply to the indicated calendar day. For example, the hours 10:00 to 03:00 (next day) can't be expressed.

This is apparently not so uncommon, though we won't be needing it at Lincoln.

Warn users if their CSV file dates are not correctly formatted

We've discovered that Excel helpfully reformats dates in CSV files when saving them. The workaround is to edit in a text editor or edit the xlsx file (where date formats are enforced) and export as CSV.

The reformatted dates (at least for us, may be settings dependent) contain slashes and cause the date comparison tests to fail and the records to be skipped silently. In fact, the result is that the date data is removed because the load function returns a value (empty array), so real damage is done.

It's too dangerous to attempt reformatting the dates (apologies to Postel), but simple tests like "does it follow this pattern we want" should be possible, followed by a warning to the user.

Support arbitrary period coverage not just calendar months

Currently data is rendered for whole calendar months only. Let this be more flexible so that I can show shorter or longer periods as required.

Stop pagination extending beyond limits of data

Don't provide pagination links at the boundaries of data. Though it can be funny to watch the logs and observe Googlebot traversing its way back to 1977 and beyond where there is no data, more intelligent browsers would probably not need those links, nor those in the undetermined future.

Multiple openings in a day

This wasn't supposed to come up, but has just this one time at Lincoln (and apparently does plenty at other places). That's enough to bother me.

Not going to be a trivial adjustment.

Use browser's language preferences where possible

This is a fancy nice-to-have. If we support more than one language, it would be optimal to look at the User Agent accept-language headers and see if we can accommodate those. Some thought required on the logic before commencing. Something like:

• get the UA language preferences
• see if they have translations here
• yes and already in $languages: move preferred languages to top in order
• yes and not in $languages: add supported preferences to head of list, retain current first/default
• no: do nothing

There are more complex scenarios than that!

More renderings of calendar data (iCal etc.)

Create an option not to purge loaded future data

The load script currently purges any existing data for future days before loading new data. It's a trap for young players, a mite dangerous, and needn't be there.

Add notices at head of page

Add a notice box on HTML calendar display pages (ideally could do per month as well).

Not exactly sure what the use case is, but it seems handy for conveying information the app doesn't support, for example.

Allow data from past dates to be loaded

We only load dates from the current day. If admins don't load new data before the last day with data, there'll be a gap. We should be more forgiving.