Written guide
Overview
Appmint Translation stores a key and its language-specific values. We will create that record, change a translation and verify the consumer that uses its key. This module does not automatically translate every page merely because a language exists.
1. Create a translation key
Why this matters
A stable key identifies the text; the language rows hold what readers see. Group organizes related entries.
Follow these steps
- In Studio Manager, open DAM → Translation. This menu entry requires admin access; a missing menu item is an access issue to investigate with your administrator, not a missing language record.
- In Translation Manager, choose New Translation. The app opens Details; selecting Details alone is not the named create action.
- Enter a stable Key, for example
delivery_note. The standard schema normalizes it, requires 3–100 characters, and permits letters, numbers, underscores and hyphens. Use a different key if this one already belongs to existing content. - Enter Group, for example
checkout. Add an Item row, select the required Language from the list and enter Value. For English you might use “Delivery details”; add the relevant second language and its translation as a second row under the same key. - Choose Save. Return to Translation List, find this key and reopen the saved record. Compare both language rows with what you entered. This verifies storage, not that a storefront already reads this key.
flowchart LR
K["Key: delivery_note"] --> E["English value: Delivery details"]
K --> L["Second language value"]
P["Page or component requests delivery_note"] --> S["Consumer chooses supported language"]
S --> E
S --> LConceptual lookup relationship, not an application screenshot or an automatic website translation workflow. The consuming page must already request this key and support the selected language.
Check the result: The saved record contains the intended key, group and both language values.
2. Edit and verify the real consumer
Concept illustration: The consumer must request the saved key and intended locale. A saved translation record does not automatically translate every page. This is not an application screenshot or evidence that the action has run.
Why this matters
The correct record can still appear unused if the page or component looks up another key. Test the consuming interface rather than treating a saved record as evidence of rendered translation.
Follow these steps
Find the translation by its key. Change one Value and save. Open the exact page/component configured to consume that key. Change its supported language and compare the result. Return to the translation and confirm the key spelling, group and language code if the original text remains. Inspect the consumer’s lookup rather than inventing a translation binding button in this collection editor.
Check the result: The intended consumer displays the edited language value; otherwise the lookup mismatch is documented.
3. Alternative records and recovery
Why this matters
An organization can customize the translation collection schema. That changes the fields displayed by the form, not the meaning of a failed save.
Follow these steps
Compare the current collection form with the standard Key, Group and Item structure. On a disposable record test a duplicate key and retain the actual validation result. When a save fails do not navigate away until the error has been understood; reopen the persisted record to distinguish saved content from the local form. Keep a missing-language result separate from an invalid key or an inaccessible record.
Check the result: Saved values and consumer behavior are compared independently.
Troubleshooting and recovery
Read the actual error and inspect persisted state before retrying a create or other write. Keep the selected organization, record and operation visible. A saved configuration, permission, provider connection and working consumer are separate checks; verify the one the lesson claims. Reopen after saving and compare a controlled alternate/failure path where the chapter calls for it.
Next steps
You can now follow the module’s setup and check its result. Use the relevant chapter for an alternative, and verify the actual consumer before treating configuration as complete.
Limitations and checks
No matching Translation Manager screenshot was available for this pass; a live create/save/reopen and consuming-page capture are still needed. The form is collection-driven. Its Cancel handler currently only logs; do not promise that Cancel reverts local edits. Consumer binding depends on the actual page/component; there is no binding action in this form. Current form and SDK TranslationSchema inspected; live lookup verification pending.
BusinessMade Translation — supporting guide
BusinessMade entry: Admin → Translation (/admin/translation).
Maintain language strings for the intended consuming application. Translations do not automatically change every product title, receipt, employee record or external message.
Scope: This BusinessMade route uses the shared component whose complete procedures follow. Use the BusinessMade menu and organization throughout. Shared references are implementation evidence, not instructions to switch products. These written steps have not been replayed as a new BusinessMade live walkthrough.
What you will configure
BusinessMade Translation stores a key and its language-specific values. We will create that record, change a translation and verify the consumer that uses its key. This module does not automatically translate every page merely because a language exists.
1. Create a translation key
A stable key identifies the text; the language rows hold what readers see. Group organizes related entries.
Open Admin → Translation and select New Translation. The Details view opens the record form; Translation List returns to saved entries.
Historical unsaved BusinessMade form. The Item section is still empty: its plus button adds a language/value row. This image does not show a saved translation or a translated consumer.
Enter Key using letters, numbers, underscores or hyphens; the standard schema normalizes the key and requires 3–100 characters with uniqueness. Enter Group. Use the Item plus button to add a row, choose Language from the available language list and enter Value. Add another language row for the same key. Save and reopen the record.
Check the result: The saved record contains the intended key, group and both language values.
A small example you can check
Use Key booking_welcome, Group booking, and one Item per language your consuming screen supports. For English enter Welcome to your booking; for Spanish enter Bienvenido a tu reserva. Choose each language from the selector rather than entering guessed language codes. Save, return to Translation List, locate booking_welcome and reopen it to compare both values.
This only creates a translation record. The target screen must look up booking_welcome through its actual translation mechanism. If no screen uses that key yet, finish the record exercise here and have the page/component author add that binding; there is no binding button in this form and no automatic rewrite of every booking screen. When the consumer exists, follow the next section to check it.
2. Edit and verify the real consumer
The correct record can still appear unused if the page or component looks up another key. Test the consuming interface rather than treating a saved record as evidence of rendered translation.
Find the translation by its key. Change one Value and save. Open the exact page/component configured to consume that key. Change its supported language and compare the result. Return to the translation and confirm the key spelling, group and language code if the original text remains. Inspect the consumer’s lookup rather than inventing a translation binding button in this collection editor.
Check the result: The intended consumer displays the edited language value; otherwise the lookup mismatch is documented.
3. Alternative records and recovery
An organization can customize the translation collection schema. That changes the fields displayed by the form, not the meaning of a failed save.
Compare the current collection form with the standard Key, Group and Item structure. On a disposable record test a duplicate key and retain the actual validation result. When a save fails do not navigate away until the error has been understood; reopen the persisted record to distinguish saved content from the local form. Keep a missing-language result separate from an invalid key or an inaccessible record.
Check the result: Saved values and consumer behavior are compared independently.
Troubleshooting and recovery
Read the actual error and inspect persisted state before retrying a create or other write. Keep the selected organization, record and operation visible. A saved configuration, permission, provider connection and working consumer are separate checks; verify the one the lesson claims. Reopen after saving and compare a controlled alternate/failure path where the chapter calls for it. If the consumer does not behave as expected, retain the error and the saved record identity before changing more fields.
Check your result
You can now follow the module’s setup and check its result. Use the relevant chapter for an alternative, and verify the actual consumer before treating configuration as complete.
Limitations and checks
The form is collection-driven. Its Cancel handler currently only logs; do not promise that Cancel reverts local edits. Consumer binding depends on the actual page/component; there is no binding action in this form. Current form and SDK TranslationSchema inspected; live lookup verification pending.
BusinessMade routing and outcome check
The menu and route were checked in packages/ui/src/ui/sidebars/business-made-links.ts and apps/business-made/src/shell/route-registry.ts. Open the module through the route stated at the start, perform the controlled procedure, save, reopen and inspect its actual BusinessMade consumer. Do not infer branch isolation from a header location selection when this shared screen reads organization-wide records. Record any access refusal or consumer mismatch with the exact record identity. No new provider, payment, physical-device or live-tenant action was performed for this adaptation.