Smart UI Internationalization

Hi,

I have a feeling I'll end up eventually answering this myself, but here it goes....

My widget and commands work in English but they don't load in other languages. What I noticed was that it seems that the grunt script will compile into <module>-all.js the root/lang.js file, but not any of the others, even if other languages are defined in your nls/lang.js.

For example, I have

define({

"root":true,

"en-us",false,

"en", false,

"de", true,

"fr":true

});

Is there something I need to change in order that the contents of de/lang.js and fr/lang.js *also* get copied into the <module>-all.js bundle?

Thanks in advance

-Hugh

Find more posts tagged with

Comments

Reiner Merz

this config (Languages de, de-DE, en, es, fr, it and fallback root) works for me. In our Multilingual Metadata Extension:

Image: https://us.v-cdn.net/6030023/uploads/editor/cm/qmk1prf6sqaz.png

Gives

Image: https://us.v-cdn.net/6030023/uploads/editor/8q/7jepaxecy59d.png

Ferdinand Prantl

Your configuration aims for including `de` and `fr` languages with (the default) `en` in your product installer.It will work in 21.1, at first. Earlier versions could not bundle additional languages.

You can use the following workarounds in 20.4 and earlier versions:

1. Deploy your localisations as separate language packs. If you established a process to release language packs for CS modules in your company, you can continue using it for Smart UI extensions too.

2. Include the language modules in your code bundle explicitly. If you do not release language packs separately because of the additional effort, this is an easy workaround. For example, let us have an extension exposing a tree control with some localisable strings:

src/controls/tree/tree.view.js:

define([
  ...
  'i18n!myext/controls/tree/impl/nls/lang'
], function (...) {...})

src/bundles/myext-all.js:

define([
  'myext/controls/tree/tree.view'
], {})

You will find only modules `myext/controls/tree/impl/nls/lang` and `myext/controls/tree/impl/nls/root/lang` included in `out-release/bundles/myext-all.js`, although you set `de` and `fr` flags in `myext/controls/tree/impl/nls/lang`. You can enforce bundling of additional languages by including their language modules in the bundle index explicitly:

src/bundles/myext-all.js:

define([
  'myext/controls/tree/tree.view',
  'myext/controls/tree/impl/nls/de/lang',
  'myext/controls/tree/impl/nls/fr/lang'
], {})

Details

Localisable texts are authored by a pair of modules, a master module and a language module. The master module describes languages bundled with the product - included in the code bundles in the build output. It has usually the same content, which declares "root" (alias for the default language, which is "en-us") as included and disables loading or "en" and "en-us" languages, because they are the same as "root". For example:

src/controls/tree/impl/nls/lang.js:

define({
   'root': true,
   'en-us': false,
   'en': false
})

Additional languages are usually delivered by a separate deployment unit - a language pack, which is delivered independently on the product (code). That is why there is usually nothing about additional languages in the master module.

If you fins the maintenance of separate language packs too much effort, you can bundle all languages, which you support with the product (code). You set their locale flags to tru in the master module:

src/controls/tree/impl/nls/lang.js:

define({
   'root': true,
   'en-us': false,
   'en': false,
   'de': true,
   'fr': true
})

... and create language files in the corresponding locale directories:

src/controls/tree/impl/nls/root/lang.js
src/controls/tree/impl/nls/de/lang.js
src/controls/tree/impl/nls/fr/lang.js

David Henshaw

Hi Ferdinand,

We're presently using the approach of deploying localizations as separate language packs.

The "root " language of course is en or en-US.

As the root language is compile into the final bundle, is there a means available for customers to override our default labels - similar to how customers could modify the XLATE files for OSCript/Weblingo?

Regards,

David

Ferdinand Prantl

The answer is "yes and no". There is an API for that, but there were no administration pages added for the customer to edit the replacement texts, If you deploy an OScript module to the server, you will be able to use it.

The feature was meant for overriding connected to branding - server name, page titles and other prominent strings. Since we have introduced it, it has been used more internally for adapting Smart UI to other ECM products developed by OpenText. Allowing the CS customers to edit those text has never got enough attention.

The concept is the following: create a public lang module (outside the /impl/ directory) and move the overridable strings there. If the module is not private, it will not be renamed or moved in a future release. Only those strings should be put to the public module, which we are ready to support as public interface. If you look at the SDK sources, some lang.js files are outside the /impl/ directories, like /lib/src/csui/pages/start/nls/root/lang.js:

define({
 // Used as a parameter in other patterns below
 ProductName: "Content Suite Platform CE 21.1",

 // Example: "John Smith - OpenText Content Server"
 // Pattern: "{0} - {1}"
 // {0} is the user name
 // {1} is the name of the product
 UserTitle: "{1}",

 // Example: "Folder CarbonFibre - OpenText Content Server"
 // Pattern: "{1} {0} - {2}",
 // {0} is the name of the node
 // {1} is the type of the node
 // {2} is the name of the product
 NodeTitle: "{1} {0} - {2}",

When you create an OScript module, you can orphan CSUI::Extension and override the GetDynamicConfiguration method to return this assoc:

{
 i18n: {                // the configuration for the localisation module
  overrides: {             // the configuration with all overrides
   'csui/pages/start/nls/root/lang': { // the name of the language module with strings to override
    ProductName: 'Bedrock',     // the string identifier to override
    UserTitle: '{0}\'s Cave'
   },
   'csui/controls/tabletoolbar/nls/root/localized.strings': {
    ToolbarItemReserve: 'Lock',
    ToolbarItemUnreserve: 'Unlock',
    MenuItemReserve: 'Lock',
    MenuItemUnreserve: 'Unlock'
   }
  }
 }
}

It could even be a Smart UI - JavaScript-less OScript module.

As you see, it is not for every customer. if your task is to rebrand the CS for a big customer, they will probably need some other customisations and they will end up with paying for a small OScript module anyway. But requesting a custom development for rewriting some string might be considered too excessive for other customers.

You could file a feature request about this. I believe that there should be a way to change those strings by an experienced admin. Just like it is possible for the logo and background colour.

David Henshaw

Thanks Ferda.

I was asking question in the context of our solutions - where we have an existing module. I've had one request to override one Smart UI label in our solution. Our Smart UI components for the solution use root language of English, so are compiled into the resulting bundles.

If I read your notes correctly, we could apply your approach to our product, but would need a means for customers to manage the values for the localized strings that would be returned by GetDynamicConfiguration - at least for the root language (as the other languages we supply as a language pack, meaning they can be manually altered anyway).

For one specific label - judgement required on whether benefits are proportionate to efforts!