Problem

Every content entity type the engine gives a booker-facing label to carries it per language, after #3616524: Translate the resource name, the slot title and the tariff label a booker reads. The venue is the one exception: yoyaku_venue has no data table and its Name is not translatable, so a bilingual house shows one spelling of its hall to everybody.

The name is not an internal one. Four surfaces a booker reads print it:

  • the slot booking page subtitle, in SlotBookingController::page(), whose own comment says the venue "is what the visitor still needs and cannot get anywhere else on this page";
  • the when-and-where line of the place booking page, in PlaceBookingController;
  • the venue block of the map payload, in VenueMapBuilder, so it also shows inside a full-screen plan;
  • the Where: row of the ticket, in TicketPlacementHooks, which is rendered in the booker's own language.

The exception is deliberate and documented, in the entity docblock and under What stays language-neutral in docs/translation.md: a hall's name is a proper name, called the same thing in every language. That holds for some halls and not for the ones a public operator actually runs. Salle des fêtes, Petite salle, Main Hall and Hall 3 are descriptions, not proper names, and even a name that reads as proper is translated in practice. It is not the engine's call to make on a site's behalf, and the rule #3616524: Translate the resource name, the slot title and the tariff label a booker reads settled on is that a string a visitor reads has to be translatable.

Proposed resolution

Give yoyaku_venue a yoyaku_venue_field_data table and translatable: TRUE, and make the Name base field translatable. Nothing else moves: the map artwork, the two sprite ids, the tenant and the two default records stay language-neutral, copied into every language row.

Ship config/optional/language.content_settings.yoyaku_venue.yoyaku_venue.yml alongside the ten #3618305: Admin screens do not say what a record belongs to, and translating one does not work adds, with untranslatable_fields_hide set, so a site with the translation UI gets the Translate tab without ticking anything and its screen asks for the name alone rather than repeating a page of untranslatable fields.

Then read the name in the right language at the four surfaces: getTranslationFromContext() for the three rendered in a booker request, and the explicit langcode for the ticket, which is built outside one from the langcode the order notifier already resolves.

Why this one is cheap

Making a type translatable relocates every non-key column into the data table, and what broke in #3616524: Translate the resource name, the slot title and the tariff label a booker reads was raw SQL still naming the base table. Nothing in the engine writes raw SQL against yoyaku_venue: every read is load() by id, and one entity query filters on it, in PinningAccessControlHandler, which gains the default_langcode condition the other types use. Both booking pages already declare languages:language_content and already add the venue as a cacheable dependency, and the map document is already keyed by langcode, so no cache serves one language's name to another.

Remaining tasks

Drop the venue from the language-neutral list in docs/translation.md and add it to the table above it; check whether the InterfaceLanguageUrlTrait paragraph in docs/architecture.md needs the same pass it got for the other three types; French for any new string. A kernel test that the name round-trips per language, and one that each of the four surfaces answers in the language asked for.

User interface changes

A venue gains a Translate tab out of the box on a site with the translation UI, offering its name and nothing else.

API changes

None in code. The storage layout changes, so this is reinstall-only, as everything before 1.0 is.

AI-Generated: Yes (Claude Code was used to trace where the venue name is read and to write this issue summary. No code has been written for it yet.)

Issue fork yoyaku-3618349

Command icon 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

mably created an issue. See original summary.

mably’s picture

Status: Active » Needs review

  • mably committed 6bf93935 on 1.x
    fix: #3618349 The venue name a booker reads on the booking page and on...
mably’s picture

Status: Needs review » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.