How to support multiple languages within a single application

Wed, 02/11/2009 - 10:51 — admin

Intermediate

It is usually convenient to have the ability to deploy the same rich media service in multiple countries.
One of the issues to deal with is then to be able to support multiple languages within the same application.

Handling such issue requires specific conception:

Client-side: we want to obtain a single application package / installer whatever the language the rich media content should be displayed into. So we have to make the pre-embedded rich media scenes adapt to the supported language the end-user will like the application to be displayed into. This is the subject covered in the present tutorial.
Server-side: we want the dynamically generated rich media scenes to be adapted to the current language. This is usually achieved by providing the application current language code in any request, adaptation being quite easy to achieve relying on usual RSP facilities (Java coding). This is also what will be used for developing language dependent client-side scenes.

To cover the "one single-package / multiple languages support" paradigm, some features have been granted in Streamezzo solution in order to provide the ability to:

Adapt local rich media content according to current application language
Package the installer for an application with multiple supported languages

As you will see below, one of the upmost important matter to deal with was to keep the pre-embedded / local rich media content as light as possible.

Principle

We provide an internal client-side mechanism to access the appropriate rich media content according to current application language:

Current language: application language identification
- Ability is given to retrieve the system language code. This can be used as default at the application first launch in order to display it in this language if supported (i.e. this case shall also be considered and then the application language shall be set to a predefined default language, among the supported ones). At any later launch the last selected language shall be used (i.e. respect end-user's choice).
- Ability is given to store and consult the last set application language code.
Client-side / Local content access: appropriate content selection
- First, application language specific rich media content is looked for.
- If available, it is used / displayed. Else (i.e. no current application language specific content is found/available) the default (i.e. not language dependent or displayed in a default language) rich media content will be used / displayed.

It is important to notice that each scene, whatever the set of languages it is supposed to support, can be developed as a single RSP. Indeed during the application packaging (client package creation) all scenes that are dispatched client-side will be processed, just like any remote RSP, for each supported language.
Here is the development and deployment process that is followed:

Whatever the scene being intended to be deployed client or server side, it is developed as a single RSP.
If the scene content is supposed to be language dependent, all language specific parts will be generated based on one criteria which is the predefined language code that is supposed to be passed to the scene processing.
When creating the client package, all languages (i.e. codes) that are supposed to be supported have to be specified per scene, including which one is the default language.
Then all client-side distributed scenes will be processed for the default language (i.e. we obtain the common / shared content, which is also the default content displayed in case there is no specific exception defined).
... and for each additional language they are supposed to support (i.e. language defined exceptions).

This means a given scene supposed to support N languages, will be processed as N distinct rich media contents (the selection of the appropriate content will be operated client-side at runtime, following the process detailed above and illustrated below).

The figure below illustrates the localized rich media content (scene) selection (here all scenes are supposed to be client-side).

localized scene selection

It shows language specific rich media content can be displayed for a given application language, and by default a common / non language dependent rich media content will be displayed.

If we assume current application language is french (see workflow in blue)
- End-user first accesses scene A.
  - Scene A in french version is looked for, first. Here this scene is not language dependent, so it is not available in french flavour.
  - Scene A is so displayed in its default configuration applicable whatever the current application language is.
- End-user then accesses scene B.
  - Scene B in french version is looked for, first. Here this scene is language dependent, and it is available in french flavour.
  - Scene B is so displayed in french.
- End-user first accesses scene C.
  - Scene C in french version is looked for, first. Here this scene is language dependent, but it is not available in french flavour.
  - Scene C is so displayed in its default configuration.
If we assume current application language is english (see workflow in red)
- End-user first accesses scene A.
  - Scene A in english version is looked for, first. Here this scene is not language dependent, so it is not available in english flavour.
  - Scene A is so displayed in its default configuration applicable whatever the current application language is.
- End-user then accesses scene B.
  - Scene B in english version is looked for, first. Here this scene is language dependent, and it is available in english flavour.
  - Scene B is so displayed in english.
- End-user first accesses scene C.
  - Scene C in english version is looked for, first. Here this scene is language dependent, and it is available in english flavour.
  - Scene C is so displayed in english.

Features

Managing current application language

Get system language code: cmd://getSystemLanguage?DEF=[my_Text_Node_DEF]
Get application language code: cmd://getApplicationLanguage?DEF=[my_Text_Node_DEF]
Set application language code: cmd://setApplicationLanguage?code=[my_language_code]

Developing language dependent scenes

Specify the name of the URL parameter that will transport the language code in each request (in the language tab in the project Service settings when using Workbench Developer)
When implementing RSP code, for rich media parts that are language dependent, consult this URL parameter (i.e. the language code) and generate the appropriate rich media content accordingly.


	String language = stzRequest.getRequestParameter("__lang__");
	...
	if ((language != null) && (requestedLanguage.equals("en"))) {
		...
	}

Configuring an application supporting multiple languages

(optional) Specify the default language for the application (in the language tab in the project Service settings when using Workbench Developer): will force the application default language (i.e. used at first launch).
For each client-side scene, specify the set of additional (i.e. in addition to the default one) languages (i.e. list of language codes) it is supposed to support (in the language tab in the project Service settings when using Workbench Developer): this will mean such scene contains language specificities and thus must be generated in each of those languages.

Emulating an application supporting multiple languages

(optional) Specify initial application language (in customization section in emulation dialog box when using Workbench Developer): simulate the device currently set system language
Specify the subset of supported languages to process the client-side scenes for (in customization section in emulation dialog box when using Workbench Developer): scenes that have been specified as supporting those additional languages will be processed against each language of this set.

Packaging an application supporting multiple languages

Specify the subset of supported languages to process the client-side scenes for (in Processing languages section in client pacckage creation dialog box when using Workbench Developer): scenes that have been specified as supporting those additional languages will be processed against each language of this set.

Typical example

The coding example below stands for the example illustrated above.

Implementation

Scene A

Scene B





	

	<%
		// identify scene requested language (passed as predefined URL parameter)
		String sceneLanguage = "default";
		String requestedLanguage = stzRequest.getRequestParameter("__lang__");
		if ((requestedLanguage != null) && ((requestedLanguage.equals("fr")) || (requestedLanguage.equals("en")))) {
			sceneLanguage = requestedLanguage;
		}
	%>

	
		<%
			String backgroundColor = "#FFFFFF";
			if (sceneLanguage.equals("fr")) {
				backgroundColor = "#0000EE";
			} else if (sceneLanguage.equals("en")) {
				backgroundColor = "#EE0000";
			} 
		%>

Scene C





	

	<%
		// identify scene requested language (passed as predefined URL parameter)
		String sceneLanguage = "default";
		String requestedLanguage = stzRequest.getRequestParameter("__lang__");
		if ((requestedLanguage != null) && (requestedLanguage.equals("en"))) {
			sceneLanguage = requestedLanguage;
		}
	%>

	
		<%
			String backgroundColor = "#FFFFFF";
			if (sceneLanguage.equals("en")) {
				backgroundColor = "#EE0000";
			} 
		%>

Project configuration

Emulation configuration

Packaging configuration

Known limitations

Depending on the device, system language code may not be retrievable (empty value is retrieved then).
System language code (supposedly ISO 3166) may vary depending on the platform (example: "fr" vs "Fr_fr").

Attachment	Size
Multilanguage.swz	3.91 KB

Copyrights

Secondary links

Syndication streamezzo

Streamezzo developer's corner

Primary links

Search