The Shared Language Keys sample provides a JSP portlet that displays language keys.
The language keys displayed in the portlet come from two different modules.
What API(s) and/or code components does this sample highlight?
This sample is broken into two modules:
language-web module provides a JSP portlet with unique language keys that it displays. The
language module provides a resource module which only holds language keys. Its sole purpose is to share language keys with the JSP portlet provided in
language-web. This sample conveys Liferay’s recommended approach to sharing language keys through OSGi services.
How does this sample leverage the API(s) and/or code component?
You must deploy both
language modules to simulate this sample’s targeted demonstration.
First, note the language keys provided by each module:
blade_language_web_LanguageWebPortlet.caption=Hello from BLADE Language Web!
blade_language_web_override_LanguageWebPortlet.caption=I have overridden the key from BLADE Language Module!
blade_language_LanguageWebPortlet.caption=Hello from the BLADE Language Module!
blade_language_web_override_LanguageWebPortlet.caption=Hello from the BLADE Language Module but you won't see me!
When you place the sample BLADE Language Web portlet on a Liferay Portal page, you’re presented with three language keys:
The first message is provided by the
language-web module. The second message is from the
language module. The third message is provided by both modules; as you can see, the
language-web’s message is used, overriding the
language module’s identically named language key.
This sample shows what takes precedence when displaying language keys. The order for this example goes
language-webmodule language keys
languagemodule language keys
- Liferay Portal language keys
So how does sharing language keys work?
By default, the
ResourceBundleLoaderAnalyzerPlugin expands modules with
/content/Language.properties files to add provided capabilities:
Then the deployed
LanguageExtender scans modules with those capabilities to automatically register an associated
You can leverage this functionality to use keys from common language modules by republishing an aggregate
ResourceBundleLoader. This can be done two ways:
You can get a reference to the registered service in your components as detailed in the Overriding a Module’s Language Keys tutorial. The main disadvantage of this approach is that it forces you to provide a specific implementation of the
ResourceBundleLoader, making it harder to modularize in the future.
Via Provide Capability
LanguageExtenderthat registers the services supports an extended syntax that lets you register an aggregate of a collection of bundles:
-liferay-aggregate-resource-bundles: \ blade.language
This approach has the advantage of easier extensibility. When language keys change, only the common language modules must be built and redeployed for the modules referencing them to recognize their updates.
For more information on sharing language keys, visit the Internationalization tutorials.
Where Is This Sample?
There are three different versions of this sample, each built with a different build tool: