It's the expiry dates that get me. Is there really any reason for a website to store a cookie for 25 years? Is it really going to be useful to Dell, to know when I last visited (September 15th, apparently) 900 years from now? Does Bitbucket need to know what repos I recently viewed, until a few decades before the Mayan Calendar requires a sixth digit? (You remember the Mayans, right?)

Sooo, what?

Because I can, I made a small add-on to clean up some of this detritus from the cookies database. It can delete expired cookies, cookies you haven't used for a while
(you get to set how long), and will alter the expiry date of remaining
cookies so that they don't last until the Sun burns up the Earth. It will even do so automatically, when you take a break to watch Sesame Street.

You can use it now too. Here it is. I named it Cookie Time after a company that makes delicious real cookies (feel free to send me some).

I haven't done much lately but I haven't done absolutely nothing. Given that I look at my Lightning calendar every day, some things began to irritate me. I've started to fix them.

(Note that I don't actually plan to fork Lightning and release it, I'm just using the term for pun value.)

Things you can see here:

Moved the view controls to the toolbar for space-saving and prettiness reasons

Restyled the events to match the today pane

Used better colours for my calendars (that's just done with about:config, but I'd change the available colours in the picker)

Things you can't see:

Switched on a database option for the offline cache (massive performance win, woo!)

Switched to Philipp's javascript implementation of iCal, and made some other changes so that Lightning could be run without being unpackaged, and without version dependence

Stopped the month and multiweek views from refreshing all the time when it's unnecessary

All these things and a few more are available as-is on my c-c patch queue if you're interested in trying them. I've done the easy 80%, and I wish I could justify spending the time on the hard 20%, but I just need to look at the picture above to see the reminders of bills that need to be paid.

As an add-on developer, I don't like doing localization. It's one of those hurdles I have to get over before I can release something. The thought process goes something like this: "I really want to release this new version for people to use and love and send me money for. Oh, I should probably get the translated strings up-to-date. Ugh."

Ah, now that I can do, or rather, I can get a computer to do. Get the strings translated, turn the changes into a patch, upload to GitHub. Boom.

So that's what I've done. Introducing Zoo. Nothing really all that fancy, just a text box for each string, and some code to do all the complicated stuff. It's far from ready for the prime-time, but it should be good enough if you're a translator and want to muck around with something different. I've loaded up four of my add-ons there (they come with some existing translations which you won't be able to edit) as a starting point.

I'm nervous about posting this. Please don't break it.

(I'm often lurking in #developers on Mozilla IRC in the US evening/Asian day/European morning, come say hi.)

¹ But, I have had two translation pull requests this week. That makes a total of two, ever. It confirmed what I thought though, that this is a great way of doing things.

Here's a graph (or a chart if you're that way inclined) of the users of one of my add-ons over time. Firefox 14 - 16 are missing from it which is confusing, but that's not the unusual bit. Let's see if you can spot it: