Language integration
Fenómenus is multilingual through the site's translation layer. This page documents which values are per language, which are shared, and where the product keeps them aligned.
The division
| Per language | Shared across translations |
|---|---|
| Post title | Price meta |
| Subtitle, description, long description | Allergen terms |
| Tasting and set menu block titles and contents | Category assignment |
| Footer notes | Featured mark |
| Category names | Images |
| Interface labels | menu_order |
post_status |
Sharing the facts is deliberate: a guest reading any language must be quoted the same price and told the same allergens.
Where alignment is enforced
Status changes. Changing an item's status through the list screen applies to the item and every translation returned by the translation layer.
Ordering. Saving the item order applies the same menu_order to every translation of each item.
Allergens. Saving an item applies its allergen terms to every translation.
Categories. Saving an item from its edit screen keeps the translated item pointing at the matching translated category, creating the link where it can.
Integrations that write these values directly should reproduce the same behavior, or the languages will diverge.
Translatable fields per post type
The translation panel exposes a defined set per menu type:
| Post type | Fields |
|---|---|
a_la_carte_menu, terrace_menu |
subtitulo, descripcion, descripcion-larga, descripcion-vino-recomendado |
wine_list, cocktails, beverages, breakfast, desserts, bar_menu |
subtitulo, descripcion, descripcion-larga |
tasting_menu |
subtitulo, descripcion, the block titles and contents, nota-al-pie |
set_menu |
subtitulo, descripcion, the block titles, nota-al-pie |
Fields marked as allowing HTML are sanitized accordingly; the rest are stored as plain text.
Creating a translation
A translated record is created when a title is supplied for that language and the item is saved. The new post:
- takes the source's post type and status;
- is assigned the target language;
- is linked to the source as its translation;
- receives the translated field values;
- has its category assignments aligned with the source.
A language with an empty title produces no record, deliberately.
Admin queries
The admin list screens are scoped to the main language, so they show one row per menu item rather than one per translation. Custom admin queries over these post types should do the same, or counts will be multiplied by the number of languages.
Front-end URLs
Each language has its own archive and category URLs. Code that builds links should resolve them per language rather than string-manipulating a base URL.
Artefacts
- The QR generator produces one code per language, grouped and labelled.
- The PDF generator exposes a language selector and produces one file per language.
Both are covered in their own contract pages.
Without a translation layer
Every translation behavior is inert. Items have no translation panel, the language toggle has nothing to show, and QR and PDF generation produce a single default result. Nothing else changes.
Guard integration code with a function check rather than assuming the layer is present.