Pavillion

Appearance

Customize your calendar's identity ​

Your calendar has a public face. Visitors see it when they land on your page; other calendar owners see it when they're deciding whether to follow you or repost from your events. This guide is about the settings you have to shape that presence deliberately — what to put in each field, and what gets harder to change later.

Everything this guide covers is under Settings → Calendar → General. The calendar's name shows which one you're working on; click it to switch. On a computer it sits above the screen title; on a phone it is the title of the Calendar screen.

Who sees your identity, and where ​

Three views to keep in mind as you fill in the basics:

  • A visitor lands on your public page. They may have found you from a link a friend sent them. They see your calendar's name in the header, your description below it, and your list of upcoming events. They form an impression in about five seconds.
  • Another calendar owner finds you to follow. They've heard you're a good source for, say, Westside neighborhood events. They look up your handle, open a preview, and read your calendar description to decide whether to follow you. Your description is the thing standing between "this looks right" and "this looks generic — skip it."
  • A visitor whose preferred language isn't your calendar's primary one. They see your name and description in their language if you've translated those fields, and in your primary language if you haven't.

Your identity settings serve all three views at once.

The URL handle ​

Your calendar's URL handle is the short, lowercase, URL-safe name that identifies it across the network. It shows up in two places: the public address your-instance.example/<handle> that visitors paste into a chat, and the social handle <handle>@your-instance.example that other Pavillion calendars use to follow you.

Because that public address puts your handle at the root of the domain, it can't be a name the instance already routes there — admin or login, say — or a language code like es. The form you name a calendar in won't accept one, so you find out while you're choosing.

You picked a handle when you created the calendar. Right now, the handle is fixed when you create your calendar. There's no rename button in the settings panel. If you've outgrown the handle — your "westside-2026" calendar is still going strong in 2027 — the practical move today is to create a new calendar with the new handle and migrate. That's expensive: every link, every bookmark, every reposting calendar's rule, every email signature pointing at the old handle becomes stale. So it's worth picking a handle that ages well now.

A short version of the advice — the longer version is in the Quickstart:

  • Tie the name to the community, not to the moment. riverbend-folk ages better than riverbend-2026-season. westside-garden ages better than summer-projects.
  • Recognizable out of context. A neighbor pasting your handle into a chat shouldn't need a sentence of context for the recipient to know what it is. mutual-aid is too generic. maplewood-mutual-aid reads as itself.

A note on the social handle.

The @ shape ([email protected]) confuses some people on first read — it looks like an email address but it isn't. It's the handle other calendars use to follow yours: someone on a different Pavillion instance types it into their "follow a calendar" field to pull your events into their feed.

Your calendar's name ​

The name is what appears in the page header, in search results, in follow previews when another calendar is deciding whether to subscribe to yours, and on every event that gets reposted from yours onto someone else's calendar (as the "source" attribution).

The General screen gives you one text field for the name, per language. Editing it saves when you click away from the field.

Use the name your community actually calls itself. Westside Community Garden Events, Riverbend Folk Series, Maplewood Mutual Aid Calendar. Names that match how people refer to the calendar in conversation work better than names invented for the platform.

The name is your name, not a tagline. The name should identify, not pitch.

Names that age. This is the same advice as the URL handle, but with fewer restrictions — you can change the name freely, so the cost of getting it wrong is small. Still, names tied to a year, an organizing committee, or a momentary branding choice will stop being accurate before the calendar stops existing.

Your description ​

The description is one or two sentences. It appears under the calendar name on the public page and in the previews that other calendars see when someone looks yours up. After the calendar's name, it's the highest-leverage text you'll write for your calendar's identity, because every audience reads it and they're all making a decision when they do.

The General screen gives you a small free-text area, per language. The first language you write in is the primary description; visitors browsing in another language see that language's version if you've translated it, or fall back to the primary if you haven't.

Tell a stranger who the calendar is for and what's on it. "Events organized by and for the Westside community garden — workdays, harvests, potlucks, and quarterly meetings" tells a visitor whether they're in the right place. "All events" tells them nothing.

Be specific about the community, not just the topic. "Folk concerts" is a topic; many calendars list folk concerts. "Folk concerts at the Riverbend Community Center, presented by the Riverbend Folk Society" is a calendar. The difference matters when another calendar owner is deciding whether to repost from yours alongside their own folk listings — they're trying to figure out whether yours is relevant to their audience.

Skip slogans and adjectives. Vibrant, welcoming, premier and the rest of that vocabulary make the description sound like the back of a packaging insert. They also crowd out room for the specifics that actually tell a visitor what your calendar is.

A note on writing the description for other calendar owners.

The people who run other calendars read your description with one question in mind: "if I follow this, what will land in my repost queue?" A description that names the kinds of events you publish, the geography, and the community is helping them answer that question.

Languages ​

