Skip to main content
I
imor1-Visitor
1-Visitor
October 14, 2015
Question

Localiztion tables

  • October 14, 2015
  • 3 replies
  • 7972 views

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

3 replies

C
CarlesColl1-Visitor
1-Visitor
October 14, 2015

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.

I
imor1-VisitorAuthor
1-Visitor
October 18, 2015

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

C
CarlesColl1-Visitor
1-Visitor
October 18, 2015

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.

P
paic1-Visitor
1-Visitor
October 14, 2015

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

P
ptc-911071-Visitor
1-Visitor
October 19, 2015

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.

C
CarlesColl1-Visitor
1-Visitor
October 19, 2015

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.

C
CK_143836877-Bedrock
7-Bedrock
October 20, 2015

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

Terms & ConditionsAccessibility statement