Monthly Archives: December 2010

QA / Technical — 7 Comments
19
Dec 10

Updating holiday calendars

We’re in a desperate need for updated holiday calendars, as many have not yet been updated for 2011.

In detail, we’re looking for calendars for the following countries / locales:

  • Basque
  • Belgium (Dutch)
  • Chile
  • Greece
  • Kazakhstan
  • Lebanon
  • Malta
  • Namibia
  • Puerto Rico
  • Singapore (Submitted, but not reviewed yet.)
  • Sri Lanka
  • Switzerland
  • Turkey (Submitted, but not reviewed yet.)

All of these local calendars will expire when they’re not updated and will have to be removed if we don’t find a contributor who can support them.

If you would like to help, please follow these steps:

Once complete, we can update the calendar file on the website as soon as possible.

Thanks in advance!

If you need further information about this process, don’t hesitate to contact us in the #calendar-website channel on irc.mozilla.org or calendar@mozilla-uk.org

–The calendar website team
(Tobias Markus, Tom Ellins, Jan Bambach)

Project Updates — 5 Comments
10
Dec 10

Bringing your Calendar to the Web, Part 2: Consumers

I recently started a series on how to best bring your calendar data to the web. Today I’d like to go into more detail about who would be a consumer of your data, and how this could look like.

There are a few ideas (and even standards) on the web to make calendar data more readable for computers. The first that comes to mind is the hCalendar microformat, which uses the HTML class attribute to mark certain aspects of an event. Unfortunately, the use of this format is not very wide spread, mostly because browsers usually don’t make much sense of this information. The standard works well for sites promoting events to the user, such as local event sites. For example, Yahoo Upcoming uses the hCalendar format. There are also efforts to revive ical-as-xml, also called xCal. This is more centered on transporting calendar data via xml though.

But, as far as I have read, there is no standard for sharing local calendar data with the web. To start off in this direction, we have to differ between active and passive data consumers.

On the one hand there are websites that would ask the user for his or her calendar data so that they could display this data, well integrated into their site. For such sites it would be great to provide a standardized API to access user calendar data. On the other hand, there are sites that won’t use a such API right away. Such sites could nevertheless be integrated with your calendar. Parsing the website and looking for dates could help you in creating an event in your calendar.

Scraping events off a web page can be very complex and its not often clear which parts of the web page really are event data. While hCalendar could relieve this issue, for sites which don’t provide metadata a human is probably still the best to decide. I am working on an extension that allows manually scraping data from an email, this could well be extended to websites too.

Lets go back to web-based calendars for a moment. If you have been using an online calendar like Google Calendar, you have to rely on some sort of integration between those websites. Although some sites like tungle.me offer importing data from Google Calendar, this is not always the case. Also, what if you use a different Calendar? The site owner needs to add and test interfacing with each calendar site, which is not always easy.

The alternative would be a standard, that allows on-line calendars to synchronize its data with your PC, and also define a way for other sites to access this data in a safe manner. This would mean the usual add/modify/delete/retrieve operations, together with a synchronization mechanism. To make adoption as easy as possible, this standard should make use of existing formats and standards as possible. I could imagine xCal being the transport mechanism, together with etags and ctags to improve synchronization.

I will be talking about privacy in more detail in the next part of this series.

Lightning — 2 Comments
05
Dec 10

Migrating the Lightning help documentation to the Mozilla Messaging Support Knowledge Base

In our last blog post we were asking for help with migrating all support documentation from the Mozilla Wiki to Mozilla Messaging’s Knowledge Base.

Unfortunately the traffic in the #calendar-website channel was quite low, or in other words: we didn’t get any help, so the migration process took us a bit longer than we’ve expected – but we’re finally done! :-)

The calendar website team was checking, updating and migrating all articles and we’re happy to announce that users who need help with Lightning can use the Mozilla Messaging Support KB!

You can view a list of all Lightning articles here.

–The calendar website team
(Tobbi, Jan, TMZ)

QA — 9 Comments
04
Dec 10

Lightning 1.0b3pre now with numerous improvements

If you have been using Lightning 1.0b3pre nightlies, you’ve been missing out on a number of fixed bugs and new features. This is because we’ve been concentrating on making Lightning work with trunk (the newest comm-central/mozilla-central code).

Although not finally decided, the next Thunderbird version is likely to be from the more stable comm-1.9.2/mozilla-1.9.2 branch. Therefore we have now backported all relevant patches to the comm-1.9.2 branch, giving you the chance to see what the next version will be like. If you are wondering why this hasn’t happened before, it is important that bugs are fixed on trunk first. Otherwise it may happen that a future version loses features and bugfixes a previous release contained, due to problems while porting the code.

The Calendar Team would really appreciate if you could give this nightly a spin, especially if you are maybe using your own calendar server, or maybe one that is not so common. The earlier you test this version, the more likely it is that the 1.0b3 release will not contain bugs that make it unusable for you.

If you haven’t yet downloaded Lightning 1.0b3pre, make sure you have a copy of Thunderbird 3.1 and get Lightning here. If you encounter any bugs be sure to search first. If you can’t find a matching report then file a new one. Please also note which version of Thunderbird/Lightning you are using.

Note: The list of bugs that were fixed, which includes the new features can be found here.