multi-language management
Website globalization enables companies to significantly
increase the return on their existing investment into infrastructure,
content development, engineering and overall marketing activities.
The main goal of successful website globalization is to provide
access to the site's content and functionality to visitors in other
target markets and in their own languages.
Globalization usually requires application localization or in other terms the process of translating the contents into different languages and so adapting the application for a specific country or region.Application localization is necessary when the contents are shared and they are accessible by users that speaking different languages.
OBEROn can reduce the
complexity of multi-language management and lets you to focus on
the application content. It provides an internal translation dictionary able
to manage all label translations, included the form multiple selection
items (sub-keywords). OBEROn manages an unlimited number of languages;
keywords are organized into an unlimited number of sections to reduce
the access time. Each keyword or sub-keyword may have the related
translation for several languages. The access to the dictionary
is guaranteed both inside the trigger/method source code and the
JSP pages: this allows to overcome the limitations of i18n translation
files which are accessible only inside the application server. Moreover
you can export and import translations in XML and Excel formats.
Adding languages and creating sections
In this lesson we will see how to apply language translations to
the web-application labels. In the previous lesson we have created
a new application with a menu structure: each menu item
(command) has a label, we want now translate these labels for the
specific user language.
For this purpose, OBEROn provides an internal dictionary
with UTF-8 charset. First, you have to define which languages you
want to manage: to define a new language it is sufficient to add
a translation for a single label. You can add how many languages
you want and this doesn't require to translate all label for each
defined language. If a label hasn't the corresponding translation
for the user language it will be shown without translation.
Moreover, the OBEROn dictionary is subdivided into sections;
this reduces the translation search space and increases the overall
performances.
To define a new language select the Add Item(s) command from the
Dictionary menu and insert the first translation for the new language.
You can use maximum 3 chars for the language code, if you use more
than 3 chars it will be truncated.
Repeat the steps for all languages you want to manage.
It is also possible to add new language or new section every time
you need it using this tool.
You can see the result of the operations
by opening the dictionary with the "Edit Dictionary Items"
button. Select the section where you where you are going to operate
from the left-bottom list (it contains all previously defined sections):
you should see a column for each defined language.
Adding / Editing / Removing translations
It is possible now to add new labels or delete one or more labels
in the table or edit the language translations (only for those already
defined) into the selected section.
dictionary
put 'DefineCustomer' language 'IT' section 'Menu' value 'Nuovo
Cliente'; |
After you have inserted a label translation for the first language,
you can add the translations for the others by compiling corresponding
the table cells (and finally saving the changes).
The OBEROn internal dictionary has many usages, in particular you can translate:
- labels for application menus
- the field range values ( key = field name and subkey = range value )
- any application-form label
- names of action and decision workflow-steps
- platform error/notification messages
- everything you need to use inside the application by keyword substitution <[section_Name,keyword]>
In addition, you can use the dictionary to store simple tables; for example if you need the ZIP codes for some countries, you can create a new section called "ZIP Codes", use the key as the country code (USA,FR,UK...), the subkey as ZIP code and the translation (for a virtual language "XX") to keep the city names. The dictionary OOQL commands will help you to manage this table and to perform queries for information retrieval.
Setting up a multi-language application
It is very important to set the dictionary parameters into the main
application menu. In particular, when a menu is set as application
menu, you can find the dictionary features "dictionary_menu_section"
and "dictionary_common_section" . These parameters
identify the dictionary sections where the application can find
translations for the menu/command labels and for the common labels
respectively.
The best practice is to create a dictionary section for each application-module,
but there are labels that are common for all modules (like the words:
view, user, navigate, class, object and so on) so the common translations
should be collected in a common section. If you want to put menu
and common translations into the same section, set both feature
values with the same section name.
When the application is identified with a portfolio menu, the parameters are generally associated to this element but you can have different dictionary_section one for each application; f not specifically declared inside the form or the view elements, the search space for label translation will be the union of all these dictionary sections.
Exporting / importing dictionary
translations
Translations can be exported from one OBEROn database and
imported into another. These operations can be performed by OOQL
commands or directly with the Context Design client. From version
1.5 you can find in the "Dcitionary" menu the following
commands:
- export: extracts translations into a local
file
dictionary
select A*,C* language IT,EN section SR*,Common |
|
exportfile
'C:/Temp/dict.xml' xml ; |
Language: list of language patterns to be exported
Section: list of section patterns to be exported
Keyword: list of keyword patterns to be exported
SubKey: list of sub-keyword patterns to be exported
Value: list of translation patterns to be exported
You can use the usual "*" and "?" wildcards
to indicate "any number of characters" and "a single
character" respectively inside a pattern and the comma (,)
character between patterns to define the pattern list.
File: is the name of a new or existing file to which to write
the export data.
XML: if activated, exports the data in xml format
Excel: if activated, exports the data into an Excel datasheet
Append: if activated, appends the export data to an existing
file.
XML Format:
Excel (XLS) Format:
- import: loads some translations from a local file
dictionary
import A*,C* language IT,EN section SR*,Common |
|
importfile
'C:/Temp/dict.xml' xml ; |
Language: list of language patterns to be imported
Section: list of section patterns to be imported
Keyword: list of keyword patterns to be imported
SubKey: list of sub-keyword patterns to be imported
You can use the usual "*" and "?" wildcards
to indicate "any number of characters" and "a single
character" respectively inside a pattern and the comma (,)
character between patterns to define the pattern list.
File: is the path and name of the existing file from which
to import the translations.
XML: sets the import file type as XML
Excel: imports the data from an Excel datasheet
Search and add all missed
translations to the dictionary
When you create new applications, you need to define menus, commands, forms, views and all other elements for the user interface. Each of these can have labels and texts to be translated into the user language and it is very common to forget to add these translations to the dictionary when they are numerous. OBEROn provides a very usefull tool to help the developers in this work: the Dictionary Check process extracts all potential translable labels from the the schema and verifies that they are correctly mapped inside the dictionary; otherwise you can decide to add them automatically in such way that way as you need only to edit the translations for the different languages.
dictionary check language 'EN' |
|
isection 'PLM_Application' (common,menu,application,custom) ; |
Language: the default language used to check the presence of keywords and eventually to add the missed items to the dictionary (the keyword translations for the default and other languages can be updated/added later in the dictionary table)
Section: specify the type of sections to verify for the selected application:
|
common |
a set of predefined common labels |
|
menu |
all labels for menus and commands associated with the application |
|
application |
all class, linktype, filetype , form and view names associated with the application and workflow step decision choices |
|
custom |
all form-item translations (labels, section/label/button texts, field ranges and href/image/embed url replacements), all view-column labels; all workflow step translations ( href , mail subject and body replacements ) , all command href replacements |
If the application is specified, the translations are added to the dictionary section declared in the application parameters: common->dictionary_common_section, menu -> dictionary_menu_section , application & common -> dictionary_section / tag specific section
Update: if checked adds the missed keywords to the dictionary, otherwise generates only the OOQL commands to add them manually
Log File: when specified, the check result is written into it
|