Singapore localisation sessions: preserve runtime values in translated messages

The problem

A Singapore language contributor improves a translated form message, but the new sentence drops an inserted threshold or breaks its plural structure, leaving the interface less informative despite sounding natural.

List the pieces that are not ordinary prose

Start with one message and identify the inserted value, unit, action and condition it communicates. A character-limit warning, for example, needs both the required limit and the user's current count to remain intelligible. Write those meanings beside the proposed translation. Do not remove a placeholder simply because the sentence reads more smoothly without it. Put the intended reader action beside the information the message must convey. A value may be a limit, current amount, remaining amount or another quantity; do not decide which from its name alone. Keep its meaning and unit attached to the actual message state. If the required behaviour is unclear, ask the project before improving the sentence around a guessed interpretation. Prepare an invented input or another example you are permitted to share. A visible screenshot without the state or source message may hide which part came from runtime information and which part was fixed wording.

Use a message and rendering card

Make seven entries: message identity and purpose; language and interface state; variable meanings and chosen values; condition or plural case; project structure to preserve; expected reader-facing information; and actual observation or untested field. Use the actual source record and project instructions for the structure. The card does not impose a particular key name, syntax or plural rule on every language. A reviewer should be able to see why a number matters, which message it belongs to and whether the example was actually rendered. Keep an unknown variable meaning or untested branch visible rather than substituting the most plausible sentence.

Follow the project’s message structure

FormSG's translation guide requires preserving runtime variables and uses a structured localisation system. Check how the chosen project represents those values before editing punctuation or word order. Copying a visible example into a text document can hide the message syntax. Review the actual string and its use in the interface together, with a contributor who understands the format. Read the message’s surrounding state and the role of each inserted value before asking a language reviewer to assess it. Distinguish changing the words in an existing structured message from deciding how hardcoded text should be externalised. The separate unchanged-screen guide develops that source-path question. Here the question is whether the known message keeps its required meaning and structure when rendered. If you propose another variable, unit or branch, identify the corresponding project decision rather than silently changing the interface contract. A grammatically smooth sentence can still omit the value that tells the user what correction is required.

• FormSG/TRANSLATION.md at develop · opengovsg/FormSG · GitHub ↗ · Source checked 20 October 2026

Work through an invented missing-value example

All messages, values and requirements here are fictional. A practice form requires its warning to show both the minimum length and the current length. In the invented state the minimum is five characters and the entered value contains two. A proposed warning says only “Please add more characters”. It may be understandable in isolation, but it omits both quantities required by this fictional task. The contributor prepares wording that retains the meanings of five and two through the practice project’s stated structure. The language reviewer checks whether a reader can identify the required change, and the technical reviewer checks whether those values are actually inserted. Neither person is being asked to accept a real FormSG patch or a universal wording rule.

Choose values that expose an error

Prepare cases for one item, several items and a value near a validation boundary. Use values that would make a missing number obvious. Read the resulting sentence without knowing the intended answer, and check whether the reader can identify what to change. A fluent reviewer and a technical reviewer may notice different failures; ask each a specific question. In a further invented message, the interface needs to report the number of messages remaining. The chosen practice cases are one message and two messages, with their expected meanings stated before the check. A number-free phrase such as “messages remain” loses information in both cases. Record the count actually displayed and the corresponding sentence rather than reporting only that a plural branch ran. If you have not checked a zero case or another relevant state, mark it untested. Different languages and project formats may need different cases; follow the actual structure and reader need instead of copying this small fictional set as complete coverage.

Keep the rendered result beside the proposed wording

Continue the fictional practice record. The revised warning displays the intended minimum of five and current value of two in the tested state. The one-message and two-message cases also show their expected counts. A narrow screen then wraps the warning beneath another field, so the meaning checks have passed for those cases while the placement question remains unresolved. Record both observations; a successful number insertion does not settle layout. Ask the project how that state should be presented and check the revised arrangement in a permitted example. Do not erase the earlier obstruction or claim that a single wider screenshot validates every screen, language or assistive reading path.

Check the interface after the sentence

A longer phrase may wrap beneath the wrong field or push an action out of view. Inspect the message in its real context and record the language and state tested. Keep the contribution small enough to review as one behaviour. Search for sessions offering practical localisation feedback, while checking whether the project's required tooling and review process fit your current skills. Take the card, the permitted source pattern and the actual rendered observation to the chosen session. Ask whether it offers language feedback, help with message structure, interface inspection or only a demonstration. Those roles may require different people. An unsent enquiry could say, “I have an invented warning with two required values and a recorded placement problem. Can participants examine its meaning and rendering, and what setup or material route is required?” Keep an acceptance to discuss the example separate from project approval of the proposed change. If a source-path issue emerges, stop treating the question as wording alone and use the relevant trace guide.

Submit the checked boundary rather than a translation badge

Keep the message, chosen state, input values, expected information, actual result and remaining cases together. In the fictional record, the useful outcome is correct inserted information in three practice states with a separate narrow-layout issue still open. It is not evidence that the whole application is translated, that every plural condition works or that users understand all messages. Follow the actual contribution route and preserve what was checked before any later revision. Use Boardzip’s free contribution search for a session matching the open field, then verify its support and preparation. A fluent review, workshop attendance or successful build cannot supply the language and interface observations that were never made.