The word event in a Drupal codebase means a Symfony event, and this module dispatches plenty of them: BookingEvent, BookingEvents::HELD, EventSubscriberInterface, subscribers throughout. It also uses the same word for a bookable time window, which is a slot.
Excluding every Symfony and DOM sense line by line, there are 580 mentions across 159 files.
The code already admits it
TransactionSummary documents its own payload as "'events' lists each slot as ['slot_id' => int, 'resource_id' => ...]". The key is named for one thing and its own docblock explains that it holds another.
It is a wire contract, not only prose
$summary['events'] is published by hook_yoyaku_summary_alter(), which is the seam a pricing module implements. It is built in TransactionSummary, defaulted in SummaryHooks and in the cart form, and read by the summary templates and the mail template. So this is the same shape of change as retiring the order-line sense of target was: the PHP, the documented hook, the templates and their fixtures move together or not at all.
The rule this settles
The module already has two thirds of this written down. slot is the word in code and admin UI. session appears only in booker-facing strings, because it would otherwise collide with the web session. event is the third: it belongs to Drupal, and a slot is a slot.
Proposed
'events' becomes 'slots' in the summary payload and everywhere that reads it, and the prose says slot. The Symfony sense keeps the word everywhere it already has it.
What the sweep actually came to
444 mentions across 104 files, not the 580 the count above claims. The difference is what reading the lines one at a time turned up: subscriber docblocks whose plain "the event carries the window" is Symfony after all, the flood event HoldThrottle registers, DOM events the calendar widget and the place map bind, the reader-facing illustrations the vocabulary law already protects ("a room, a piece of equipment, an event"), and the strings below. A grep counts strings, not meanings.
The contract moved in one piece, because a payload key alone would have left its readers behind: $summary['events'] is $summary['slots'], hook_yoyaku_summary_event_alter() is hook_yoyaku_summary_slot_alter(), the theme hook and its template are yoyaku_summary_slot and yoyaku-summary-slot.html.twig, the card's CSS classes are yoyaku-summary-slot*, the render children are slot_N, the cart's button is getSlotRemove()/removeSlot(), and CheckinResult::$eventStart is $slotStart. Each summary row is $slot_summary, so $slot still means the entity.
docs/concepts.md gains the rule beside slot-never-session, so the next sweep does not have to rediscover it: slot, never event either.
The placeholders were not a wording question
Two strings carried an @event placeholder. A placeholder name is read by a translator and by nobody else, so both were corrected with the French catalog: 'Your places for @event' is the slot's label and became @slot, and 'Checked in: @event' became @resource, because CheckinHandler::label() returns the resource label and never the slot's. The words a reader sees did not change.
The settlement screen, which turned out not to be a wording question
These were going to be left for a decision of their own, on the reasoning that "Post-event settlement" reads better to a venue than any substitute. That reasoning only holds for a venue. The engine books "a room, a piece of equipment, an event", which is its own definition of a resource, so a hire desk lending a projector was being asked about something its site does not have, and told the projector could be marked a no-show. The states underneath were already neutral, completed and unused; only the wording on top assumed a performance, so it now says what actually ended: Settlement after the slot ends, Auto-complete after the slot ends, Auto-mark unused after the slot ends (a no-show), the two descriptions, the field group heading over them, and the queue worker title. The French moves with all of it, and already said créneau for a slot everywhere else.
Four French strings naming that sweep called it a balayage, which is a calque of "sweep": a periodic automatic job is a traitement automatique. Three further calques in the long description went with it, including modes spelled out as verbs that no longer matched the options they name.
What is still a wording question
The strings where event is what a reader would call a performance, and where no operator is being asked about equipment: the token description grouped by event, the three pool-area refusals for this event, the grade description an event can price places, the venue export warning, and the mini-site sentence on the booking channels field. None of them has moved.
Not in scope
Every Symfony and DOM use: BookingEvent, BookingEvents, EventSubscriberInterface, getSubscribedEvents(), event_subscriber tags, addEventListener, PointerEvent and friends.
Booker-facing strings where event is what a reader would call a performance. That is a wording question rather than a vocabulary one, and it should be listed for review rather than swept, exactly as session was.
AI-Generated: Yes (Claude Code found this while lifting a test fixture named event() into a shared trait during #3619693: Retire every duplicated method body, in tests as well as production, took the count above by excluding the Symfony and DOM senses line by line, and wrote the code and tests on the merge request. I reviewed and ran the work myself before posting it.)
Issue fork yoyaku-3619722
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mably commentedComment #4
mably commentedComment #5
mably commentedComment #7
mably commented