Pavillion treats your calendar as multilingual from the start. The first language you write in is the primary, and you can add more from the language tabs at the top of the name and description fields.

The languages you add determine what's translatable. With one language, the editor shows simple text fields. Add a second, and tabs appear above the field — one tab per language. Each tab holds an independent version of the text. The same applies to event titles, descriptions, category names, place names, and accessibility notes throughout the calendar. Adding a language opens the option to translate everything; it doesn't translate anything by itself.

Don't add a language you can't sustain. A French tab that contains the English text — or worse, a single half-translated event from a year ago — is a worse signal than no French tab at all. It tells visitors that French content exists and is then immediately stale. If you're not sure you can maintain a language, don't add it; you can add it later.

For the rules of what's translatable, how visitors land on the right language version, and what happens when a visitor's preferred language isn't available, see Publish in multiple languages. The General screen is where the calendar-level decision happens; the per-event mechanics live in that guide.

The default event image ​

The default event image is an image that fills in for any event you publish without uploading one specifically for it. It appears in two places. The first is the event cards in your calendar's list — your public calendar page and your embedded widget's list — for any event without an image of its own. The second is the link preview: when someone pastes a link to one of your calendar's event pages into a chat or a social post and the event has no image of its own, the preview shows your default. The event's own page shows only an image uploaded for that event, so a visitor who follows that link and opens an event that relies on the default sees no image there. In a list, reposts never show a default in either direction: when another calendar reposts your event, its list shows only the event's own image, and events you repost from other calendars don't pick up your default in your list either. A link preview works differently: for an event without its own image, it shows the default of the calendar whose page the link points to — so a link to an event you reposted, on your calendar, previews with your default.

The General screen lets you upload one image. Uploading replaces it; removing it leaves events without their own image to show no image at all.

Once the default is uploaded, the same Image description for screen readers choice the event editor offers appears beneath it: Skip description hides the image from screen readers, Add a description gives you an Image description box for the language tab you're on. A screen reader reads the description in place of the image, and wherever the default stands in for an event's own image, it reads the default's description. Write it once per calendar language, and write it about the image — The Maplewood Community Garden logo — rather than about any one event, because it will sit beside all of them. If the default is purely decorative, skip it. Removing the image clears its descriptions, so a new default starts undescribed. The description saves when you click or tab away from it, like the rest of the General screen.

Use a default that reads as your calendar, not as a specific event. A neighborhood-association calendar's default might be the association's logo on a plain background, or a wide shot of the park where most events happen, or a piece of identifying community artwork. Avoid using a default that looks like it belongs to one particular event.

The default is a fallback, not a requirement. For any specific event that deserves its own image, upload one in the event editor and it'll override the default for that event. For routine events without strong visual identity — the monthly meeting, the weekly volunteer day — the default can stand in as a fallback visual.

The default date filter ​

The Default Date Filter sets how far ahead a visitor sees when they open your public calendar without choosing dates: the list starts today and runs for the window you pick. It applies to your public page and your embedded widget. Visitors can still widen or move the range with the date control at the top of the page; the filter only decides what they see first. The filter and the date control apply to the list view; a visitor looking at the week or month view sees that week or month instead.

The choices are 1 week, 2 weeks, 1 month, 3 months, 6 months, 9 months, and 12 months. Until you pick one, the control reads Instance default and your public page uses your instance's default window — two weeks, unless your administrator has set another. Picking a window replaces Instance default, and the control can't return to it.

Match the window to how often you publish. A calendar with a few events a month reads as empty on a one- or two-week window, and a first-time visitor who sees an empty page rarely goes looking for the date control. A busy calendar with something every day can stay short, so the list opens on what's coming up soon rather than a long scroll.

Things that trip people up ​

Changing the calendar name doesn't change the URL handle. Renaming the calendar from Westside Garden to Maplewood Community Garden in the name field changes the visible label everywhere, but the URL still says /westside-garden because the handle isn't tied to the name. Visitors with the old link still land in the right place — but the URL now disagrees with the name, and that mismatch confuses people. If a rename feels structural enough to want a new URL too, that's the case where creating a new calendar may make sense.

Removing a language drops its translations. If you added a French tab, wrote French versions of the name and description, then removed French from the calendar's language list, those French translations are gone. Pavillion will warn you before removing, but the warning is easy to click through. Take the warning seriously.

The description renders as plain text. Markdown, HTML tags, and line breaks beyond what the textarea preserves don't get formatted. If your description has a link in it, paste the URL as visible text — visitors can copy it, but it won't render as a clickable link in the description block. (Links inside event descriptions render normally; this is specific to the calendar-level description.)

Default image edits update existing events that were using the default. Every event without an image of its own reads from the calendar's current default the next time the page loads. Replacing the default this morning means yesterday's published events are now showing the new image too. This is usually what you want, but it's worth knowing before you swap.

What's next ​