Hi all, Is anyone using the N/translation module? I have a suitelet that utilises the following. require(["N/translation"], function(translation) { console.log("Locale:", translation.Locale.CURRENT); }) From this I just read the user preference language and set the correct translation. The problem is that when I change the language the above shows erratic behavior sometimes is changing and sometime not.For both the CL and server scripts

We are working on a big translation project now, and we are making use of that module. If you want to share your code, I can take a look. It was tricky to get it working, and the examples in SuiteAnswers weren’t always helpful.

I made a simple SL to demonstrate the problem with Netsuite as well

/**
 * @NApiVersion 2.1
 * @NScriptType Suitelet
 */
define(['N/ui/serverWidget', "N/translation", "N/config"], function(serverWidget, translation, config) {
    function onRequest(context) {
        if (context.request.method === 'GET') {
            var form = serverWidget.createForm({
                title: 'Simple Form'
            });
            var configRecObj = config.load({
                type: config.Type.USER_PREFERENCES
            });
            let configLang = configRecObj.getValue({
                fieldId: 'LANGUAGE'
            });

            var field = form.addField({
                id: 'custpage_text',
                type: serverWidget.FieldType.TEXT,
                label: 'Server locale current'
            });
            field.updateDisplayType({
                displayType: serverWidget.FieldDisplayType.DISABLED
            });
            field.defaultValue = translation.Locale.CURRENT;
            log.debug("server", translation.Locale.CURRENT);

            var field1 = form.addField({
                id: 'custpage_text1',
                type: serverWidget.FieldType.TEXT,
                label: 'config'
            });
            field1.updateDisplayType({
                displayType: serverWidget.FieldDisplayType.DISABLED
            });
            field1.defaultValue = configLang;
            log.debug("config server", configLang);

            form.addButton({
                id : 'buttonid',
                label : 'Client locale',
                functionName: stringifyFunction(getLocale)
            });

            context.response.writePage(form);
        } else {
           log.debug("not implemented");
        }
    }

    function getLocale() {
        require(["N/translation"], function(translation) { console.log("Locale:", translation.Locale.CURRENT); alert("Client Locale: " + translation.Locale.CURRENT)})
    }
    function stringifyFunction(func) {
        var functionString = func+'';
        var stringFunction =  functionString.substring(functionString.indexOf('{')+1,functionString.lastIndexOf('}'));
        return stringFunction.trim();
    }

    return {
        onRequest: onRequest
    };
});

One thing is to make sure you are using fonts that support all of the characters/symbols of the target language. NetSuite use Noto Sans in their PDF templates, which is a good one that covers a lot of languages. Your Ubuntu machines may not have the same fonts installed. You can try using web fonts instead, as they will work more consistently across different browsers and computers.

Nice hint, thanks. What we are building atm is a React front SL that will make data entry lighter. We thought it would be a manageable addition to use this module to support multiple translations . Do you think that the font bugs the usage of this api even in server scripts?

One thing, are you actually using a translation collection? The main reason for this module is to work with translation collections. Standard records in NetSuite often translate automatically based upon language/locale settings, but custom fields, records, and text do not.

Yes that's the idea we build a translation collection with 4 languages English, Dutch, German , French for testing and if this works we will give it to our consultants or hire an agency to get more languages. Problem is that this breaks from the start if we cant use this enumeration and we are afraid to release in case the rest are not working as well. But I guess if people are using the whole module we can get the language from the config module and post it to the client script for usage. Thanks for all the tips though

in your example code, I don’t see any calls to load the translation collection, or to get specific key-values from it. Are you just trying to get/display the user’s locale setting right now?

Yes because that was the issue. The actual code is spread between multiple React components. This just represents the problem it self that we are getting

Okay, I understand a little bit better now. The problem is primarily not getting the right value from the user’s Language preference, then, yes?

Exactly

The code seems right. Are you possibly seeing caching issues? Sometimes the browser will cache certain pages and/or web service calls to speed things up, but it could also be displaying stale values. Maybe try with a different browser, or try clearing your cache, and logging out and back in after the language change. I see caching problems much more with Chrome, as Chrome caches web service calls by default, and Suitelets are just like any other web service call to Chrome

Cache is hard reset between tests all the time. Tested with Chrome and Firefox and yes we are getting those cache issues quite often you are right.

Okay. It’s always troubling when you can’t reproduce the issue exactly or consistently. When you do get the wrong value back, is it wrong in both the user setting and in the translation locale setting, or only wrong in one of those values?

config module always return correct, translation module is the problematic one 😞

if only the translation local setting is wrong, then the good news is, you can work around that quite effectively by setting the locale explicitly in your code, instead of using the default value.

Yes, the workaround is to use this one, what I was afraid is that this module might have bugs down the road when loading the collections and getting the correct words. Considering the alternative to use our own custom record mapping for that atm...

I haven’t seen bugs with the module when the locale is set explicitly. You can try some code like this, to make sure your user Locale is the one being used

Ok thanks for the info will give it a try for sure

I wouldn’t worry too much about what locale the translation module thinks is the default. That is set by NetSuite when the script loads the N/translation module, and I don’t think there is a way to control it, but you also don’t have to use that locale at all. It’s better to be explicit, then you won’t have any issues. This is essentially what we found to be the most reliable after trying lots of different options.

Makes sense