NAV 2013 SOAP Web Services on a multilanguage environment

The policy for SOAP Web Services in NAV 2013 states that they always run in EN-US culture.

In NAV 2009 it was reported a buggy scenario that was solved in build 32558 and upcoming ones (remember)

However after collecting some feedback a workaround was built for NAV 2009 (remember 2)

This workaround was temporary as product team did not want to introduce a breaking change in a Hotfix without a way to revert to the original behavior.

Therefore now in NAV 2013 it has been decided to set EN-US as the default fixed culture for SOAP Web Services, the aim behind this decision is that we want to gurantee that Web Services have a fixed culture insensitive interface so any system can achieve a predictable communication with NAV.

I hope you find this Information helpful.

Best regards


Diego García Álvarez

Dynamics NAV Senior Support Engineer


Comments (6)

  1. says:

    With this decision how can we receive from NAV local language error messages (with date, decimal and time local format)?


  2. Hi Matteo,

    I'm sorry but this is not possible for NAV 2013.

    In this version the design is that EN-US will be the default fixed culture for SOAP Web Services interaction.

    To make it clear:

    SOAP WS always run in EN-US culture in NAV 2013

    I hope this clarifies this topic 100%

    Best regards

    Diego García Álvarez

    Dynamics NAV Senior Support Engineer

  3. says:

    I disagree with this choice.

    Parsing every NAV message error from EN-US format to Local language is impossibile.

    Try to show to an italian user, on a web interface, error message "Posting date must be 5/4/2012".

    He will try to put "5 APRIL", not "4 MAY" (if he understands the meaning of english text "Posting date must be", of course).

    We cannot catch and translate every message error, every testfield and every fielderror.

    Can we (we partner) solve spowning from the webservice a backgroud NAS, wait for the processing and then reply with a local message?


  4. Philippe Moison says:

    I agree with Mateo and disagree with this choice.

    The impact, for all not EN-US localized NAV partner's solutions designed with NAV Web Services, is not negligible…

    I wonder how Microsoft can decide to provide an international software that can only run and expose error messages in EN-US culture ?

    As business is more global every day, there is a real need to make applications and services multi-lingual and culturally aware.

    I wonder also how Microsoft can consider this choice as a best practice architecture ?

    There are at least three different globalization patterns that can be applied to a Web Service design (These patterns are mutually exclusive) :

    – Locale Neutral: In this pattern, most aspects of the services are not locale-affected. This is the simplest case, and additional considerations are not required. That's the choice made by Microsoft for NAV 2013 WS, but doesn't match the business needs today.

    – Service Determined: Here, the service always runs in a determined locale, which can be the host’s default locale, or a locale specifically configured for that service. That's the choice made by Microsoft for NAV 2009 WS before the build 32558 intoduced in NAV 2009 R2…

    – Client Influenced: In this case, the service may run in a locale provided by the client application. As the “WS-I18N” states, the service is “influenced” because it can either consider the locale in which it is running or not depending on how the service is being implemented.

    Clearly, I think that for latter-day business needs, the third pattern "WS-I18N" should be the Microsoft's choice for NAV 2013 WS, and hope it will be for next releases in the future !

    Philippe Moison

    3Li Business Solutions (International and french Partner…)

  5. Hendrik Klemp says:

    You can use GLOBALLANGUAGE to get your error message in a specific language. Just set GLOBALLANGUAGE(1031) at the begin of your WS function to get german error messages.  

    But this have no effect for the date or time format.

  6. says:

    The mentioned decision to only support EN-US culture for webservice calls would have been a big issue for us as well.

    Happily, the option to control the SOAP Service culture behaviour has been reintroduced with Build No. 35212 (Aug 20,2013),

    see this link:…/KBDisplay.aspx

    All you have to do is re-add the missing parameter to the CustomSettings.config file of your NST:


     The default Culture in which SOAP Web Service calls are run.

     Supported values

     "false" (the default) ensuring Web Services are running on a fixed culture,

     "true" use the Culture that is logged for the calling user identity in the

     User Personalization Table, if any


    <add key="ServicesCultureDefaultUserPersonalization" value="true"/>

    We have just tested this with a very young Build version of NAV2013R2 and it works fine.

    It's really a pity that important parameters like the above are not part of the default setup package.

    @NAV Team: PLEASE add all possible parameters to the default CustomSettings.config file and leave the decision whether to use the parameter or not to the partner. If there is no senseful default value for certain parameters you can still comment those in the file.

    Many thanks

    Best regards


Skip to main content