Languages — Rikochey

How the script picks the language of a form, how to force it, and what the server does with it.

A form is built once, in its source language, and translated by the client into the other languages it offers. There is one form per identifier, whatever the language: the same data-rikochey-form="contact" tag serves every version of a multilingual website, and requests in every language arrive in the same form, with the same field names.

Seven languages can be offered: fr, en, es, de, it, nl, pt.

How the language is chosen

For each form on the page, the script takes, in this order:

the data-rikochey-lang attribute of the form's tag, when there is one;
otherwise the page language, read from the lang attribute of <html>.

The script reduces that value to its base language in lowercase (en-GB, EN_gb → en) and asks the server for the form in that language — see How forms are loaded. The server picks the language and returns the form already translated:

the requested language, when the form offers it;
otherwise, when the page gives no language or one the platform does not publish, the website language, when the form offers it;
otherwise the form's source language.

A published language that the form does not offer gives the source language directly. A form is therefore never rendered in a language it does not offer, and the visitor's browser language (Accept-Language) is never used: the page decides, as it does for the rest of its content.

<!-- Follows <html lang> -->
<div data-rikochey-form="contact"></div>

<!-- Always in English, whatever the page's language -->
<div data-rikochey-form="contact" data-rikochey-lang="en"></div>

Most multilingual websites already set <html lang> — WordPress does, and so do WPML and Polylang: the attribute is only needed to force a language on one spot.

Once the script has taken charge of a form, the <form> element — yours in attached mode, the generated one in automatic rendering — carries the chosen language in data-rikochey-rendered-lang, for your own styles or scripts.

One language per submission

Everything the visitor sees follows the rendered language: labels, placeholders, help texts, options, button, privacy notice, the script's own messages, the validation messages — standard and custom — and the confirmation message returned by the server.

To do so, the script sends the rendered language with the submission, in form_locale, next to page_locale — see Submit a form. The server keeps form_locale when the form offers it. Otherwise it takes page_locale — or the website language, when the page language is missing or is not one of the seven — and resolves it among the form's languages as above, falling back on the source language. The request records the language it was filled in.

The confirmation message follows the same language. A message the client has overridden for one website is written in that website's language, and only returned in it.

Texts that were not translated fall back on the source language, one by one: a partially translated form is never blocked.

In attached mode

Your own HTML is never modified: labels, placeholders and options are yours to write in the page's language. The language resolved from the same attributes only drives the messages — validation errors and confirmation — and is sent as form_locale. Put data-rikochey-lang on the <form> tag if the page has no reliable <html lang>.

What is published

The browser only ever receives the language it renders: each form of window.FORMS[] carries locale, the rendered language, and its texts already translated — see What the script publishes. Neither the other languages nor the translation table leave the server. The token API lists the source locale and the offered locales, not the translations — see List a website's forms.

From a CMS

WordPress: [rikochey form="contact" lang="en"] forces a language; without lang, the tag carries none and the form follows the page.
PHP: Form::tag('contact', [], 'en') and $form->embedTag([], 'en') add data-rikochey-lang — see Rikochey PHP.