Affects Version/s: None
Fix Version/s: None
Component/s: DXP Components Web > Translation Manager
Goal of this task is to provide JSP access to the translation admin logic via <input-localized> integration.
A common usage for both variants is in object edit pages where the object title or name will have a Translation Selector instance st to work in admin mode attached to it. Other translatable items in the page will just allow translation selection.
After evaluating some options, we concluded that the best approach to foster adoption for the translation selector in JSP-based DXP applications is to make it accessible via the most common place where it's used: the <liferay-ui:localized-input> tag.
Let’s compare current <liferay-ui:localized-input> behavior with the new expected behavior when tag is configured to work with translation admin:
||Expected behavior when integrated with translation admin
|Current lang selection||Syncs all instances of localized-input fields in terms of what’s the current language||Syncs all instances of localized-input fields in terms of what’s the current language, unless the selected language is removed via modal, where the default one will be used|
|Language selector contents||All instances display the same list of (available) languages||All instances display the same list of (active) languages|
|Delete a translation||Not possible||With the modal. Upon modal close, the new list of active languages will be used by all selectors in the page. Also, deleted languages will empty the translated values and an event will be triggered so that apps can do app-level translation cleanup|
Tag must be aware of the mode it should operate, more specifically, whether it has to integrate the translation admin (admin mode) or just act as a translation selector (sync-slave mode). This requires an extra optional adminMode argument for the <liferay-ui:localized-input> and calling tags (<aui:input> and <liferay-ui:input-field> ) which will tell if admin mode has to be enabled or not. This flag should be used in just one instance in the page.
The value this integration provides is to avoid showing all available locales in the selector. It’s up to the apps to provide that list via optional activeLocales tag argument to the <aui:input>. According to the designs, a reasonable solution, not enforced by the <liferay-ui:localized-input> implementation, is:
- Compute the set of languages for which some translation exist in the set of localized inputs and other app components supporting localizable input
- Use that list for all occurrences of localizable <aui:input> in the page, not just the one with adminMode=true. A display context object can help to do the job.
Otherwise, the list of available locales will include all site available locales, which partially defeats the purpose of the modal.
Explanation of tech tradeoffs behind this decision can be found here
So, in this integration, <liferay-ui:localized-input> can be configured to work in Translation Admin Mode via:
- The activeLocales optional tag argument
- The adminMode optional tag argument (only for one instance of the localized input)
Current translator selector in <liferay-ui:localized-input> will be able to work in integrated mode, where component will:
- Display a list of active languages for selection, as provided by the application. If this list is not provided, component will show the available languages instead.
- If adminMode=true, render a button to access translation admin component. When clicked, translation admin modal will be rendered, receiving both active and available languages.
Please note that <liferay-ui:localized-input> tags is already rendering the languages, so it’s not a requirement to integrate them with the translation selection react implementation, as this level of reusing, though ideal, is much more involved technically. Nevertheless, some minor adjustments may be needed in case we rely on the markup rendered by <liferay-ui:localized-input>.
The translation admin will be rendered from the <liferay-ui:localized-input> when adminMode=true. In this case, the <liferay-ui:localized-input> will control the modal and interact with it via global state as follows:
- The list of active locales may receive changes in that modal. Modal will reflect them in the global state. This is general, expected behavior for the translation admin
- Apps can use that information if needed
- LocalizedInput.js will also listen to that global state
- Upon modal close, the new active languages list will be used by all localized-input instances, as follows:
- For each added language:
- A new event inputLocalized:localeAdded will be triggered. Apps can listen to it to do app-level language initialization if needed.
- For each deleted language:
- A new event inputLocalized:localeRemoved will be triggered. Apps can listen to it to do app-level language cleanup if needed.
- The localized-input will empty any value for that language present in any instance on the page. This effectively “removes” the translation as the App will get blank values when retrieving data from the localized-input.
- The localized-input selector will self-readjust to include the new list of active languages
- If the currently selected language has been deleted, then selector will auto-select the default language
- For each added language:
The new events are triggered so that there is no need for JSP-based apps to use the global state api to be notified.