• 13/8/2014

    Localizing JavaScript of a Full Trust solution


    We, SharePoint developers of ancient times when "full trust" solutions ruled, have understood one thing: using JavaScript improves by far our solutions.

    Indeed this allows to reduce the load of the servers and makes the user experience more "responsive".

    But what if you want to display messages in different languages depending on the user? In .NET (understand server-side) it is quite simple, just use of resources. (see one of my posts on the subject)

    Standard solutions for ASP.NET

    The framework already allows a localization of the JavaScripts files, however these methodologies is not necessarily very practical given SharePoint deployment cycle.

    An alternative methodology best suited to SharePoint is to duplicate the JavaScript files and deploy them into subfolders by LCID (1033, 1036...). This forces us to duplicate code, at best to have file for resources. (in addition to the resx). (this is how SharePoint works internally)

    ScriptLink.RegisterScriptAfterUI(this.Page, "JSample/Scripts/myscript.min.js", true, true);

    It is the second parameter set to true, which allows to do this when calling the script.

    Solution proposed by Microsoft

    Continuing my researches I found this post from the SharePoint product team

    They explain that SharePoint contains a handler which is used to expose the resources located in the hive in JSON (awesome!).

    However I'm not fond of the manner in which they load these resources because:

    - The way it is presented would suggest you have to do inline script (this is bad)

    - The call they make might crash if it is in a site collection of a web app that has no root site collection

    - Once loaded, resources are not contained in a namespace which may lead to conflicts with other components

    - We do not control the loading sequence with this kind of call, another risk of having conflicts

    - Loading is done simultaneously with the page and not asynchronously which provides a poor user experience

    My solution

    Here is the solution I propose, we will make an asynchronous load of script through jquery and SharePoint’s JSOM and load resources in a dedicated namespace. This will allow us to go beyond all the above limitations. The only negative point, it will be necessary to add jquery if it is not already present. This is not a real problem since for several years already SharePoint developers use JQuery within their projects.

    You can find the code at this address example


    Since there always must be a first time, I would like to announce that I created an account on github and that I'll post my code examples over there from now. It is a very interesting platform.

    The big positive point? If there ever are things to improve in my examples, you can participate (or other developers worldwide).