[vim/vim] Vim on MS-Windows seems to ignore LC_* evnvironment variables for setting its locale configuration (Issue #20201)

lkintact

unread,

May 12, 2026, 2:51:58 AMMay 12

to vim/vim, Subscribed

lkintact created an issue (vim/vim#20201)

### Steps to reproduce

1. In the `cmd` shell set an `LC_*` environment variable, for example with `set LC_TIME=zh_CN.UTF-8`
2. Run `vim.exe --clean`
3. Execute `:language`. Vim displays something like "Региональные настройки : "LC_COLLATE=Russian_Russia.1251;LC_CTYPE=C;LC_MONETARY=Russian_Russia.1251;LC_NUMERIC=C;**LC_TIME=Russian_Russia.1251**".
Notice that the bolded part is _not_ **LC_TIME=zh_CN.UTF-8**, as one might expect it to be.
5. Execute `:let $LC_TIME = "zh_CN.UTF-8"`, repeat executing `:language`. Vim displays the same as at step 3, while, again, one might expect the bolded part to be changed to **LC_TIME=zh_CN.UTF-8**.

I can change the locale for time with `:language time zh_CN.UTF-8` fine, but if ignoring `LC_*` on MS-Windows is not a bug, but a feature, it should probably be mentioned in `doc/mlang.txt`.

### Expected behaviour

K.Takata

unread,

May 12, 2026, 3:12:35 AMMay 12

to vim/vim, Subscribed

k-takata left a comment (vim/vim#20201)

if ignoring setting LC_* for locale configuration on MS-Windows is not a bug, but a feature, it should probably be mentioned in doc/mlang.txt.

In my understanding, normal Windows applications don't support setting the locale by LC_* variables. Not sure if Vim should support this.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.

mattn

unread,

May 12, 2026, 3:40:35 AMMay 12

to vim/vim, Subscribed

mattn left a comment (vim/vim#20201)

In my understanding, normal Windows applications don't support setting the locale by LC_* variables.

Actually Vim on Windows does honor several LC_* / LANG variables — it''s just that the report hit a locale-name format issue rather than a "not supported" case.

1. Message language (LC_ALL / LC_MESSAGES / LANG)

Since the MSVC CRT does not define LC_MESSAGES, src/locale.c has its own get_mess_env() that reads these variables directly via mch_getenv() and feeds the result to gettext. So on Windows:

set LANG=ja
vim.exe --clean
:echo v:lang        " → ja
:messages           " UI messages in Japanese

2. Date/time formatting (LC_TIME)

f_strftime() in src/time.c calls the CRT strftime() directly without overriding the locale, and init_locale() does setlocale(LC_ALL, ""), which on Windows pulls values from the environment per the C standard. So LC_TIME does take effect — provided the value is in a form the CRT recognizes:

set LC_TIME=ja-JP                          rem UCRT-style
vim.exe --clean
:echo strftime("%c", localtime())          " Japanese date/time
:echo strftime("%A")                       " 日曜日 etc.

The reason LC_TIME=zh_CN.UTF-8 in the original report had no effect is that the Windows CRT does not accept POSIX-style names with _ separators and .UTF-8 codepages in the general case. UCRT accepts hyphenated BCP-47-ish names (e.g. zh-CN), and .UTF-8 is only honored on Windows 10 1803+. The legacy MSVCRT only takes Windows-style names like Chinese_China.936.

So I think it would be most accurate to document in doc/mlang.txt that on MS-Windows the LC_* variables are honored but the locale-name format follows the Windows CRT (e.g. ja-JP, Chinese_China.936) rather than the POSIX convention, instead of saying they are ignored.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.

mattn

unread,

May 12, 2026, 3:43:55 AMMay 12

to vim/vim, Subscribed

mattn left a comment (vim/vim#20201)

FYI: for the legacy MSVCRT (older Windows / non-UCRT builds), a Japanese locale would be specified as e.g. japanese_japan.cp932 (or equivalently Japanese_Japan.932) — the legacy CRT expects language_country.codepage.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.

lkintact

unread,

May 12, 2026, 4:23:39 AMMay 12

to vim/vim, Subscribed

lkintact left a comment (vim/vim#20201)

set LC_TIME=ja-JP                          rem UCRT-style
vim.exe --clean
:echo strftime("%c", localtime())          " Japanese date/time
:echo strftime("%A")                       " 日曜日 etc.

This doesn't work for me, the last two commands output date/time and day of week, respectively, in my system (Russian) format.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.

mattn

unread,

May 12, 2026, 4:42:34 AMMay 12

to vim/vim, Subscribed

mattn left a comment (vim/vim#20201)

@
Thanks for testing. The fact that neither ja-JP (UCRT-style) nor japanese_japan.cp932 (legacy-MSVCRT-style) worked is interesting — it means it is not just a locale-name format mismatch. To narrow this down, could you check a few things?

Which CRT your vim.exe is linked against. Run :version and look at the compiler / runtime line (e.g. MSVC 19xx → UCRT; older MinGW → MSVCRT). The set of locale-name forms setlocale() accepts depends on this.
Whether the env var actually reaches Vim. After set LC_TIME=ja-JP and starting vim.exe --clean, run:
```
:echo $LC_TIME
```
It should print ja-JP. If it is empty, the variable is not being inherited by the Vim process for some reason.
Whether the CRT can load the locale at all, independent of env vars:
```
:language time ja-JP
:echo strftime("%A")
```
and
```
:language time japanese_japan.cp932
:echo strftime("%A")
```
If both of these also output Russian, the CRT on your machine is rejecting the locale string itself (locale data not present / wrong runtime), and the LC_TIME env var has no chance of working either. If one of them does produce Japanese output, then the env-var path is the bug.

That should tell us whether this is a runtime / locale-data issue on your system or a real bug in Vim's LC_TIME handling.
@

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.

h_east

unread,

10:53 AM (10 hours ago) 10:53 AM

to vim/vim, Subscribed

h-east left a comment (vim/vim#20201)

The message language part is handled in #20860, which takes it from the
Windows display language instead of the regional format.

LC_TIME, LC_CTYPE and LC_COLLATE are not covered by that and still come from
the regional format, so this issue stays open.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.

Reply all

Reply to author

Forward