Localiztion tables

[imor]

Hi

As an extensions developer, I often encounter the meter of localization tables.

While developing an extension, there is a lack of information regarding the localization tables that may or may not appear in Thingworx, in time whem the extension will be imported.

After reading the localization page, in the support manual, I had come to a conclusion that each user can “point” to only one localization table as it’s default table. However, as extension developer I can’t know which tables are even defined in the system.
Also, what happen if two separate extensions define same localization term?

More than that, I would expect that there will be a more generic support to choose the language based on browser configurations, rather than forcing the administrator to go over each of dozens of thousands of user and assign to each one a localization table.

I wonder whether there any  guidance regarding better practices for using localization tables, in the cases I had presented.

Thank you

Ido

[CarlesColl]

Hi Ido,

Some thoughts about it after some months of development with ThingWorx:

• Also, what happen if two separate extensions define same localization term?
  • You should prefix all your Keywords to not this allow, for instance MyExtension.Token1, ...
• More than that, I would expect that there will be a more generic support to choose the language based on browser configurations, rather than forcing the administrator to go over each of dozens of thousands of user and assign to each one a localization table.
  • You can easily build a Mashup that allows the user to select the desired language between Localization Tables. But yes, you will have to maintain a list of available languages, there's no service to query which localization tables are there.
    • As you are an extension developer, will not be hard to add a Widget that gets Browser languages and applies to the user setting if it doesn't has any ( adding a user setting like: as user browser set )
      
• About localization table names, as my experience I would recommend you to use ISO like Localization table names, for instance ( en --> English, es --> Spanish ), why? because there's some insights on the Javascript code that depends on this, and if you use this names, you will get extra feature
  
  • Also this way, you have a naming convention for Localization Tables

Just my two cents,

Best Regards.

[imor]

Hi Carles.

I'm still confused about some of your suggestions.

Let's say that i'm developing a mash-up, to be imported and to serve other mash-ups. one of those mash-ups ("SomeMash-up") is part of an extension ("SoneExtension") who has been developed by "SomeContributor". in addition, "SomeContributor" has placed his Localization tokens inside a LocalizationTable ("SomeLocaliztionTable").  In time when i'll develop my extension, i have no way of knowing about "SomeLocaliztionTable",so all of my tokens will be stored inside "Defualt" LocaliztionTable.

In that scenario, i cannot see a way for both mash-ups to appear correctly without "???"  signs at the same time.

I would expect, that while developing my mash-up, instead of just choosing the localization token for my widgets, i will be given the options to choose from which table those tokens should be taken from.

In addition, i'm still confused about your suggestion for changing the User's language, based on the browser's settings.

Let's say that the User is using 2 different browsers, each of them contains different language settings, if i'll take the approach of changing the "global" user settings, i'll end up staying with one of the mash-ups presenting "???" instead of meaningful text.

i would expect that the User's settings will be changed at the  "Session" level, instead of the "global - application" level.

Your thoughts will be more most appreciated.

thank you

ido

[CarlesColl]

Hi Ido,

First of all, to be said, actually the Localization System it's so bad architected, until ThingWorx guys think it again on it, we will have to do what we can with what we have. What I've said, it's recommendations using what we have actually, and as they neither give Best Practices, we will have to establish our owns

