Locale, interface copy and prayer identifiers

This describes the next coordinated kit/host release on the hardening branch, not registry kit 1.0.0. Deploy the compatible host, release its matching kit, then build and publish new immutable templates. Old artifacts do not change their output or acquire translations automatically.

Ownership

Read site.locale.code for the language. The host sets the document’s lang and dir. Use logical CSS properties and platform font variables. Do not set a template direction, bundle an Arabic font or replace a tenant’s authored text with a translation.

The visitor language selector is hidden for now. Localisation supports a website’s chosen language; it does not imply that the organisation maintains translated content. site.locale.languages is currently empty and the legacy language_switch island renders nothing. Its registered name and implementation are retained for a future per-site opt-in, such as an English/Welsh website. Do not create a replacement switcher in a template before that policy is defined.

Branding, navigation, collection labels, section content and prayer names are supplied data. Render those values as supplied, including intentional empty strings. Translation is only for interface copy owned by the template, such as Menu, Read article and Sold out.

Interface filter

<button type="button">{{ 'Menu' | t: site.locale.code }}</button>
<a href="{{ article.href }}">{{ 'Read article' | t: site.locale.code }}</a>
<h2>{{ section.title }}</h2>

The t filter uses a finite platform-owned phrase catalogue in the shared engine locale.mjs. The initial catalogue covers the three mosque templates in Arabic. English, unknown languages and unknown phrases retain the supplied phrase. It is not machine translation or a full-site Arabic guarantee. The output remains escaped; never add raw. New phrases require a reviewed platform catalogue addition, not template-side locale tables. React islands keep their separate platform message catalogues and must be verified independently.

Dates

{{ article.publishedAt | local_date: site.locale.code, 'date' }}
{{ event.startsAt | local_date: site.locale.code, 'datetime' }}

local_date accepts ISO dates or timestamps with an explicit Z/offset, and the two fixed styles date and datetime. Zone-less timestamps are rejected to avoid host/kit differences. It formats English, Welsh or Arabic using the Gregorian calendar and UTC. It localises presentation, not the organisation’s time zone; do not label its time as tenant-local. Unknown locales fall back to British English; invalid values/styles produce an empty string. Arbitrary patterns, a user-selected time zone, relative dates and now are not supported. Only six formatter combinations can be cached, independent of the number of tenants. Prayer begins and congregation values are already supplied wall-clock strings: render them unchanged, without this filter. Existing date remains available for existing artifacts.

Stable prayer identities

site.content.schedules remains an array. Select the entry with type == 'worship'. Its content.times rows and content.next may include a language-independent key: fajr, zuhr, asr, maghrib or isha. Use that to select a decorative time-of-day icon and render the supplied name beside it. Unknown or absent keys must still show their text. Legacy English-name matching is a compatibility fallback, not a translation strategy. Friday rows remain content.jumah; church services must not be assigned mosque keys.

The identifier is additive. It does not change schedule eligibility, dates, prayer calculations, upload parsing or which schedule is visible. An empty schedule array still means no rail.

Verification

Test actual Liquid output without preview text replacement. Include Arabic names with stable keys, unknown keys, English fallback, escaping, cleared headings, long labels, mobile RTL and the real platform islands. An inactive Arabic preview island is not evidence that live payment, identity, consent or form messages have been translated and reviewed.