Manage localization
Introduction
SalaX Secure Mail features multiple default languages that work out of the box. You can further customize almost every word or phrase you see on the Web UI and the email notifications, applying your brand's style and voice.
You can also create and enable additional translations through the Admin Center.
A shortlist of customizable translations:
- Titles, headings, buttons and other textual elements
- Popup messages and error feedback
- Terms of Service entire content
- Email notifications content and their additional translations, if any
You can find all necessary controls in Settings > SalaX Secure Mail > Localization.
Managing localization
Translations
In the main page you can change settings for the Web Interface, Terms of Service, and Notifications. This is also where you can Add New Languages.
Here you will find all the translation keys available to change accross the application. Navigating to the different settings display their options:
- for Terms of Service, you can also require all users to accept the updated terms
- for Notifications, you can select two additional languages to be displayed in the same email notifications users will receive in their personal inbox
- Add New Language starts you off with a template based on the Pre-selected Language. Change the
language_code
key name &language_name
value, then click+ Add Language
. When you are ready to let users see the language you added, enable it onSettings
.
To save your changes, click the Save button.
Settings
Here you find settings related to localization as a whole.
Reset configurations
You can reset Localization configurations to the factory default. You can choose to reset "Localization, Notifications and Added Languages" or "Terms of Service", or both.
Resetting the configuration to factory defaults is an irreversible action that might lead to data loss. Languages you added are also going to be removed as part of the reset process. Plan accordingly.
Enable/Disable Terms of Service
You can choose whether users will see Terms of Service before accessing the application's contents.
Localization settings
You can enable or disable specific languages, filtering which languages users interact with.
You can also set the Pre-selected Language, which will be presented by default to users when they interact with the Web Interface. This language is also used as a base when you Add a New Language.
Changing translations
To make any changes in translations, navigate to Settings > SalaX Secure Mail > Localization. You should be in the main screen with the Translations tab active.
In the Translations section, select the language that you wish to update. The Web Interface, Notifications and Terms of Service tabs will all be related to the language you selected. Navigating to each will display inputs where you can update the wanted values.
Adding new languages
Here you will see that the translations field is pre-loaded with data. This data is based on the Pre-selected Language, offering you a starting template.
This template contains the Web Interface, Email Notifications, and Terms of Service translations.
These translations are necessary for the new language to work. You cannot enable a new language without Email Notifications and Terms of Service translations available for it.
Here is a quick step guide on how you make a new language available to users:
- Provide the
language_code
andlanguage_name
- Update the translations as necessary
- Click "+ Add Language" to save
- Enable the language for users
Now the users can see the new language as an option when they interact with the SalaX Secure Mail's web interface.
Providing the language_code
and language_name
This is how you let the system and users know what language you're adding. Providing these is a basic requirement to add the new language.
- Change the
language_code
key name - Change the
language_name
value
From:
{
"language_code": {
...
"language_name": "English",
...
}
}
To:
{
"nl": {
...
"language_name": "Dutch",
...
}
}
The language_code
is a two-letter identifier specific to that language. Update the key name to the desired value.
The language_name
is the name of the language you are adding. Update it's value.
The values you add here need to comply with the ISO 639-1 standards.
The language code and language name must be unique. They must not be the same as other languages already present in the system.
Update translations
Adjust the new language translations to your needs. When you are satisfied with the changes click "+ Add Language" to save your new language.
This will make it immediately available for you in the Admin Center's Localization settings. You can further edit it now like other languages.
Any newly added language is not yet published - it is disabled by default, preventing SalaX Secure Mail users from interacting with a language you just added. When you are comfortable with the translations you provided, enable the new language.
Enabling the language
Navigate to the Settings. Enable the newly added language and save your settings.
Before enabling the new language make sure the it has all the necessary translations. Once enabled, the language will be available for users to interact with it in the Web Interface.
Updating Terms of Service
Here you can change:
- Accept and Decline buttons text
- The dialog (pop-up) heading text
- Terms of Service's title - that is, how it is referred to by your company eg: usage license agreement, terms of use, etc
- Terms of Service's contents
Every altered version of Terms of Service localization is stored within the system, ensuring a comprehensive record of changes for future reference.
Requiring acceptance of updated terms
When updating Terms of Service, you can require that all users accept the new version. Marking this option will present the updated version to all users when they access SalaX Secure Mail's web interface.
This allows you to perform small translation fixes or formatting adjustments without disturbing your userbase, while maintaining your control over when to prompt the user for Terms acceptance.
If enabled, Terms of Service acceptance will be required of users before gaining access to the system. If users decline the option, their access is then terminated.
Updating email notifications
Here you can change the translations for the various email notifications in use by the system. Additionally, you can select a second and third languages to be displayed in the notification body, as multilanguage support.
Selecting additional languages
For a language option to appear in the second and third language selectors, it should exist and be enabled.
You cannot select the same language to appear in the second and third languages simultaneously, and you cannot add a third language without selecting a second.
Additional languages you selected will be displayed in the email notifications sent to user's personal inbox, allowing your communication to be broader and more effective.
Updating the web interface
Here is where you can change every word that the Web Interface displays to the users: heading texts, titles, messages, pop-up messages, button names, input labels, error messages.
They are all displayed in a list of key:value
pairs nested in a JSON
object.
To change a specific text, simply overwrite the value
part of the key:value
pair.
Example: change "Hello World" text
{
"globals_welcome_to_product": "Hello World"
}
We could change it's value to:
{
"globals_welcome_to_product": "Welcome to SalaX Secure Mail"
}
The resulting string in the Web Interface is: "Welcome to SalaX Secure Mail", instead of "Hello World".
Do change the value
in the key:value
pairs.
Do not change the key
names. The Web Interface depend on those to know what text should be displayed.
Please be sure that the changes you made work and perform to your satisfaction. You can do that by navigating the Web Interface.
Possible errors include expected strings to be missing, unexpected strings to be displayed and unexpected UI errors.
Translation keys and internal references
You can reference any key's value inside another key, composing powerful translations that are easy to update.
The syntax to do it is simple: the key name between curly braces {}
preceded by the symbol $
- as in: {$globals_application_fullname}
. Note that there is no space between the braces.
We call this internal referencing
. The resulting value is an interpolated string containing the referenced values as formatted in the string itself.
Here's a complete example:
{
...
"globals_terminology_reference_otp": "One-time Passcode",
"authentication_sms_otp_notification_success": "{$globals_terminology_reference_otp} validated successfully",
...
}
In this example, we have a key describing how we want to refer to OTP's in our application, globals_terminology_reference_otp. It's value is "One-Time Passcode".
We have another key with a translation referring to the first key:
{$globals_terminology_reference_otp} validated successfully
The final value for the key authentication_sms_otp_notification_success
as displayed in the Web Interface would be: "One-time Passcode validated successfully". So that's what the user would see when they successfully authenticated with their SMS OTP.
There is a set of keys named with the preffix globals_terminology_reference_
that empowers your communication to be more consistent accross various usages.
Anytime you change these keys, it will automatically update everywhere else in the application that uses it via internal referencing
.
Here's a summary:
- Find the key whose value you want to reference. Copy it's key name.
- Find the keys where you want to apply that reference. Add the reference there between curly braces (
{}
) preceded by a$
, as in:{$key-name}
. Replacekey-name
with the key you copied in step one.
Other references
There are two other ways where a slightly different interpolation syntax is used for different purposes and outcomes.
"compose_mail_response_sender_detail": "On {dateLine} {msgFromLine} wrote:",
Note the absence of the $
sign.
and
"page_authentication_mail_otp_sent_check_inbox_prompt": "Please check your inbox at {+{email}+} to continue.",
Note the {+{ }+}
structure.
Both are references to in-memory variables that inform the user. The second example is an internal styling template to mark some part of the text that should be bold.
Referencing these in other translations is unadvisable, as the results might be unexpected.
In general, do not reference these variables elsewhere. Avoid tampering with these template usages.
Using the form in the second example does not make every text bold.