Admin screens do not say what a record belongs to, and translating one does not work

Problem

Six things an operator ran into while translating and arranging a house. They are one issue because they are one shape: a screen that knows something and does not say it.

• A record does not say what it belongs to. A slot belongs to a resource, a tariff to a resource or a slot, an allotment to a resource, a slot or a preset, and in placement a section, a place grade, a configuration, a pinning and a place each belong to a venue. Every one of those forms asked for the owner by autocomplete over the whole site, which is not an edit: it is how the row was reached.
• The breadcrumb could not say it either, because the paths are flat, so those screens read Home, Administration and the record type, with no way back to the venue or resource being worked on.
• The booking page arrangement offered words this module does not have. "By audience" and "By category" name nothing here: the code's own words are one panel per tariff class, and one entry per set of places in the order the venue grades them. In French "audience" had become "public", which named nothing at all.
• That arrangement sat under Calendar, which is not a calendar setting, so an operator looking for it opened Calendar. With it moved out, Calendar held one field while Day selection held the rest.
• A saved translation landed on an error. The translation form is the entity's add form, and one that names no destination leaves Drupal to return to the URL it was posted from: the add-translation route, which then refuses the request because the translation it is asked to create now exists. The translation was written and the operator was shown an exception about it.
• Translation had to be switched on by hand, one type at a time. Every translatable type had translatable storage, a canonical link and a Translate tab, and none of it showed until an operator ticked the type at Configuration, Regional and language, Content language and translation. Nothing said that, and nothing said which types there were.
• A key with a hyphen could not be saved at all. The machine name widget took core's default pattern, which allows letters, numbers and underscores, while this module writes hyphens: its own fixtures name a tariff class full-price, a preset grille-a and a grade cat1-full. Such a row was refused on every one of its forms, and the message named a machine name the operator had not touched.

Proposed resolution

What owns a record is stated once, by the module that owns it, through hook_yoyaku_owning_references(). Three screens read that one map: the form shows the owner rather than asking for it, with the widget left in place and inaccessible so the reference still round-trips on save; the breadcrumb walks the chain; and saving returns to the tab the row is listed on. The mechanism lives in the engine, because placement declares its own screens and does not depend on the admin UI module: a rule living there held for a slot tariff and not for a place grade, which is the same rule.

The arrangement's options, its description, the enum's own comments and two documentation pages now use the nouns the screens use: place grade and tariff class. The stored values are untouched, because they are written on every resource that answers this and a label is not worth moving data for. The arrangement has its own Booking page group, and Calendar and Day selection are one group.

A saved translation lands on the Translate tab. Translation screens get a trail ending on the record being translated, since every type carries those routes whether it belongs to something or not. The machine name widget accepts the hyphens this module writes; derivation still produces underscores, and no key is renamed.

Each module ships those settings as optional config, which Drupal installs only when its dependencies are met: a site with content_translation is offered the ten types on install, and a site without it gets none of them and is not asked. docs/translation.md names the types rather than saying "the ones the house translates".

Remaining tasks

None.

User interface changes

A site with content translation installed can translate what a booker reads without being asked to tick anything first. The owning reference is shown rather than asked for on eleven forms. Breadcrumbs on those screens, on every venue tab and on the translation screens offer the way back. The booking page arrangement is under its own heading and names place grades and tariff classes. Saving a translation lands on the Translate tab. A row whose key contains a hyphen can be saved.

API changes

New hook, hook_yoyaku_owning_references(). Two classes moved from the admin UI module into the engine. Ten optional configuration objects are shipped, one per translatable type.

Data model changes

None.

AI-Generated: Yes (the code, its tests and this summary were written by Claude Opus, reviewed and verified by the maintainer against a running site)