web-platform.js deprecated - how to get a string?

[CathyBr]

I'm starting to remove the functions that use WEB_PLATFORM and replace them with the htmlsdk api ones.  One thing I have not found documented, is how to get a localized string.  Until now we have been using WEB_Platform.getString(myKey) - it returned the correct string with the correct language.  Can you please tell me how to do this without WEB_Platform?

I tried to find something in the html sample, but am having difficulty in general with the sample, for I am not familiar with angular - Maybe it would be possible sometime to include a simple sample in just html and javascript which shows the api functionality..

[_vladi_]

Hi Cathy,

You have probably seen that there is no localization method in the new APIs. The reason for this is that the plugin owns the property files and the Javascript code anyway so any localization library would do the work (essentially it is just reading of your own property files). We have showcased the ngx-translate library in the HTML Sample which is one good way of doing this for the recommended Clarity-Angular-Typescript tech stack.

Nevertheless, there are many JS localization libraries - if you are not using Angular just pick one that fits your tech stack (be it node-localize, globalizejs or any other) or read the property file yourself.

Note that with this approach there are no requirements to the property files in terms of their naming and type (.properties, .json, etc.).

Cheers,

Vladi

[CathyBr]

Hi _vladi_

- ok...    just one more thing that  has to be done.

I would like to say that it seems to me that more and more time and effort is expected from the plug-in developers for just "sustaining" issues.

1) Rewrite the entire GUI code from Flex to html (last year)

2) Make the code work in the flex and the html clients - and that the look and feel matches both... (this year)

3) Now we should change to angular - or provide functionality for depecated files ourselves.... (now)

4) Completely rethink - rewrite our support for Custom Objects... (now)

The problem is that customers expect us to have new functionality in our plug-ins, and not spend the time just keeping old functionality work...

I hope that this situation will not continue forever....

Cathy

[_vladi_]

Hi Cathy,

You don't need to address those "sustaining issues" for your current plugins - those are supported and working.

The stated changes are needed for future compatibility with a new major release (I guess at least a year from now). That's normal lifecycle of an API.

The legacy Flex Client architecture requires changes going into the HTML Client world and this is why we are providing the heads up. It's up to you when you want to adapt to those.

The required frequent changes in the past are exactly why we are taking plugins into the direction of fewer dependencies to the HTML Client, higher integrity, flexibility to choose tech stack and depending on Web development stardards - so that you don't have to rewrite stuff in the future. All those are and will be done preserving backward compatibility of the old stuff long enough to allow smooth transition.

On topic: you don't have to switch to Angular, any library would solve this task. We will look into providing more examples on that.

Thanks for the feedback.

Cheers,

Vladi

The legacy Flex architecture requires changes into the HTML Client world and this is why we are providing the heads up.

[CathyBr]

Hi Vladi,

just one more comment on this issue - (getString) -

the html client  reads our plugin.xml file.  It then is able to read our .properties file to extract the localized strings which are refrenced in the plugin.xml.

Since this functionality is obviously present, would it not be possible to link this to the api  and make an interface to it?  It seems like that would not be such a terrible thing. The api knows the locale as well.

Yes, we can write the functionality ourselves, or we can get some open source code  but both ways involve more effort.

1) writing it ourselves - takes time

2) open source code could involve licence issues - we have to be very careful here.

It just doesn't seem right to depreciate functionality, and tell the plug-in developers to handle it themselves.  We would not dare do this to our customers...