Languages and currencies - KayanOS Documentation

Languages and currencies solve different problems. A language record makes a language available to the organization and describes its direction; a currency record describes a selectable monetary unit. Neither setting automatically translates a custom field, converts an existing amount, changes an exchange rate, or grants access to financial records. For the Directorate of Citizen Services, Arabic and English must express the same service meaning, while a configured monetary field can use an organization-approved currency such as SYP when the service policy requires a fee or amount. Keep language governance and financial-data governance separate.

Goal

Activate and maintain usable languages, including Arabic right-to-left quality checks, and configure currency records with correct identifiers and decimals without misrepresenting stored money values.

Language record versus currency record

Setting	Stores	Primary effect	Does not do
Language	Title, code, native name, text direction, and active/inactive state	Makes an approved interface/content language available to organization configuration and members	Translate unlocalized custom data or rewrite existing record values
Currency	Code/ID, title, symbol, ISO code, decimal places, and active/inactive state	Defines a currency option for features/fields that use configured currency records	Convert historic amounts, supply an exchange rate, or alter a field’s numeric value

Changing a language is a content-quality decision. Changing a currency is a data-definition decision. Both require a named owner, a review of current use, and a safe test before a wide rollout.

Before activating a language

Confirm that the language has an approved display title, stable code, and native name.
Select the correct direction: Arabic is right-to-left; English and Turkish are left-to-right.
Inventory user-facing custom data: entity titles, field labels, select/status choices, form text, document templates, dashboard labels, portal copy, and notification wording.
Decide who reviews terminology. For the Citizen Service Request lifecycle, agree that Received, Completeness review, Inspection scheduled, Decision review, and Closed carry the same operational meaning in both languages.
Check whether the language must be active before it can be selected as an organization default or a member preference.
Plan an RTL acceptance test on the devices staff actually use. Do not approve Arabic based only on a translation spreadsheet.

Create or update a language record

Open Administration → Languages and currencies → Languages. The language form contains:

Field	Guidance
Title	A clear administrative name such as Arabic or English
Code	A stable language code used by configuration; do not casually rename it after content depends on it
Native name	The name displayed to speakers of that language
Direction	Select LTR or RTL; Arabic requires RTL
Status	Active makes the language available; inactive removes it from active choices without translating/removing existing custom content

Use the following workflow:

Create or update the language record with the approved code and direction.
Save it as active only after required terminology exists.
In Organization settings, select it as a default only when it is active.
Switch a controlled member between the relevant interface languages. The current user menu offers English, Arabic, and Turkish.
Open the Directorate’s request, task, form, notification panel, calendar, and a document/template preview. Check direction, truncation, dates, numerals, mixed Arabic/English labels, and serial references such as CSR-2026-00042.
Record defects against the specific field/template/label owner. Do not change a stable field key merely to change a translated title.

An inactive language is a controlled availability state, not a content deletion tool. Before deactivation, check defaults, member preferences, public portal content, and documents that still rely on it.

Configure currency records

Open the Currencies area. A currency record has separate display and identifier fields:

Field	Requirement in the current form	Example policy use
Title	A multilingual title with at least two characters in each maintained locale	Arabic/English business names approved by finance
Code/ID	Exactly three uppercase letters	Stable internal currency key
Symbol	Non-empty and up to four characters	A recognizable display symbol
ISO code	Exactly three uppercase letters	Interoperable reporting/export identifier
Decimal places	Whole number from 0 to 6	The precision approved for that currency
Status	Active or inactive	Whether it is available for new configuration

Edit the title through the locale-aware title control rather than replacing one language with another. Switching the title editor between English and Arabic retains the other locale, and saving submits the complete multilingual title. Verify both labels anywhere the currency is selectable; a translated display title does not change the stable code or ISO identifier. For a Directorate fee field, create or verify the approved currency record first. Then configure the monetary field, calculation, form, document, or report that consumes it. Selecting a currency changes how that configured feature identifies/displays money; it does not recalculate existing numbers. If the organization changes a fee policy or currency basis, define the business migration with finance and service owners before touching historical records.

Directorate scenario

The Directorate activates Arabic with RTL direction and confirms English remains active for bilingual staff. The language owner verifies that the Arabic title for Citizen Service Request and each lifecycle status is approved. A Registry Officer switches language, opens a controlled request, and confirms that the serial reference remains left-to-right and unchanged. Separately, the finance owner verifies the active currency record used by the estimated-fee field. The team creates a non-production request with an amount, confirms the configured symbol/decimal display, then compares the stored numeric amount before and after language changes. The number must not be converted merely because the interface language changed.

Validation checklist

Test	Expected result
Arabic language record	Active, RTL, and selectable as an active organization/member choice
Arabic UI review	Sidebar, menus, forms, dates, and custom labels are readable right-to-left; stable IDs and keys remain unchanged
Inactive language	Is not offered as an active default; existing stored content is not silently removed
Currency code	Code and ISO code validate as three uppercase letters
Decimal precision	The form accepts only a whole value from 0 through 6
Currency display test	The configured monetary field renders the chosen record without changing the stored amount
Historical record test	Existing fee/amount records remain intact after a language or currency-record administration change

Use controlled records. Do not use a live citizen payment or a production decision to demonstrate currency settings.

Troubleshooting

Symptom	Check first	Safe response
Arabic is not available in a language choice	Language status, code, and organization active-language configuration	Activate and test it before selecting it as a default
Arabic screen direction is wrong	Language direction, reload, and component-specific RTL support	Capture the exact screen and correct the language/UI configuration
Custom labels remain English after switching	The custom entity/form/status/template lacks Arabic content	Add approved Arabic content; do not rename the stable key
Currency form rejects a code	Three-letter uppercase validation for ID and ISO code	Use the approved three-letter identifier; do not use a numeric amount as a code
An amount changed unexpectedly	The field/calculation/document mapping, not merely the currency record	Stop the rollout and investigate the affected data path with the service/finance owner
A currency disappears from new choices	Currency status is inactive or the consuming feature is configured differently	Review status and feature configuration before changing historical data

Set active defaults in Organization settings.
Check personal language switching in Profile, language, and signatures.
Define currency-bearing entity fields in Entity fields and layouts.
Use reliable amount derivations in Calculated fields.

KayanOS language and currency settings for the Directorate of Citizen Services.

​Goal

​Language record versus currency record

​Before activating a language

​Create or update a language record

​Configure currency records

​Directorate scenario

​Validation checklist

​Troubleshooting

​Related guides