If both extensions works on different LocalizationTables, for sure it will not work, that was the reason to start a "self standard" as ISO like names for Localization Tables. And if you use this "self standard", would not be hard for you to build a script that copies Tokens from one Localization Table ( extension that doesn't complies with "self standard" to another, awful? Yes, but it's what we have right now.

Setting User Languages to Browser preference, should be done only once ( first logon ) not after that, you can put a flag on the UserExtensions ThingShape in order to do it. If you want to do it on User Session, you can too with User Session ( UserManagementSubsystem > Configuration > User session shape settings ), but I would not do on a session basis, usually a User wants to see it an it's own language, not on the browser language. But of course, what I would do too, it's to let the user change the language with a User Settings Mashup.

Hope this clarifies a bit more

Carles.

[imor]

Thank you very much for provided information.

I wonder if you aware about any further plans to improve the localization framework in TWX and/or about any estimations about it.

Thank you,

Ido

[CarlesColl]

I'm not at all , and the current improvements on 6.5 on Localizations Tables doesn't gives any good forward it .

Let's see of some TW guys gives a light to us about this...

[paic]

At least you'll be able to see what localization tables are in Thingworx pretty easily: <Server>/Thingworx/LocalizationTables

[ptc-91107]

Two things you can do for the present (as mentioned in earlier responses):

Namespace your tokens. The reverse-domain convention is a reasonable one to follow. For example, a developer at Acme Inc working on an X-Ray extension might name localization tokens as com.acme.xray.*. This should ensure that token name collisions aren't a problem (currently, in the event of such a collision, the last value imported prevails).

Name your Localization Table entities according to the IETF BCP 47 specification. This could be a simple language (such as es for Spanish, hi for Hindi), a language with a region code (such as fr-CA for French as in Canada, pt-BR for Portuguese as in Brazil), or a language, script, and region (such as zh-Hans-SG for Chinese in simplified script as in Singapore or zh-Hant-HK for Chinese in traditional script as in Hong Kong). Please be sure to use the BCP 47 subtag delimiter, a hyphen, rather than using underscore as is common in some Java implementations.

Localization in ThingWorx is under active development, and the concerns and requirements of extension developers are very much in mind.

[CarlesColl]

As we have you here, about improvements on Localization support*:

• Localize Model Entities Names, from the Model Composer
• Localize Property Names, from the Model Composer
  • Mashups automatically get Localized Property Names ( Labels, Property Display, Grids Column Titles, ... )
• Mashups --> Localize Data ( On Lists, Grids, Tree,.. , the content gets translated from [[token]] to the corresponding translation, the services returns Tokens and gets automatically translated )
• Get List of Available Languages ( not just Localization Tables ... )
  
• Write somewhere on the Localization Tables documentation what you have written here
• Localized Medias --> If you have buttons as images which in turn has text embedded you will need to localize those Media Entities
  

* I've already build almost all this, but it will be awesome to have in on the Standard TW product.

[ckulak]

Hello Carles,

A totally offtopic question, but I'm too curious. I saw what you did to support localization and time zones, among the other impressive extensions, and it looks like there must be quite a lot of code behind. So my question is -- how are you going to make sure all that stuff still works correctly when you upgrade your ThingWorx? Do you write unit tests for your extensions?

/ Constantine

[CarlesColl]

Hi Constantine,

Support Localization --> No tight integration with standard ThingWorx Widgets, neither extensions, just plain Server Side Javascript, should not be any problem with new releases, I just use standard Localization Tokens.

TimeZone Widgets --> Yes it's a pain in the ass, that's the reason I pushed it to R&D in order to be included on the Standard TW product, as it's a feature that should be there already, as an Industrial IoT solution that sells all over the world. But they didn't seemed much interested...

Other amazing things I've done --> Well we will see on new TW releases, and if doesn't happens things that happened before like some features removal without notice between 6.0 and 6.5...

Best Regards,

Carles.

[ckulak]

Well, that's my main concern with the heavy customizations: as far as I understand, nobody gives guarantees that the interfaces won't be changing in future, and at the same time we shouldn't expect any of our code to go into ThingWorx platform. This leaves us with the only option -- test test test, and we don't have a good testing methodology at the moment. All of that makes me quite cautious about writing complex extensions for ThingWorx and it also leaves me wondering how other people address those issues.

[pbollu]

Hi Carles,

I see that you are able to get the Available localization tables in Thingworx?

How are you doing that as we don't have any function to do so? Can you pass the code snippet you are using to get them?

Thanks for the help!

[CarlesColl]

Here it's a easy way:

var result = Resources["SearchFunctions"].SearchModelEntities({
        maxItems: undefined,
        searchExpression: undefined,
        types:{ items: ['LocalizationTable']} /* JSON */,
        aspects: undefined /* JSON */,
        excludedAspects: undefined /* JSON */,
        maxSearchItems: undefined /* NUMBER */,
        tags: undefined /* TAGS */
    });

[pbollu]

Thanks a lot Carles. Appreciate your help!

It works, only thing is the BaseType of the service should be selected as "INFOTABLE".

[ngourav]

Hi Carles,

Can you please help me out how to change a button language from english to spanish? I am getting all the languages from this code

var result = Resources["RuntimeLocalizationFunctions"].GetLanguages();

So i want the moment we select the language the button label should change from english to spanish.

thanks

Naveen

[CarlesColl]

Hi Naveen,

Maybe better you start a new thread... Just a small thing, why use a Button and not a DropDown?

Carles.

[ngourav]

Ok Charles