The Translation Process

This topic applies to the Kilimanjaro release of SCA and earlier. If you are localizing text using an extension, see Localize Text in an Extension.

When a specific language is set for a website, string literals wrapped in any _.translate() function are replaced with language-specific strings, which appear on the site. The following diagram depicts this process.

The application’s SuiteScript Server Page (SSP) requests information from the backend to confirm that the requested language is properly set up in NetSuite.
All _.translate() functions are embedded within various JavaScript files and contain string literals to be translated. These functions match their string literals with name-value pairs defined in the SC.Translations array within JSON language files.

JSON language files are located in the Languages subfolder for each application module. For example, Modules > suitecommerce > ShoppingApplication@x.x.x > Languages.

Note:
In the final Distribution folder, these files are located in the languages subfolder at the root level.
The name-value pairs within the SC.Translations array contain translated values for the active language. The SC.Translations array passes these values back to the _.translate() function.
The translated content appears on the site.

Important:

If a literal wrapped in a _.translate() function does not have a corresponding name-value pair in the SC.Translations array for the active language, that literal is not replaced.

Note:

In addition to the localization elements handled by the client, many elements are handled from the NetSuite backend that cannot be customized or extended. For example, NetSuite error messages, numbers for prices, dates, etc. are localized by the NetSuite backend code.

Related Topics