Multilingual Sites Support is easy in 19.1.3 Oracle Content and Experience (OCE).
A Multilingual Site (MLS) is a site available in more than one language. Even though the page structure and content are the same for the site, the language requested could be different. In 19.1.3, Oracle Content and Experience (OCE) supports the ability to translate from one language to other languages easily.
When building an enterprise site, you must select a default language. This default language is important in two regards:
- Access to the site using the default site URL is rendered using default language.
- https://<server>/site/<mysite>
To access other translated languages used by the site, you can used URL format with <language-locale>:
- https://<server>/site/<mysite>/<language-locale>
For example, accessing Portuguese (Brazil) (pt-BR) would use:
- https://<server>/site/<mysite>/pt-BR
If you try to access a language not translated by the site, the default language will be used.
2. Updates to the site are done in the default language and the site is translated into other languages.
An enterprise site must have one or more required languages. It may have option languages. Such information is represented by a localization policy. A localization policy is a business rule that determines which languages the site must be translated to before it can be published. A site can be published only when it has been translated to all required languages in the localization policy.
For this blog, we will begin with a site generated from an out-of-the-box template. We will use the default/required language, English (United States), and an optional language, Portuguese (Brazil). Then we will create a translation job to pull out the strings necessary for translation. We will translate from English (United States) to Portuguese (Brazil). Lastly, we will import the translation back to OCE and show how it can be tested. To simplify this blog, we will not deal with Assets, which will be covered in another blog.
Before we can create an enterprise site, we have to create the localization policy and repository. The localization policy determines the languages a site will be available in. Let’s create a localization policy that has the required language, English (United States) (en-US), and an optional language, Portuguese (Brazil) (pt-BR).
Next we will create a repository. The repository is used to contain any assets used in the site, and is required for site creation. We will cover adding assets to a multilingual site in a separate blog.
Now we have to create the site. The template used will be the out-of-the-box template Access.
The repository will be access-repos1, created earlier. The localization policy will be access-local1, created earlier. The default language will be English (United States) (en-US). Since the default language of the site is English (United States) (en-US), accessing the site without a locale in the URL will display in English. For example, both the following URLs will display the site in English:
- https://<server>/site/access
- https://<server>/site/access/en-US
That will create the site. We are not going to modify the site, but will just use the pages in the template at the moment, to keep things simple. But it should be noted that when updates are made to the site, they will be done in the default language only.
Now we are going to translate the site. To start the translation of a site, select it, and then choose Translate on the More menu to invoke the Create Translate Job dialog.
In the Create Translate Job dialog, enter a name (that is, access-translate1), English (United States) (en-US) will be used as the source language as that is the default language of the site. Pick Portuguese (Brazil) (pt-BR) as the target language.
After the translation job is created, you can click Translation Jobs to see the list of site translation jobs.
Clicking on a particular translation job will show the details of the job, such as source and target languages and status.
Click the Download link to download a zip file of the translation bundle. The translation bundle looks like this:
In the translation bundle, you can see a site folder that contains job.json and a root folder. The job.json file contains the translation job name, a list of pages, target/source languages, and so on. The root folder contains siteinfo.json, structure.json, and pages’ json. The siteinfo.json contains translatable strings such as header, footer, description, and keywords. The structure.json contains translatable strings such as page names. The pages’ json contain a list of translatable strings from components added to the page. Everything under the root folder should be duplicated and translated for each target language.
For this exercise, we will be translating everything under the root folder to another folder, pt-BR for Portuguese Brazil. Folders root and pt-BR will be under the same folder, called sites. For this exercise, you can download the already translated pt-BR.zip and unzip it under the site folder at the same level as the root folder. That will provide the translation for Portuguese Brazil (pt-BR). This is what it should look like for the translation bundle after pt-BR.zip has been unzipped under the site folder.
As an example, site/pt-BR/structure.json which contains the page names, will be translated like this for Portuguese Brazil (pt-BR):
After the translation is done, the entire site folder must be zipped so that it can be imported back into OCE. To create the zip file, for example on Mac, click the site folder and pick Compress “site”. On Windows, right click the site folder and pick Send to > Compressed (zipped) folder. The top-level folder in the zip file has to be the site folder. You can call the zip file whatever you want. It does not have to be called site.zip. Then this zip file can be imported from the Import link on the Translation Jobs page.
The zip file would be uploaded to OCE using the Upload link.
Once the zip file has been uploaded, the following dialog will show the summary before the import operation.
After the import of the translation is done, you can test the translated site by selecting the language in the site’s dropdown menu and viewing the site.
This is a quick example of Multilingual Sites Support in 19.1.3 Oracle Content and Experience (OCE). The feature makes translation of the site easy.
Lastly, language service providers play an important role in the translation process. They make it easy for translators to find out the translation status, keep track of translation artifacts and version dependencies, and provide other translation assistance. To best use Multilingual Site Support, Oracle recommends that you use a language service provider in the translation process.
