Adding translations to fields
What you'll learn
- Why and when to translate a field
- Where translations live in VAT Portal
- How to add Azerbaijani, English, and Russian translations for a field's name and its dropdown options
- What users see when translations are missing
Why translate fields
Static UI labels in VAT Portal (menus, buttons, standard page text) are already translated into Azerbaijani, English, and Russian — they switch when the user switches their interface language.
Custom fields your team has added to document types (e.g., "Expense category", "Travel purpose", "Amount") are different. They show in whatever language you typed them in when you created the field. If some of your users work in English while others work in Azerbaijani, those users will see the same field in a language that may not match their interface — a jarring experience.
Adding translations fixes that. Once a field has translations for a language, users in a session set to that language see the field's name and its dropdown options in their own language.
Where translations are managed
Translations live on the Additional Field detail page. To reach it:
- Open Utilities → Additional Fields.
- Find the field you want to translate.
- Click its row to open the detail page.
Scroll past the General Info and Details cards to the Translations card. This is where you set names and dropdown options in each of the three supported languages.
Step-by-step
The Translations card has a section for each language (AZ, EN, RU), each with two inputs:
- Name — the field's label in that language (e.g., "Amount", "Məbləğ", "Сумма").
- List Def — the dropdown options, entered as a comma-separated list. Use the same separator (
,) as the canonical version, so the order and count match one-to-one between languages.
To add or edit a translation:
- Click into the Name field for the language you want to translate.
- Type the translated name.
- If the field has dropdown options (its type is Dropdown or List), type the translated options into List Def — same order, same separator as the original.
- Repeat for any other languages.
- Click Save at the top-right of the Translations card.
- On success, a small "Saved" indicator appears next to the button briefly.
You don't have to fill all three languages — add only the ones your team needs.
field-translations-cardMatching list options across languages
For dropdown-type fields (list or arr), the list of options is stored once and then translated language-by-language. The system uses the position in the list to map between languages — position 1 in AZ matches position 1 in EN matches position 1 in RU.
If your original English list is:
Low, Medium, High
Then your Azerbaijani translation should be:
Az, Orta, Yüksək
(not reordered alphabetically or by local convention).
If you add a new option to the list later (say, "Critical"), you need to:
- Add it to the original list (in the field's canonical definition).
- Add its translation to each translated language's List Def in the same position.
Forgetting to update a language leaves users in that language seeing a mismatched list.
What users see when translations are missing
If a user's interface is in a language that has no translation for a field, VAT Portal falls back to the canonical definition (whatever was typed when the field was created). So:
- A field with only an English translation shown to an Azerbaijani user → they see the English name.
- A field with Azerbaijani and Russian translations but no English → an English user sees whichever language was the original canonical version (usually the one typed at creation time).
Partial translations are fine — missing ones just fall back. But if you notice users complaining that something is "still in the wrong language", check whether a translation exists for their language on that specific field.
Common questions
I added a translation but the user still sees the field in the old language.
Ask the user to refresh their browser — translations are cached in their session. If the issue persists, double-check you saved on the Translations card (the "Saved" indicator should have appeared briefly after clicking Save).
Should I translate every field on every document type?
Translate the ones your multilingual team will actually see. If a field is only used by one language's team, skip the others — partial translation is fine.
Can I bulk-translate all fields at once?
Not in the UI — each field is translated individually on its detail page. If you have many fields to translate, plan the work in one sitting.
What about translating the field's description or help text?
Field descriptions and help text aren't translated in the current version. Only the field name and its dropdown options.
I have dropdown options with the same display but different data values underneath (like "APPROVED", "REJECTED"). Should I translate those?
Yes — users in other languages want to see words in their language, not internal codes. Use your language's equivalent while keeping the positional order. Note that any routing conditions (set up in Flow Editor) that reference these values compare the canonical value, not the translated one — so changing the canonical spellings could break flow routing. See Using the visual flow editor.
A field was created months ago with a name like "Sum" but it really means "Amount". Should I just change the canonical name?
If the field's canonical name is wrong, yes — edit the field itself to fix it (via the Edit button on the detail page). Translations are about showing the same concept in different languages, not correcting a misnomer. See Managing additional fields.
Can a translation have fewer options than the canonical list?
No — keep them in sync. A shorter translated list means positions won't match and users will pick wrong values. Always translate every option; if the idea isn't translatable, transliterate it.