Esko Logo Back to Esko Support
Choose your language for a machine translation:


Description

Custom language strings are defined in an xml in the custom/languages folder. Details on how to define them can be found in the WebCenter documentation: Customize the Language Files.

Sometimes however they don't show up in WebCenter in the places you expect. This could be because of a couple of reasons.
This KB article tries to help you find and solve the issue.

Procedure

Possibility 1: Wrong file encoding

One of the potential causes of language strings not appearing in WebCenter is wrong encoding. The files in the custom/languages folder should be UTF-8 encoded. However, sometimes they are accidentally saved in a different encoding when editing them.

How to check?

  1. Open the language files in the /custom/languages folder with an editor like Notepad++.
  2. Open the Encoding menu.
  3. Check the encoding that the editor indicates:

How to solve?

If it is not set to UTF-8, make sure to select Convert to UTF-8 to change the encoding and then save the file.

Possibility 2: Didn't customize all copies of the string in the wc_strings file

Another possibility is that you didn't customize all the copies of the string in the wc_strings file and one of the copies is used on the place where you actually want to see the new value.

Forgetting to customize a copy might also be more tricky to spot than you expect.
While in the original wc_strings file most language strings are indeed defined by a key and value:

Some however are defined by a key and ref:

These however are also copies!!

Using a ref means: "use the same value as you can find in this other location in the current file". Whether you use a "ref" or actually copy (redefine) the value in both places doesn't make a difference. However, both copies should be in the custom wc_strings file! "Ref" copies can be harder to spot when customizing strings.

Example: In the screenshot below, the "QAToolPopup" application defines the "OK" string to have the same value as the "OK" string in the "JSP_Strings" application in the same file. If you want customize the "OK" under "JSP_Strings" you probably also want to copy the "OK" definition under "QAToolPopup" to make sure that one is customized as well. If you don't copy it, the OK button in the QA tool will still show the original language string.

Note that you could also only customize the "OK" string under "QAToolPopup" by no longer using a ref, but instead directly defining the value in your custom language file.

Possibility 3: Missing declaration of newly added language

If you add a language that wasn't originally supported by WebCenter, you need to make sure you register this language.

How to solve?

You can do this by adding it in the customizationConfig.xml file as described here.

Note that the customizationConfig.xml file should also be in UTF-8. For details on how to check this, see "Possibility 1" above.

Special cases for email notifications

For email notifications, the customized language string files need not be placed in the custom/languages folder, but in the languages folder where the email customization itself is defined. For details, see:

If you want to use a new language for emails (see "possibility 3" above), these new languages need to be defined in the "AppConfig.xml" file on the application server instead.

Article information
Applies to

WebCenter

Created

 

Last revised

 

AuthorJEPE
Contents