Bing maps API 8 - consistent localization RRS feed

  • Question

  • Hello.

    I'm trying to control the language of Map API v.8 directly (not depending on browser's language).

    How can we achieve full localization of API v8 web control? (the feature worked perfectly in 6.3 API and we're in process of migrating to 8 API).

    By loading the map control with 'mkt' parameter 

    <script type='text/javascript' src=''></script>

    I get only particular localization - the map data (e.g. city names) are indeed in Dutch now, however the control bar (where we can select road/hybrid view) - is still browser-dependent, e.g. it's shown in Russian language.

    Tuesday, October 18, 2016 12:15 PM


All replies

  • The mkt parameter is currently not supported in Bing Maps V8. The map automatically changes to the language that the users browsers is set to. This ensures they are able to use the map. There are plans to provide an option to override the automatically detected settings, but this is not yet available.

    [Blog] [twitter] [LinkedIn]

    Tuesday, October 18, 2016 5:16 PM
  • Thanks!

    we'll wait for an official way of localizing the map in API v8 independent of browser. It's rather a typical use case - users specify their language in web-application settings and prefer to see the site fully localized according to this setting.

    (Imagine a traveller who borrows his friend's laptop which browser is in an unknown language).

    Browser's locale is a good 'default' to start from but it should be possible to override it.

    Tuesday, October 25, 2016 6:59 PM
  • Actually, the need to use a culture other than the one that is detected is fairly low based on extensive user testing of over 1 billion user sessions. That said, we do plan on documenting how to override the defaults soon as this is something that a lot of devs like to do when testing.

    [Blog] [twitter] [LinkedIn]

    Tuesday, October 25, 2016 8:43 PM
  • Is there any news on this? Imho it really should be possible to overwrite the automatically detected culture.

    We are currently facing a couple of problems with the SearchManager module, because we receive different results for the same geocode request, depending on the detected culture. Our application is used by german users and works as expected as long as the culture is detected as "de-DE". The problem is, that the application is also used by users in a big corporate network who connect to the internet through a proxy located in another country. On these machines the culture is detected as "en-WW".

    Here is an example:

    query=Maistr., 80337, Germany - doesn't give the expected result with culture=en-WW, it looks like the street name is not found.

    Whereas query=Maistraße, 80337, Germany gives the same result with both cultures.

    This is a problem because "str." is a VERY common abbreviation used with street names in Germany. Of course this could be easily solved if it were possible to overwrite the detected culture.

    Tuesday, June 27, 2017 2:01 PM
  • This was enabled a few months ago. Use setLang and setMkt as documented here

    [Blog] [twitter] [LinkedIn]

    Tuesday, June 27, 2017 4:20 PM
  • Thank you very much for the quick answer, this looks like just what we need.

    While I do feel a little dumb for not finding these options, it would propably help if this information could also be added to the migration guides from v6.3 and v7.


    Tuesday, June 27, 2017 4:56 PM