URL of SharePoint-hosted app delivers wrong language information? RRS feed

  • Question

  • Hi,

    in a SharePoint hosted app (written in pure JavaScript/JSOM) I have to retrieve the language setting from the user's web browser. It's impossible to read that value in javaScript so far.

    But is there any way to let SharePoint add this value - which comes from "HTTP-Accept-Language" header - to the query string of the App url?



    where {StandardTokens} and {AcceptLanguage} come automatically from SharePoint?

    P.S.: the parameter "SPLanguage" from the URL is of no use, because it comes from SharePoint's regional settings which only determines the display of numbers and date formats, and not the text content.

    • Edited by MicNanara Friday, April 19, 2013 10:09 AM Title changed
    Wednesday, April 17, 2013 3:09 PM

All replies

  • It's a weird scenario where u prefer the browser language over the user preference language.

    Did u try the following code to get the user language?

    if (navigator.userLanguage) {
    			baseLang = navigator.userLanguage.substring(0,2).toLowerCase();
    		} else {
    			baseLang = navigator.language.substring(0,2).toLowerCase();

    To update a querystring variable u should check out this post:

    Junior SharePoint Consultant ||

    • Edited by LudwigVG Wednesday, April 17, 2013 3:34 PM
    Wednesday, April 17, 2013 3:28 PM
  • Thank you for your answer.

    The reason why this is a troublemaker is well shown in this article:

    As you see all accesses from within JavaScript are completely of no use when you are using Internet Explorer.

    Also the app URL parameter "SPLanguage" cannot be used.

    The only way to really get the language which the user wants (and that is the users language setting in the web browser) is to retrieve the "HTTP-Accept-Languages" header. But only server code (Sharepoint) has access on that value.

    When SharePoint 2013 is installed with multiple languages, the user can only switch to different language with his browser setting. I am not talking about the "Regional Settings", they are only for display numbers and dates, not for text!

    If you want to change text, you must set language in the web browser.

    So I am totally confused that a SharePoint-hosted app infrastructure does not take any care about the fact, that the JavaScript in Internet Explorer is unable to get the language setting from the browser.

    • Edited by MicNanara Wednesday, April 17, 2013 4:32 PM
    Wednesday, April 17, 2013 4:30 PM
  • Oke so browserlanguage is unreliable. Why can't SPLanguage be used? I used this for my App. This variable depends on the language setting of the user on his profile(see ). Which is the correct approach in my opinion.

    For example:

    If i have a english webbrowser. But on my user profile I say : "I want SharePoint in French". Everything will be translated to french, like the ribbon, navigation, etc...

    If your app is then looking to the browser setting - it will have a different setting then all the rest - which is not the required behavior...

    I think the user preference language is the way to go. Let me know if you have a reason to use the browser language...

    Junior SharePoint Consultant ||

    Wednesday, April 17, 2013 9:16 PM
  • Hello.

    The SPLanguage from URL query string is changed by the regional settings of the site collection and not by the user profile setting.

    The language in the user profile setting does change the text in the site collection. But the SPLanguage parameter in app URLs is not affected.

    So there is still the problem, a SharePoint-hosted app in unable to get the real language setting which is valid in the hosted ShsrePoint environment. That means while the site collection still displays English language for example, the SPLanguage parameter can be anything else than English.

    And that can be very confusing for customers who buy an app, because the app is retrieving the wrong language information from the SharePoint host. Just because the only available language information (in SPLanguage from app URL) delivers the "Regional setting" from SharePoint and not what the user sees in the site collection.

    To summarize it:

    What you see in the site collection is depended primarily from the settings in the user profile. If nothing has been setup there, then secondarily the browser language setting determines what you see.

    But: both values are not forwarded to a SharePoint hosted app through the SPLanguage URL parameter. That SPLanguage parameter only forwards the site collection regional setting, which is the wrong language information from my viewpoint.

    Example: while the regional settings say "English" and my user profile says "French", my app will get the "English" language code.

    I don't see a solution for it as long as the app URL delivers the wrong language information.

    You are right though, reading the browser language could be different like you described.

    • Edited by MicNanara Friday, April 19, 2013 10:11 AM
    Friday, April 19, 2013 10:06 AM
  • I agree to disagree. I have this issue also. My SPLanguage parameter is in Dutch, but my App is translated into English...(which is the default site collection language)

    I think this is a real issue over here... 

    I also created a post for this over here:

    Junior SharePoint Consultant ||

    Friday, April 19, 2013 2:04 PM
  • MicNanara, I absolutely agree with you and jump on the band wagon. I also need to get the language the host web currently is displayed in to adapt my provider-hosted app.

    My expectation was that you somehow can read the current display language via client object model, but did not find a solution so far (related question on SharePoint StackExchange).

    At one point I thought I found a solution. Looking at the POST-Request SharePoint uses to get the main page of my app I saw an interesting parameter in the POST data (Encoding: application/x-www-form-urlencoded): SPSiteCulture. This always seems to contain the correct language of the host web (e.g. en-US).

    But unfortunately these parameter is gone when I try to access it from code. My app is hosted in IIS and when I look at the POST data it is empty. If it wasn't we would maybe have a solution.

    Wednesday, April 24, 2013 4:28 PM
  • And another one with the same problem :-(

    Hey Microsoft, it is 2016! I know that americans are seldom aware that there are other languages, but could someone in Redmond please fix this anyway?

    Tuesday, September 13, 2016 12:42 PM