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.
Some thoughts about it after some months of development with ThingWorx:
Just my two cents,
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.
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
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.
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...
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.
As we have you here, about improvements on Localization support*:
* I've already build almost all this, but it will be awesome to have in on the Standard TW product.
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?