Websydian v6.1 online documentationOnline documentation - WebsydianExpress v3.5

Language Support Step-By-Step

Overview

This step-by step guide provides an overview of how to update a WebsydianExpress site from a single-language environment to a multi-language environment.

This task involves a number of steps that will each be described below.

Most of the steps

1. Investigate application

Before you can move from a single-language environment to a multi-language-environment, you must first analyze your own application. This document will not attempt to go into details with how to perform this investigation, as it will differ significantly from case to case.

What this section will do is to go through the tools that WebsydianExpress provides that can help in solving the issues that you might find in your investigation.

Data

What data you want to be able to show in a translated version and how to translate this date is outside the scope of this document.

Finding the language of the session

When introducing language support, one of the tasks you will have to do many times is to find the current language of the session. In the abstract functions PageGeneratorForProcess, EventHandlerForProcess, and ProcessEntryPoint, this information is found as part of the initialization - the information is written to the local field LanguageCode in the variable Language.

If you need this information in other programs, you can find it using the APIServer.Session.GetLanguageCode. For this you will normally need the identification of the current session, you can find this using APIServer.Session.ServerGetCurrentSessionID.

Messages

In many cases, your programs will generate texts that will be shown to the users - this can e.g. be validation errors or other informational messages.

Common ways to create such messages in Plex is using either literal values for fields or message objects (using format message) for assigning a value to a field in WsyDetails or WsyGrid.

This will of course only give you one language version of the message - so you will have to introduce a system that can handle these messages in several languages.

You can build your own functionality for handling this or you can use the abstract CreateTextMessage function to provide you with this functionality.

This means that for each place in your application where you use a format message or assign a literal value to a field that is shown to a user, you have to consider replacing this with a function inheriting from Abstract.CreateTextMessage.

2. Create languages

For each language, you want to be able to handle, create the language using the language maintenance in the administration interface.

Creating the messages also opens the possibility to assign languages to the relevant entities.

3. Update site settings

On the site settings, you can update the default language for the site. This is the language that will be used for all users who have *Site specified as language. As all existing users at this point has *Site specified as language, this is an easy way to set the language for all users that has been created previously to the language that has been used as the only language of the application.

The site settings also specify an anonymous user. This profile that is used to assign roles, folder list, and language to any session where no user has logged in. Change the language for this user to control the language anonymous sessions should use.

4. Assign language to users

For each user, you must consider which language to use.

If you want to let the user select this himself, you can use the example business process: _BusinessProcesses.ChangeLanguageForSession as a template for how you make a business process that will let the user select a language for the current session - you will have to add a call to the API: APIServer.User.SetLanguageCode to update the language for the user.

5. Translate menu item texts

For each child to a menu in the site structure, you must select the child element (menu item) and press "Translate". This gives you the option to translate the text shown for the menu item when the menu is loaded.

6. Translate templates

Create new physical folders

For each folder you have specified, create a new physical folder for each language.

Create new WebsydianExpress folders

Use the "Copy" button on the folder maintenance grid to create a copy the WebsydianExpress folder for each language.

As the administration interface is not available in several languages, you do not have to copy the adminxx folder.

Create translated templates

For each template in the base folder, you have to create a translated version (if the template contain any translatable texts). As you create the translated versions, move them to the folder specified for the language.

7. Change folder lists

For each folder list, you have specified, change the folder list so that it contains the existing base folders - but precede each folder with all the translated versions of the folder.

So if you have a folder list:

1. Customer

2. Basic

And you have created the languages English and German; you would get the following folder list:

1. Customer - English

2. Customer - German

3. Customer (Base)

4. Basic - English

5. Basic - German

6. Basic (Base)

When the runtime tries to find a template, it will search through all folders in the folder list that either has the same language as the session or has the base language.

In this way, you can translate a few templates at the time - just copy the translations to the appropriate folders as they are made.

8. Translate system texts

The texts written to the user by the WebsydianExpress runtime must also be translated. Examples of these texts are the messages shown to the user when he has tried to log in but failed and the message shown when a session has timed out.

You can translate these texts using the Internationalization→Messages maintenance in the administration interface. Select Type = *TextMessages to show the text messages used by the WebsydianExpress runtime - Select Category: System to limit to the system messages.

Most of these messages are used by the administration interface. So, unless you plan to translate the administration interface you should not have to translate all of the texts.

9.Translate message log messages

This is an optional step that you can perform if you want to be able to show the message log in different languages.

You translate these texts using the Internationalization→Messages maintenance in the administration interface. Select *Log messages for the Type to only show the messages that will be written to the log.

10. Administration Interface

The administration interface is only delivered in an English version. You can, if you absolutely must, translate the templates and the texts and messages used but this is quite a task.

The administration interface can and will be updated as part of the normal release of new versions of WebsydianExpress. When this happens you must do any translations necessary yourself. There will be no support for this in the update process.