Jewelry AI · Interface languages
A build you can install has no half-translated screen
Completeness is checked when the app is built rather than repaired while it runs. A language whose catalogue is missing entries does not produce a build at all, and nothing in the translator substitutes an English sentence for a missing one at runtime. What can still appear on screen is a different thing: a value the screen did not supply.
Completeness here is a property of the build, not of the running app
The catalogue for each offered language is declared against the shape of the full catalogue, so a language that is missing entries is not an app with gaps — it is an app that does not compile (apps/jewelry-mobile/src/i18n/translate.ts, read in the 2026-08 working copy). The check therefore happens once, before anything is packaged, and its result is either a build in which every offered language is complete or no build at all.
The consequence for a seller is narrow and worth stating plainly: the version installed on a device does not contain a screen that was finished in one language and left unfinished in another. There is also no path in the translator that quietly substitutes English for a sentence it could not find while the app is running, so an English sentence appearing inside your interface is not the expected symptom of an incomplete catalogue.
Asking for a language that has no catalogue at all raises an error rather than falling back to another language (apps/jewelry-mobile/src/i18n/translate.ts:101). That path is a developer-side gate; it is not reachable from anything in the interface.
None of this describes how the translations read. Completeness is a statement about entries being present. This page makes no claim about who produced the wording, who reviewed it, or whether a native speaker approved it.
What the source establishes
Each statement below is tied to the file it comes from, read in the 2026-08 working copy of the mobile app.
- Every offered language carries the full catalogue in a given build.
- The language table is declared against the complete catalogue shape, so an entry missing in one language stops the build rather than shipping (apps/jewelry-mobile/src/i18n/translate.ts).
- Nothing falls back to English while the app runs.
- There is no runtime substitution path for a missing sentence. The condition it would handle is excluded when the app is built.
- A missing value is shown, not hidden.
- If the screen does not supply a value a sentence expects, the raw placeholder stays visible rather than leaving a blank space (apps/jewelry-mobile/src/i18n/translate.ts).
- Placeholder consistency between languages has its own validation.
- Differences in placeholders across catalogues are caught by catalogue validation (apps/jewelry-mobile/src/i18n/catalog-validation.ts), separately from the completeness constraint.
- Twenty languages are offered, and none of them is presented as locked.
- All twenty languages the app offers today are selectable in the language picker (apps/jewelry-mobile/src/components/ui/language-picker.tsx).
Reading your own screen
Three things a seller can see, and what each one indicates. The third column matters as much as the second, because the wrong reading sends a report to the wrong place.
| What is on the screen | What it indicates | What it does not indicate |
|---|---|---|
| A token in curly braces, such as {count} | The screen did not supply the value that sentence expected | It does not indicate that the sentence itself is untranslated |
| A sentence in your language with every value filled in | The catalogue entry for that sentence was present when the build was made | It says nothing about how the wording was produced or reviewed |
| English text while the interface is set to another language | Something worth reporting with the exact string and the screen name | It does not indicate a language whose catalogue was left unfinished, because an incomplete catalogue stops the build |
Where an expectation breaks
Each of these is a reasonable expectation that the build-time constraint quietly invalidates.
Waiting for a later version to fill in a curly-brace token.
The translation is already there; a value did not arrive from the screen. Waiting will not change it, and the report belongs to the screen rather than to the language.
Assuming an English sentence in your interface means your language is only partly done.
That state is excluded before a build exists. Record the exact string so it can be located as what it actually is.
Comparing coverage between two languages inside the same version.
There is nothing to compare: within one build every offered language carries the same set of entries.
Treating completeness as a quality statement when answering a customer.
Presence and wording are different claims. Only presence is established here.
Before you report a screen as untranslated
Four things that make a report locatable rather than an impression of the app.
- Copy the exact text you saw, including any braces and the words inside them.
- Note the screen it appeared on and the step you were on when it appeared.
- Note the language your interface was set to at that moment.
- Decide which report you are filing: a missing value, an unexpected English string, or a disagreement with the wording. They are three different subjects.
What this page does not settle
Each line below is a question the source behind this page cannot answer, stated so that no one has to guess.
- How good any translation is, and who checked it. Nothing here states that any language was reviewed or approved by a native speaker.
- How many entries the catalogue holds. The source carries contradictory notes and no verified figure, so no count is published here.
- Which languages the store listings appear in. In-app text and store listing text are separate lines of work.
- Which language the server replies in. Emails, notifications and API error messages are outside what this page examines.
- How long a language change takes, and what any of this costs in start-up time or application size.
- Which language will be the default in a particular country.
- Which language the legal documents open in, and whether a country-specific version of them exists; that question is settled on its own page.
- The value of the preview configuration flag in any published build.
Questions
Can part of the app appear in English while my interface is set to another language?
Not as a result of an unfinished catalogue. The language table is declared against the full catalogue shape, so a language with entries missing stops the build rather than shipping with gaps, and the translator has no path that swaps English in for a missing sentence at runtime (apps/jewelry-mobile/src/i18n/translate.ts, read in the 2026-08 working copy). If you do see English text in your interface, record the exact string and the screen — it is worth reporting as itself, not as a translation gap.
I see a word in curly braces, such as {count}. Is the translation missing?
No. The sentence came from the catalogue in your language; the value it expected was not supplied by the screen that asked for it, and the raw placeholder is left visible rather than blanked out (apps/jewelry-mobile/src/i18n/translate.ts). Placeholder differences between the language catalogues themselves are checked in a separate validation step (apps/jewelry-mobile/src/i18n/catalog-validation.ts).
How many languages is the interface offered in, and are some of them still being added?
Twenty languages are offered today, and every one of them is selectable in the language picker (apps/jewelry-mobile/src/components/ui/language-picker.tsx). No language in the list is shown as locked or unavailable. This page makes no statement about what any list will contain later.
Does 'complete' mean the translations were reviewed?
No. Completeness means every entry the app asks for is present in every offered language of that build. Who produced the wording, and whether a native speaker reviewed or approved it, is not something the source behind this page shows, so no claim of that kind is made here.