![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(137.6, 99%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EC%3C/text%3E%3C/svg%3E)
Not Monitored
Tag not monitored by Microsoft.
35,928 questions
Short answer is "Use language tags" like the BCP-47 style en-US or vec-IT.
LCIDs are a fairly broken concept that started being deprecated with Windows Vista. One of the biggest problems is that there are over 6000 languages and hundreds of regions. Yet
https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-makelangid shows that only 1-0x1FF are really available for primary languages, so 511 languages. And only 1-0x1F for sublanguages, so 31 variations of a languages. CLDR has more than 31 variations of English, for one (en-US, en-GB, etc.) Unfortunately, that means that LCIDs don’t scale.
For those reasons, all new locales get an LCID of 0x1000 (LOCALE_CUSTOM_UNSPECIFIED). If the user happens to have that as their default locale, that will become 0xc00 (LOCALE_CUSTOM_DEFAULT). If it’s otherwise in their language profile, it could get a dynamically assigned LCID such as 0x2000 or 0x2400.
Because of these limitations, use of LCIDs is strongly discouraged, and we’d hope that new applications would use the locale name instead (eg: en-US). All of the NLS APIs that take LCIDs have name-based variants as of Windows Vista. In the event that isn’t possible, locales may use the LCID of 0x1000. That is what the locale builder would use for a custom locale for Venetian.
Nominally, some bits of the LCID are reserved for “user-defined languages” as in the link above, however it’s unclear to me how useful that would be in this case. Such “user defined” lcids are typically only consumed within an application and not shared with the system.
LCIDs have not been assigned for some time. Over half of the locales shipped currently in Windows, many from CLDR, are these “no-LCID” locales and use the 0x1000 LOCALE_CUSTOM_UNSPECIFIED LCID. Applications interested in broad locale support should consider moving to the BCP-47 style locale names and away from LCIDs.
Additionally, in Windows 10, we also support “constructed” locales where Windows recognizes millions of valid BCP-47 tags even if they aren’t backed by in-box data. If asked for data for those locales, then Windows will attempt to fill in data as best as it can.