Singapore open-source workshops: locate why one interface message stays in English

The problem

A Singapore contributor switches an application language and finds one message still in English, but editing the translation file has no effect because they have not identified how that message is rendered.

Capture the exact state that shows the message

Write down the screen, selected language and action that displays the text. Distinguish a field label from a server response or browser-generated message; they may not share a translation mechanism. Use a synthetic form so that the example can be shown without personal records. The useful question is where this particular text comes from, not whether the whole product supports languages. Add the application revision or setup you examined, the text you expected and the observation you actually obtained. A selected-language indicator alone does not identify the source of every visible string. Keep a screen title, field warning, notification and external response as different messages until their paths are established. If you cannot inspect the relevant permitted source, record that limitation rather than naming a file by guesswork. Prepare the minimal observed state, then narrow the localisation question to this message and its permitted source path.

Separate observations from possible explanations

Use six fields: displayed message and trigger; chosen language and setup; expected change; edit actually made; observed result; and source-path question still open. A value remaining in English can suggest a literal string, a different key, another source or a setup mismatch, but it does not establish which explanation applies. Do not change several files to make one observation fit your first hypothesis. Identify what the actual project permits you to inspect and what evidence would distinguish the possibilities. This is a question-preparation method, not a command sequence or a diagnosis of a real application.

Check whether a translation key is used

FormSG's guide distinguishes externalising hardcoded English from updating existing translations. Follow the displayed message back to its source and check whether it uses a locale key. If it already does, examine the selected locale and fallback. If it is literal interface text, editing an unrelated locale value will not change the rendering path. Keep the proposed key and the observed use of that key separate in the record. Finding a similar translation value does not show that this component calls it. Likewise, locating a literal word in a repository does not show that the running state uses that file or revision. Compare the relevant permitted source and setup with the state that produced your observation. If the path leads outside the part you can inspect, retain that boundary and ask the project which component controls it. Do not rename an uncertain path as hardcoded merely because editing the first file did not help.

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

Trace a wholly fictional unchanged button

The application, key and observations in this example are invented. A practice screen shows an English button labelled “Review” after the contributor selects another practice language. They change a locale value named actions.review, but the screen still shows “Review”. That observation does not yet establish a cause. In the permitted practice source for the same revision and screen, the contributor then finds that this button uses the literal word rather than that locale value. The recorded finding concerns this button’s rendering path only. It does not show that every English message is hardcoded, that an external response is translated or that the unused value should be deleted.

Propose the smallest coherent change

For an existing key, show the current value and the corrected meaning. For hardcoded text, ask which namespace and type structure the project expects before adding a key. Include the surrounding context so reviewers can assess whether the wording is reused appropriately. Do not create a second key merely to avoid finding the existing one, or silently change every language's behaviour. In the fictional button case, the next proposal is to use the practice project’s agreed message structure for this one button and keep the original meaning. The contributor asks which existing message location and type are intended before adding anything. If the project wants a different key or shared pattern, retain that answer with the revised scope. Do not combine this change with new wording for every other button or another locale. The translation-values guide covers whether inserted information and plural meaning survive a known message; it cannot establish which path this screen uses. Keep the two decisions connected without calling them interchangeable.

Compare the checked result with the still-open boundary

Continue the invented case after the practice project agrees the small change. The contributor repeats the same captured state: the alternate-language label now appears, and the original English state still shows “Review”. Record those two observations for that revision and button. Another notification elsewhere remains unchanged and has not been traced; leave it out of the completed claim. If your own permitted repeat check does not change the first message, keep that actual result rather than borrowing the fictional outcome. A build passing or another screen changing does not supply the observation required for the original state.

Verify both the corrected and original path

Return to the captured state after the change and repeat the language switch. Check that the original language still displays the intended message and that the translated version appears in the same relevant state. Bring that evidence to a workshop or contributor discussion. An event can help investigate the path; the repository process still governs any final contribution. Bring the captured state, the relevant permitted source observation and the proposed scope to the session. An unsent question could say, “This practice button uses a literal word in the inspected revision; my first edit changed an unused locale value. Which message structure should this button use, and which checks are needed for that scope?” If the path is still unknown, change the question accordingly. Ask who can explain the code path and who can approve the contribution. A peer’s useful trace suggestion does not make an event host responsible for merging the change or deciding every language’s wording.

Leave a reconstruction of what changed and what did not

Retain the setup, selected language, trigger, source-path observation, proposed or agreed change and checks actually made. In the invented example, one button’s path and two rendering states are recorded; the other notification stays unresolved. Keep a proposed edit, an observed result and project integration as separate stages. If the context changes, repeat the relevant enquiry instead of treating an earlier answer as evidence for a different message or revision. Use Boardzip’s free contribution search for practical help with the specific missing field, then confirm the session’s prerequisites and support. Search access cannot identify the code path, provide repository permission or prove a fix you have not observed.