# イベント投稿やトピックのメール通知に説明文を含めた方がよい
**URL:** https://meta.discourse.org/t/email-notification-of-event-posts-topics-would-be-better-if-the-description-is-included/405280
**Category:** UX
**Tags:** email, events
**Created:** [2026 年 6 月 14 日午後 10:36 UTC](https://meta.discourse.org/t/email-notification-of-event-posts-topics-would-be-better-if-the-description-is-included/405280 "2026-06-14T22:36:34Z")
**Posts on this page:** 1
**Showing post:** 3
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [2026 年 6 月 15 日午後 12:41 UTC](https://meta.discourse.org/t/email-notification-of-event-posts-topics-would-be-better-if-the-description-is-included/405280/3 "2026-06-15T12:41:31Z")
ありがとうございます。以下のプルリクエストで修正されます。
>
>
> Previously, the notification email for an event post showed almost
> nothing abou…t the event. The event card is rendered client-side from the
> \`\[event\]\` block's \`data-\*\` attributes, so emails (which run no
> JavaScript) fell back to a sparse table that omitted the description
> entirely and mishandled other fields: all-day events showed a bogus
> "12:00 AM", recurring events gave no hint that they repeat, and
> scheme-less URLs produced broken relative links.
>
> This change extracts the email rendering into a dedicated
> \`DiscoursePostEvent::EmailRenderer\` that mirrors the on-site event card
> as closely as a static rendering allows. The email now includes the
> description, status (e.g. Expired/Closed), creator, recurrence label, "N
> going" count and cover image; formats all-day dates without a spurious
> time/timezone; renders emoji in the event name; cooks markdown in the
> location; and prepends a scheme to scheme-less URLs.
>
> Translations are read from the existing client locale (the \`js.\*\`
> namespace) so the email and the card never drift, and recurrence/status
> values are gated by \`EventValidator::VALID\_RECURRENCES\` and the event's
> own status. Purely interactive parts of the card (RSVP buttons,
> chat-channel link, more menu) are intentionally omitted.
>
> The creator is shown according to the site's name settings
> (\`display\_name\` gated by \`enable\_names\`) rather than always exposing the
> real name, which matches the on-site card and the other surfaces these
> emails reach, such as embedded comments.
>
> \`PrettyText.format\_for\_email\` does no sanitization of its own, so every
> field is escaped where it is rendered. Description URLs are linkified by
> escaping each text segment independently, keeping any markup that follows
> a URL out of the generated \`href\`.
>
> Finally, rendering is resilient: a failure on a single event is rescued
> and logged so one malformed event can never abort an entire digest or
> notification email.
>
> \*\*BEFORE / AFTER\*\*
>
> \
---
_[View the full topic](https://meta.discourse.org/t/email-notification-of-event-posts-topics-would-be-better-if-the-description-is-included/405280)._