Liferay Portal is designed to handle as many languages as you want to support. This is done by pulling out all language specific text and storing it in the
language.properties files. This way, when a page loads, Liferay Portal will detect the language, pull up the corresponding language file and display the text in the correct language.
With this you can:
- Easily support as many (or as few) languages as desired,
- Have a central location for multiple languages,
- Change the way a certain word is translated. If you want, you could effectively rename the "Message Boards" portlet to be called "Forums".
Liferay Portal has many properties that can be easily configured to customize the portal. These properties can be found in the
portal.properties file located at
…/portal-impl/classes/portal.properties. To modify the default values of these properties, create an EXT version of this file containing only the values you want to override.
Setting the Default Language and Default Country
You'll find the below settings in the
# # This sets the default locale of the portal, overriding the properties # "user.language" and "user.country" specified in system.properties. # # company.default.locale=en_US
Setting up a Unique URL for Different Languages
Liferay Portal allows you to provide a unique URL for a specific language via the I18nServlet. Examples are:
The mappings for this are done in
<servlet-mapping> <servlet-name>I18n Servlet</servlet-name> <url-pattern>/de/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>I18n Servlet</servlet-name> <url-pattern>/zh_CN/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>I18n Servlet</servlet-name> <url-pattern>/zh_TW/*</url-pattern> </servlet-mapping>
This functionality would then allow you to point specific domains to a specific language of one site.
Removing Unwanted Language
By default, Liferay Portal supports all of the follow languages (excerpt from the
portal.properties file of Liferay 6.2):
If we only want to support English, German and Spanish, we can simply remove the unwanted locales so that the locales’ value looks like this:
language.properties and Other Language Files
There are many language files and the configurations inside one language file could overwrite the ones from another language file, to better understand the priority of these language files, refer to the following three rules:
- EXT versions take precedence over the non-ext versions
- Language specific versions take precedence over the non-language specific versions
- Location specific versions take precedence over the non-location specific versions
Take North American English (en_US) as an example, here is the ranking:
Language-ext_en_US.properties Language_en_US.properties Language-ext_en.properties Language_en.properties Language-ext.properties Language.properties
Language display information is defined in
…/portal-impl/src/content/Language.properties, as well as various other Language_.properties files for foreign languages. Language.properties is the primary and "default" language definition file, but definitions in that file may be overridden by language specific definitions. For example, the file Language_en.properties contains the English versions of most of the definitions, the file Language_fr.properties contains the French versions, etc.
Language files can also have locale specific definitions. Language_en_US.properties (if it exists), contains English phrase variations further defined for the United States. Other languages can also have locale specific definitions.
Entries in the language files can be re-defined on a deployment by deployment basis by overriding -ext.properties files. Language-ext.properties, for example, overrides/extends the definitions found in …/portal-impl/src/content/Language.properties.
Some important notes are as follows:
- The locale specific definitions take precedence, followed by language specific definitions, followed by the default ones. Since most of the entries in Language.properties have language specific entries in Language_xx.properties, those entries will always take precedence. For example, to override entries in Language_en.properties, you should put your new entries in
…/Language-ext_en.properties. As of Liferay 4.1.2, few locale specific files exist (there is no locale specific variations of the English file, for example). The HIGHEST precedenced file for the United States, for example, is the extension to Language_en_US.properties, which would be
…/Language-ext_en_US.properties. If you find your changes are not appearing, try putting them in that file.
- If there is more than one locale for the same language defined in the locales property, the first one in the list will be used when a translation is requested in another locale of the same language but a translated value cannot be found. For example, if there are two locales such as pt_BR and pt_PT (in this order), any key not found in pt_PT will be looked for in pt_BR.
Changing Existing Language Entries
Example: Changing the text of an existing portlet in Liferay from "Message Boards" to "Forums"
Liferay currently displays "Message Boards" for the portlet because of the following entry in
To change it, create/modify your Language-ext_en.properties file and add the following entry in
Creating New Language Entries
For newly created portlets, it is likely to have new language specific texts.
Example: Changing the title of a new portlet from the default title to "Reports".
Create/modify your Language-ext.properties file for the portlet and add the following entry:
Displaying Multiple Languages in the JSP Files
Since we now understand how all these languages are stored and how to overwrite them, let’s continue to discuss "how to display different languages in the JSP pages".
You will find the following line in the English Language_en.properties file:
use-ldap-password-policy=Use LDAP Password Policy
and the following line in the Spanish Language_es.properties file:
use-ldap-password-policy=Utilizar la política de contraseñas de LDAP
To display this text according to the chosen language, you should add the following line to your JSP files:
If you user has chosen to see the Spanish version of your site, it will display Spanish instead of English.
Using the LanguageUtil Helper
The LanguageUtil class can also be used in JSP files to provide a dynamic translation of certain language keys. This class is useful when there are multiple dynamic parameters that need to be translated, for example:
<%= LanguageUtil.format(pageContext, "back-to-x", pageTitle); %>
The above statement will show the label to return back to a page, with the page title included as an argument. It is also possible to add multiple arguments by passing in an Object array.
Messages that contain HTML syntax need another parameter of type LanguageWrapper, instead of the argument(s) of type Object, for example:
<%= LanguageUtil.format(pageContext, "back-to-x", new LanguageWrapper("", pageTitle, "")); %>
Displaying Multiple Languages in the Java Files
The LanguageUtil class in Liferay can be used to provide a programmatic translation of certain language keys.
Frequently Asked Questions
You may have initially found the entry in "Language.properties" and you may think that you just need to override that value by editing "Language-ext.properties". However, it will not change anything because all of the values in "Language.properties" also exist in "Language_en.properties" and locale specific definitions take precedence. Therefore, "Language_en.properties" will override any changes you have made in "Language-ext.properties". To prevent this complication, one should edit in the "Language-ext_en.properties" file.
You can edit the same files to change Language Settings, Portlet Titles, Category Titles, Action Names, Messages and any other text that is language dependent.
The page's current languageId can be pulled from themeDisplay.getLanguageId(), for example: