Partners can select their preferred language while logging into CTK. By default, CTK supports three languages namely- English, French and Arabic.
To add support for an additional language, below are the steps to be followed:
Step 1: Add an additional language to the CTK login page.
Step 2: Add a new resource bundle (i18n JSON) file for the new language.
Step 3: Translate each page label.
Step 4: Translate validator description.
Step 5: Translate every testcase in the resource bundle.
Step 6: Translate all the service-generated validator messages.
Step 7: Translate all the service errors.
Step 8: Build and deploy the code.
Let us understand the steps mentioned above with more details.
The user can add a new language support to CTK via Keycloak.
to do so, create a locale for a new language in localization.
Add a new locale in the supported locales field.
For example: New locale es
for Spanish language.
It will be added to the CTK login page once the changes have been saved.
The i18n folder is available under assets folder in UI codebase.
Create a new JSON file in the folder.
For example: In Spanish language, the file name should be es.json
.
Copy the eng.json
data and paste it in es.json
.
When translating into a new language, we should solely translate only the right-side values using a translation service (such as Google Translate).
For example: Take the first page (Project Dashboard)
In each page, the labels are on the left and values are on the right.
The figure below highlights the page labels along with their values.
Also translate the labels on all pages.
All Validator descriptions have been added to the resource bundle. The names of validators are their labels, and their descriptions are their values.
Here is an example of validator description added in resource bundle.
Translate only the right-side values.
If a new validator is added, a resource bundle must be added as well.
Translate the values of testName, testDescription, and androidDescription. The code will use the testcase data in accordance with the testId.
If you add any new testcases in the future, you must include them in the resource bundle.
Here is an example of testcase added in resource bundle.
All the service-generated validator messages have been added based on the below cases.
For example:
case 1:
There are no arguments in this case.
Example of validator message in a resource bundle:
The validationResultDto
now contains an additional attribute called setDescriptionKey
. This will help to take validator messages from resource bundle.
Example code for setDescriptionKey:
case 3:
This case contains more than one argument in the validator message.
Example of validator message in a resource bundle:
{} – This will represents the arguments value.
Example code for setDescriptionKey:
Here ARGUMENTS_DELIMITER is ::
and ARGUMENTS_SEPARATOR is ;
Example of service errors added in a resource bundle given below.
Error codes are on the left and error messages are on the right.
You need to build code after completing the steps listed above.
After building, you can deploy the code.