Events tags

[nmlorg]

Expanding on #59, it might be nice to pull tags like "18+", "all ages", "accessible", etc. out of event descriptions into titles. Going a step further, the /events command could offer a way to filter events based on those tags. (So someone who is 19 could either exclusively show events tagged "18+" and "all ages", or show all events that aren't tagged "21+"; etc.)

It might be best to allow event organizers to explicitly control tagging, so the bot might first examine event['description'] for a line that starts with 'Tags: ' and only use the text on the remainder of the line. If no such line exists, look through event['summary'] for phrases inside square brackets ("My Fun Event [18+]"). Then, either as a final fallback or in addition to square brackets, examine all of event['description'] for well-known tags (18+, etc.).

[nmlorg]

Should tags be:

1. Completely flat:  21+, bar, Seattle, social, US, WA
2. Categorized:  age:21+, city:Seattle, country:US, region:WA, topic:social, venue:bar
3. Hierarchical:  age/21+, loc/US, loc/US/WA, loc/US/WA/Seattle, loc/US/WA/Seattle/bar, topic/social

[nmlorg]

First steps:

1. Add tags to calendars.
2. Add a tags field to all events. For now, this just inherits from the calendar. (Eventually, event.tags will be blended from the event's calendar and any per-event tags discovered in the description, etc.)
3. Add tags to the event's title in format_event. They should be formatted to prevent Telegram from turning them into group text searches. (Eventually they should turn into something like a deeplink to have the bot display all events with that tag.)
4. Maintain a list of all tags. Discovered tags should be normalized by something like: Remove all non-alphanumeric characters. If at least 50% remain, lowercase the remainder; otherwise, revert to the original text (preserving case). Every time a tag is encountered, register a vote for its exact form as being the canonical form for the normalized form. Use the exact form with the most votes (ties broken ASCIIbetically?) as the canonical form (used by format_event).
5. Add a new adminui.eventtags(?) widget, in parallel to adminui.calendars. Have the various events UIs just call the global multical.get_overlap and manually filter events for tags. (Eventually adminui.calendars will likely go away, and get_overlap will either get a tags argument to do the filtering itself, or some successor to MultiCalendar's View will handle the filtering.)

Thought needs to be given to how messy event lines might become if/when people really start tagging things prolifically. Should only the most-common X tags be shown? Least-common? Either way, globally, within their calendars, within just the set being presented (in group chats)? Should X just be 1, 3, top/bottom 50%, some threshold based on the length of the title? Should the tags be moved to a third line if there are >Y? Always?

I kinda like the idea of displaying the most-distinguishing tags, so for example in the simplest case—a group with a single calendar set, so all their events will [initially] have identical tags—no tags will be shown; but for a group with multiple calendars set, events will get a tag showing which calendar each event is from. (This might suggest we use most-differentiating across the whole view, so if such a group's time-windowed subview only happens to include events from a single calendar they still get tagged.)

Once this basic implementation is in place, we can go back to looking into discovering tags from literal hashtags in the description text, generating them from the location, etc.