Hype5 Docs

Hype5 Theater 0.7.0 · Beta — by invitation

Multilingual sites

On this page

Hype5 Theater handles translated content by treating the original-language post of a production, person or venue as the owner of shared facts. Translations carry their own texts; performances, credits, galleries and other shared rows exist once, on the original, so physical events and credits are never duplicated per language. This page describes that model as implemented.

Tested with Polylang only. For Hype5 Theater 0.7.0 the real Polylang 3.9.0 plugin was tested. The plugin also reads WPML's interfaces, but WPML itself was not installed in testing — its interfaces were only simulated — so WPML is not a supported integration for 0.7.0. See Compatibility.

Translation plugin detection

Data\Identity resolves posts of the three Hype5 types:

  • Original (canonical) post — Polylang first (pll_get_post() in the default language), then WPML (wpml_object_id in the default language). Without either plugin, a post is its own original.
  • Reader's-language post — the translation in the current language (Polylang, then WPML), or the post itself.
  • Public reader's-language post — the translation only when it is published; otherwise the original. A draft, pending, scheduled or private translation is never shown to visitors.

The plugin ships a wpml-config.xml that marks the three post types and four taxonomies as translatable and lists how each meta field is handled.

Shared data (stored once, on the original)

Data Notes
Performances and ticket offers Stored against the original production and venue. Translated IDs passed to the schedule filters are mapped to the original.
Credits and information rows Stored against the original production and original person. The editors make credits read-only on a translation and link to the original.
Gallery images and people tagged in them Read from the original production.
Repeatable rows Files, videos, audio links, external galleries, partners, articles, other links, visitor rows — read from the original.
Accessibility markers of a production Read from the original; the accessibility text is per language.
Venue accessibility defaults Taken from the original venue.
Profile visibility of a person Checked on the original person.

Per-language data (each translation's own)

Title, content, excerpt, teaser, language text, custom audience recommendation, custom warning text, visitor information, accessibility text, parking text, programme file, display overrides (_hype5t_display) and taxonomy terms (translated as terms).

wpml-config.xml copies these fields from the original to new translations: premiere date and venue, duration, acts, intervals, accessibility markers, repertory status, production relationship, presentation mode, ELAB identifiers, birth date, profile visibility, venue address fields and coordinates. It marks teaser, language, custom audience, custom warning, visitor information, accessibility, parking, arrival notes and access notes for translation.

Public output

  • Names and links are shown in the reader's language when that translation is published, for productions, people and venues alike.
  • A shortcode or page for a production whose reader's-language translation is unpublished shows the original instead.
  • A production is "public to everyone" only when the version asked for, the original and the reader's-language version are all published without a password. Cards, person profiles, the general schedule and the public performances route apply this rule.
  • A password on a language version protects the shared data (credits, performances, gallery, rows) shown on that version. The first version that carries a password decides — the version requested, else the original, else the reader's-language version — so a translation without its own password of a protected original is protected by the original's password (WordPress shows its password form there too), and a page is always unlocked by the password entered on it, including its dates and offers (Theater 0.7.0). Cross-page output (cards, profiles, the general schedule, production shortcodes on other pages) shows a production only while no version shown carries a password.
  • Pages whose content depends on a password entered for a production — its own page when the version shown, its original or the reader's-language version has a password, and a schedule filtered to it by the address (when any language version has a password, because the reader's language may be known only after the headers) — are sent with no-cache headers (Theater 0.7.0; WordPress does this only for a post with its own password). A page that is public to everyone stays cacheable when some other language version has a password; that version, if a shortcode shows it there, is shown as on any other page. Everywhere else — feeds, archives, search results, core REST answers, other pages — WordPress's own readers keep such a production protected also after its password was entered.
  • A published translation of an unpublished original shows only its identity — title, address, poster — to visitors who may not read the original: no teaser, text, excerpt, dates, offers or credits, also in feeds, core REST answers and search (Theater 0.7.0). A password on the unpublished original is not used for visitors: no password form is shown and nothing tells that it exists (users who may read the original still need it). Originals in any status but published count, also custom statuses of editorial-workflow plugins and statuses left by a deactivated plugin.
  • Visitors who are not logged in do not find, in WordPress's search, any version of a production with a password in its chain (as WordPress does for posts with their own password).
  • The productions list's next order and city filter, and schedule counts, use only productions public to everyone (Theater 0.7.0), so a protected production is neither placed among dated ones nor matched by city, and counts equal the rows shown.
  • A hidden person profile hides its translations too (when the setting was not copied to them).
  • Public texts (labels) are overridden per WordPress locale; see Labels.

Hype5 registers one permalink base per type. WPML or Polylang Pro can translate the registered slugs for per-language bases. Neither was tested with Theater 0.7.0.

Deletion

Relational data (credits, gallery tags, a venue reference on performances) is cleaned only when the original post is deleted permanently. Deleting a translation leaves shared data unchanged. Performances survive the deletion of their production.

Known limitations

  • WordPress remembers one entered post password per visitor. If two language versions of a production carry different passwords, entering one forgets the other: each page is unlocked by its own password (including its dates and offers since 0.7.0), but not by the other's. Use the same password on every language version.
  • Until 0.7.0, collection counts could include rows that the multilingual visibility rule then hid; they now use the same rule.
  • Earlier 0.6.17 builds named schedule rows by the original-language title and could not find the next performance, city filter or "next" order for productions in a non-default language. Phase 5K resolves the production in the reader's language for these cases.
  • With a persistent object cache, the plugin's cache entries for these rules are keyed by WordPress's last_changed markers and expire after one hour; with WPML, linking translations without saving a post can leave them stale until then (persistent object caches were not tested). Search plugins that replace WordPress's search query bypass the search rule above. See Known limitations.