The author of this article is Courtney Dascenzo, Principal Technical Evangelist with ISV Partner Enablement Team
Background and Assumptions
- The REST API could have been leveraged but was not due to API call utilization.
- These options were built and tested in a Partner Developer Edition Org
- Some options require features to be enabled that you may not want to introduce into a managed package such as multi-currency.
- Packaging was not tested and the options were not security review tested.
- A POC requirement was to match the look and feel of Salesforce so we leveraged the Salesforce stylesheets as static resources in the project. *** Never access Salesforce stylesheets dynamically as they can change from release to release.
Locales are typically loaded based on a default setting in your browser. In angularJS, this can be overridden by including the locale file after the angularJS script file in your index.html file is included. During bootstrap, this will force angular to load the specified locale file. The below example will force the locale to be Danish for all users.
This is great when working within one locale but typically, that is not the case. Most likely there is a need for locales to switch dynamically, based on a parameter or variable. We chose to leverage the local setting from the user’s profile setting in Salesforce. To do this, we created a remote action within an Apex custom controller to get some of the user’s information including locale, time zone, and currency. We can use these settings to dynamically change how the information in our app is presented to the end user. Below is an example of the remote action and it’s helper class.
In angularJS, we can call this Remote Action and store the results in a factory or in $rootScope (since this was a POC, we choose $rootScope). Here is an example of how to call the action and how to store the results:
1. We chose to store the call to the Apex controller’s action in a variable for reuse in the visualforce page:
2. We created an angular service to call the Remote Action in Salesforce and return the results.
3. Now we call the angular service from the angular controller and store the results to $rootScope variables. We also set the locale of the app using an angular Module called DynamicLocale that we downloaded from Github.
4. DynamicLocale will automatically grab and load the correct Locale file based on the passed in variable:
There are other angular modules available on Github to perform the locale file swap. You can also write your own. If you decide to leverage the locale files published by the angular project, make sure they are complete. You may also want to download them and include them as static resources instead of resolving the URL dynamically.
This concludes part one on Internationalization Options in angularJS and Salesforce. Be sure to check out the next post in this series on Time Zone conversions.
Code samples for the whole series can be found in Github at: https://github.com/cdascenzo/salesforce_angular_internationalization.
Don’t want to mess with the code, spin up a trial and see the demo in action (some images do not resolve on the Heroku site, don’t worry, the sign up still works): https://pacific-inlet-1581.herokuapp.com/.