Legacy Knowledge Base
Published Jun. 30, 2025

Using Liferay.Language.get() in React client extensions

Written By

Balázs Létai

How To articles are not official guidelines or officially supported documentation. They are community-contributed content and may not always reflect the latest updates to Liferay DXP. We welcome your feedback to improve How To articles!

While we make every effort to ensure this Knowledge Base is accurate, it may not always reflect the most recent updates or official guidelines.We appreciate your understanding and encourage you to reach out with any feedback or concerns.

Legacy Article

You are viewing an article from our legacy "FastTrack" publication program, made available for informational purposes. Articles in this program were published without a requirement for independent editing or verification and are provided"as is" without guarantee.

Before using any information from this article, independently verify its suitability for your situation and project.

Issue

  • We are building custom element client extension using React. We want to manage all the translations to different languages using the Language override feature in Control panel.

Environment

  • Liferay DXP 7.4 +

Resolution

  • Add the following in the application's package.json in order to use Liferay.Languate.key("") and be able to translate using Liferay language override.
    "eslintConfig": {
    "globals": {
    "Liferay": true
    }
    },

Additional Information

  • When the Javascript code includes a Liferay.Language.get() function call:
    • If the argument is provided as a string literal, then the LanguageFilter will attempt to translate the provided key to the request target language, so the served Javascript will contain the translation.
    • If argument is an expression (so the key is dynamically computed) then the served Javascript will not replace it and function will be run at the browser, returning the key it received.
    • Liferay.Language.get() is not an API that can be used to do dynamic localisation.
    • The Language filter only knows how to replace static keys.
  • We would recommend that each client extension should have its own language keys and the react components managing their own translations.
  • From a performance point of view. Retrieving language keys would be quite expensive.
  • Also client extensions should not depend on the existence of language keys outside of the client extension. Otherwise portability of that client extensions across environments or projects will always depend on someone adding the language keys to Liferay.
  • There is also a new feature in development phase which will allow users to use the benefits of I18N support. https://liferay.atlassian.net/browse/LPS-187877

 

 

 

Did this article resolve your issue ?

Legacy Knowledge Base