🎌 Get the users' most preferred locale/language from your app's available translations with zero dependencies

• Uses the Intl.Locale API (backwards compatible)
• Works on node & browsers
• Zero dependencies
• TypeScript support

This library is fully typed with TSDoc examples. View the online documentation here: https://wopian.github.io/preferred-locale/

import { preferredLocale } from 'preferred-locale'

// Note: All examples assume the browser's reported locales are:
// [ 'en-GB', 'en', 'ja-JP', 'en-US', 'ja' ]

const supportedLocales = ['en-US', 'ja-JP']
const fallbackLocale = 'ja-JP'
const locale = preferredLocale(supportedLocales, fallbackLocale)
console.log(locale) // 'en-US', converts 'en-GB' and 'en' to 'en-US' as neither are translated, placing it before 'ja-JP' in preference order

preferredLocale(['en-us', 'fr-fr'], ['en-us'], {
  regionLowerCase: true
}) // 'en-us', converts 'en-GB' to 'en-us' as 'en-gb' is not translated

preferredLocale(['de', 'fr'], ['fr'], {
  languageOnly: true
}) // 'fr', converts 'en-GB' to 'en' (etc). No matching locales so returns 'fr' fallback

preferredLocale(['en-US', 'en-GB'], ['en-US']) // 'en-GB', as it is translated and first in user's preference order

preferred-locale@2 is a rewrite of preferred-locale@1, written in TypeScript as a native ESM module. If your environment does not support ESM modules, you can continue to use preferred-locale@1 as the resultant code is identical.

Many web applications that automatically detect the browser language and serve the relevent translation are fundamentally broken.

A browser that signals the user prefers the following locales (index 0 being most preferred) should never return content in Japanese (ja-JP) if the application has translations for Japanese and American English (en-US):

• [ 'en-GB', 'en', 'ja-JP', 'en-US', 'ja' ]

Instead, many applications (e.g Epic Games' store, help and documentation) will instead serve their users content in Japanese as they do not provide translations for British English, only American English and only check for exact matches.

preferred-locale fixes this by traversing the supported node/browser languages in order of priority:

1. If an exact match is found it uses that (e.g en-GB is translated).
2. If the node/browser language is supported but the region is not (e.g Australian English), the canonical region is looked up and tested against (e.g en-AU becomes en-US),
3. If only a language is provided (e.g en), the canonical region is looked up and tested against (e.g en becomes en-US)
4. If no node/browser locale resolves to a translated locale, the fallback locale is returned

A step-by-step demonstration of how preferred-locale@1 works with your own browser locales is available at eehz9.csb.app.

Application has translations for en-US and ja-JP

1. Raw browser locales [ 'en-GB', 'en', 'ja-JP', 'en-US', 'ja' ]

2. Unify the browser locales [ 'en-GB', 'en-US', 'ja-JP', 'en-US', 'ja-JP' ]

3. Deduplicate the locales [ 'en-GB', 'en-US', 'ja-JP' ]

4. Remove locales not translated [ 'en-US', 'ja-JP' ]

5. User gets content in en-US

See CONTRIBUTING

See Github Releases

All code released under MIT