Understanding Languages in Liferay Portal

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:

  1. Easily support as many (or as few) languages as desired,
  2. Have a central location for multiple languages,
  3. Change the way a certain word is translated. If you want, you could effectively rename the "Message Boards" portlet to be called "Forums".


Customizations in portal.properties

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 portal.properties file:

 # 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:

Language Unique URL
Chinese Simplified http://www.liferay.com/zh_CN/web/guest/home
German http://www.liferay.com/de/web/guest/home

The mappings for this are done in web.xml:

<servlet-name>I18n Servlet</servlet-name>
<servlet-name>I18n Servlet</servlet-name>
<servlet-name>I18n Servlet</servlet-name>

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:



Customizations in 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:

  1. EXT versions take precedence over the non-ext versions
  2. Language specific versions take precedence over the non-language specific versions
  3. 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 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:

  1. 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.
  2. 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 …/portal-impl/src/content/Language_en.properties:

javax.portlet.title.19=Message Boards

To change it, create/modify your Language-ext_en.properties file and add the following entry in …/Language-ext_en.properties:


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.

Additional Information

The page's current languageId can be pulled from themeDisplay.getLanguageId(), for example:

How to change the language for your “Terms of Use” Page

0 人中有 0 人觉得有帮助