Как узнать версию PowerShell в Windows 10, 8.1, 8, 7

В данной статье показаны действия, с помощью которых можно узнать установленную версию Windows PowerShell в операционных системах Windows 10, 8.1, 8, 7.

PowerShell — это оболочка командной строки с поддержкой задач и язык скриптов на основе платформы .NET.

PowerShell позволяет системным администраторам и опытным пользователям быстро автоматизировать задачи для управления операционной системой и поэтому всегда рекомендуется убедиться, что ваша система использует последнюю версию PowerShell.

Чтобы узнать установленную версию PowerShell, запустите консоль Windows PowerShell любым из способов и выполните следующую команду:

В строке PSVersion вы увидите версию PowerShell.

Также, чтобы узнать версию PowerShell, можно использовать дополнительные команды:

Результат выполнения команд показан на скриншоте ниже.

Ниже приведены версии, которые устанавливаются по умолчанию в соответствии с версией Windows:

• Windows 10 (см. примечание) PS 5.1
  Windows Server 2016
• Windows 8.1PS 4.0
  Windows Server 2012 R2
• Windows 8PS 3.0
  Windows Server 2012
• Windows7 с пакетом обновления 1 (SP1)PS 2.0
  Windows Server 2008 R2 с пакетом обновления 1 (SP1)

• Если в начальном выпуске Windows 10 включены автоматические обновления, PowerShell обновляется с версии 5.0 до 5.1
• Если оригинальная версия Windows 10 не обновлена в Центре обновления Windows, версия PowerShell будет 5.0

Как узнать версию Powershell и Windows в командной строке?

Через командную строку в Windows можно выполнить множество действий, у которых есть аналог в виде интерфейса. В «десятке» разработчики добавили улучшенную версию программы. В приведенной ниже статье мы расскажем, как узнать версию Powershell.

Запуск программы

Для начала необходимо открыть приложение. Для этого можно воспользоваться поисковой строкой в меню «Пуск» — самый простой вариант. В поиске впишите название — Windows Powershell, и запустите программу привычным способом.

Перед вами появится практически стандартная командная строка. Внешние отличия приложения — в измененном цвете окна, а также в подсвечивании команд разных уровней.

Как узнать версию Powershell?

Версию приложения можно определить при помощи него же. Для этого потребуется ввод специальной команды. Вам необходимо перейти в окно и ввести в строку $host.version, после чего нажать на клавишу Enter для применения. В результате на экране появится небольшая таблица, в которой нам нужны значения Build и Revision.

Однако чтобы узнать больше информации, лучше воспользоваться командой $PSVersionTable. После применения этой строки вы увидите большую таблицу с множеством значений. Второй сверху строкой является Version, напротив которой и указана нужная версия приложения.

Узнаем версию Windows

Можно узнать версию Windows в Powershell при помощи другой команды. Принцип действий тот же — вы вписываете строку на английском языке и жмете Enter. Для этого откройте окно командной строки и введите winver. После этого появится отдельное окно, в котором будет необходимая информация об операционной системе, включая версию и сборку.

Также есть еще одна команда — systeminfo. Она не открывает дополнительное окно, а показывает таблицу с информацией внутри самой Powershell. Здесь вы найдете данные об операционной системе, процессоре, BIOS, сетевых адаптерах и многом другом.

Последний вариант — команда WMIC. В ней также можно определить версию Windows, но в немного неудобном формате. Дело в том, что данные будут отображаться в беспорядочном расположении, поэтому найти нужные значения вам придется самостоятельно.

Как в Windows 10 определить системный язык

Как известно, Windows 10 поддерживает установку языковых пакетов, с помощью которых можно изменять локализацию интерфейса операционной системы. С этим очень близко связано понятие системного языка. Системный язык это не тот, который был добавлен с помощью языкового пакета, а тот, который был выбран при установке самой системы. Если вы работаете на корпоративном компьютере, язык которого менялся посредством установки MUI -пакетов, возможно, вы захотите узнать, какой язык использовался в системе изначально.

Способов определить системный язык несколько.

Рассмотрим их по порядку.

С помощью консольной утилиты DISM

Запустите от имени администратора командную строку и выполните в ней команду dism /online /get-intl . Через несколько секунд получите результат.

Обратите внимание на параметр «Язык пользовательского интерфейса по умолчанию». Его значение и будет системным языком.

С помощью консоли PowerShell

Запустите консоль PowerShell от имени администратора и выполните команду [CultureInfo]::InstalleduICulture .

Значение параметра DisplayName будет указывать на системный язык. Обратите также внимание на параметр LCID, он содержит код языка, прописанный в реестре Windows (смотрите ниже).

С помощью редактора реестра и таблицы декодирования

Командой regedit откройте редактор реестра и разверните ветку

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Language

В правой колонке окна редактора найдите строковый параметр InstallLanguage (он в самом низу) и посмотрите его значение.

Оно представлено четырёхзначным кодом, для расшифровки которого следует воспользоваться таблицей декодирования на сайте MSDN. В нашем примере код 0419 соответствует русскому языку.

Как определить язык интерфейса Windows?

Как узнать язык интерфейса Windows?

Языковой интерфейс Windows – язык локализованной версии Windows, применявшийся и указанный во время установки. Все меню, диалоговые окна, окна ошибок и справки будут встречать пользователя именно на этом языке. До тех пор, пока пользователь не выберет другой язык. Другими словами, язык интерфейса Windows это именно язык пользователя, установленный администратором; на нём будет говорить любой из создаваемых новых пользователей. Язык интерфейса системы можно изменить только в том случае, если к основному языку установлен ещё как минимум один дополнительный. Сейчас вы узнаете точно, на каком языке говорит Windows 7/10, сеанс которой на данный момент запущен.

Как узнать языковой интерфейс Windows из cmd?

Открываем консоль от имени администратора и вводим команду:

Как видно по выдаче терминала, с помощью этой команды вы увидите все дополнительные языковые пакеты, доступные при смене раскладки клавиатуры.

Как узнать язык интерфейса Windows из PowerShell?

На этот раз запускаем консоль PowerShell от имени администратора и вводим команду:

Выводимая здесь информация аналогична cmd-шной. Эти два способа являются наиболее информативными вариантами обнаружить языковой пакет Windows. Однако в запасе у вас есть ещё один вариант – реестр.

Как определить язык Windows с помощью реестра?

Отправляемся через редактор реестра

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Language

Нам лишь остаётся вооружённым взглядом присмотреться к двум параметрам справа. Это Default и InstallLanquage. Первый из них определяет установленный по умолчанию язык системы, второй – показатель LCID (Язык ID). Показатель имеет числовой вид, и за его расшифровкой вам придётся отправиться за справкой на офсайт Microsoft.

У меня всё. Теперь вы точно знаете, на каком языке разговаривает ваша Windows. Ведь до того вы не знали, правда?

Вадим Стеркин

Сегодня я покажу приемы из личной практики. С этими ситуациями я сталкивался сам либо участники форума, которым я помогал. Я также расскажу о ценном дедовском методе применения региональных параметров одной командой, а в качестве бонуса – о нововведении в версии 20H1.

[+] Сегодня в программе

Замечание об учетной записи Microsoft

При работе с аккаунтом Microsoft есть возможность синхронизации языковых параметров. Если она включена, выполнение действий из этой статьи может привести к неоднозначным результатам.

Из облака могут подтягиваться параметры, настроенные на другом ПК или ранее сконфигурированные на этом же ПК. Второе возможно при многократном изменении настроек в короткий промежуток времени. Поэтому для чистоты эксперимента синхронизацию языковых настроек лучше отключить.

Добавление и удаление языков

В форум пришел человек, который пользуется японским языком, но только периодически. Он установил японский язык и получил соответствующий метод ввода. Но поскольку этот язык нужен лишь изредка, большую часть времени он только мешает (раскладок и без него было три).

Время уходит на ручные действия и загрузку языкового пакета. Вопрос был в том, как оптимизировать процесс.

Для начала не нужно ставить языковой пакет, чтобы получить метод ввода. Достаточно добавить язык, а флажки с дополнительных компонентов можно снять.

В статье про неудаляемые языки я рассказывал, что список языков представляет собой массив. Там я оставлял только нужные языки, а здесь будет точечная работа с японским.

Добавление: скрипт добавляет японский язык и обновляет список языков.

Удаление: скрипт получает список языков, находит там японский и удаляет его, после чего обновляет список языков.

В тему форума я доставил конфету – архив со скриптами и CMD-файлами для их простого запуска. Полить ее шоколадной глазурью можно, повесив на ярлыки сочетания клавиш.

Управление методами ввода (раскладками)

У меня на виртуальном десктопе клиента проявилась странная проблема. После перезагрузки из переключателя языков исчезала кастомная фонетическая раскладка, которой я пользуюсь очень много лет, так сложилось исторически ©

Переключатель методов ввода тоже исчезал, поскольку ради одного английского он не нужен. При этом раскладка корректно отображалась в свойствах русского языка. Вручную это решалось так: добавить стандартную раскладку – удалить фонетическую – добавить фонетическую – удалить стандартную.

Я автоматизировал это скриптом в автозагрузке. Каждый элемент языкового массива содержит набор свойств – языковых параметров. Ими тоже можно рулить в PowerShell.

Скрипт получает список языков и очищает методы ввода для стоящего вторым русского. Вообще, полная очистка не предусмотрена, потому что у языка всегда должен быть хотя бы один метод ввода. Поэтому в графическом интерфейсе невозможно удалить из языка единственную раскладку. Однако дальше добавляется раскладка с нужным идентификатором, а затем уже обновленный список раскладок применяется к языку.

Код 0419:A0000419 относится к моей фонетической раскладке. У вас она не установлена, поэтому скрипт просто удалит все раскладки из русского языка. Это к вопросу, как сделать язык без метода ввода 😉

Управление региональными форматами

В форум пришел человек, у которого в 20H1 после перезагрузки сбрасывался региональный формат с украинского на русский. У меня проблема воспроизвелась, поэтому я предложил обходной путь – при входе в систему задавать скриптом нужный формат региона.

Форматы не входят в сферу языков, поэтому способы выше не подходят. Выручает другой командлет – Set-Culture, задающий пользовательский регион с помощью идентификатора локали, LCID (в данном случае – украинской).

Управление различными языковыми настройками одной командой

На самом деле в форуме я предложил другой метод управления региональными форматами. Он мне вспомнился в рамках написания статьи о настройке языка ввода при входе в систему, но там его некуда было пристегнуть. Способ можно назвать «дедовским», потому что он работает еще со времен Windows Vista.

Создается специальный файл ответов в формате XML, который передается в качестве параметра командной строки элементу панели управления intl.cpl!

Делаем трюк два в одном! XML-файл добавляет украинский язык и задает регион, а русская стандартная раскладка заменяется на фонетическую.

Сохраненный файл можно применить одной командой из первой строки.

С помощью XML также можно установить системную кодовую страницу и скопировать параметры в системные аккаунты и профиль Default. В этом случае команду надо выполнять от имени администратора, а изменение локали применяется после перезагрузки.

Способ описан в KB2764405. Подробностей там немного, но есть пример точечной настройки форматов, а также ссылка на справку по XML. Судя по документу, когда-то метод затачивался под скрипты групповой политики в организациях, блокирующих доступ пользователей к региональным настройкам. В списке ОС статьи базы знаний отсутствует Windows 10, однако в целом технология в ней работает.

Более того, в ряде пограничных сценариев – это единственный метод автоматизации применения региональных настроек!

Международные команды DISM и командлеты PowerShell дополняют друг друга, но не покрывают всех ситуаций. Смотрите развесистый скрипт Проничкина на GitHub, где он комбинирует командлеты с файлом ответов для настройки системных учетных записей и удаленных сессий PowerShell.

Я не могу рекомендовать XML в качестве единственного способа применения региональных настроек, поскольку он обладает ограничениями (например, невозможно добавить несколько языков в один прием), а в некоторых сценариях ведет себя непоследовательно. Но если не извращаться и применять по делу, это вполне рабочий вариант.

Бонус: настройка предпочитаемого языка интерфейса в Windows 10 20H1

В блоге Майкла Нихауза недавно появилась запись с отсылкой к сессии Ignite 2019, которая привлекла мое внимание. В 20H1 придумали, как предотвратить проблему, с которой сталкивались многие международные организации и некоторые домашние пользователи.

Суть проблемы в том, что невозможно обновить ОС до новой версии или переустановить систему поверх, если язык дистрибутива не совпадает с языком установки системы.

Дома это решается обновлением посредством Windows Update, а при обновлении с диска – предварительной сменой языка из среды восстановления, о чем рассказывал в своем канале Telegram почти три года назад.

Однако 90% процентов организаций с многоязычной средой развертывают английский дистрибутив с языковыми пакетами, а необходимый пользователям язык задают параметром файла ответов UILanguage. Поскольку параметр в первую очередь задает язык установки ОС, впоследствии администраторы наступают на грабли, пытаясь обновить такую систему до новой версии с английского дистрибутива через WSUS/SCCM.

Суть изменения описывает слайд 12 презентации. В версии 20H1 предпочитаемый язык интерфейса ОС можно задать:

• как и прежде параметром UILanguage в файле ответов, но теперь он не задает язык установки ОС, т.е. не блокирует обновление
• новой командой DISM для автономных образов: dism /image:c:\target /set-sysuilang:ru-ru

Это не решает проблем с уже установленными ОС, но позволяет их избежать в новых установках.

Заключение

Несмотря на многочисленные итерации графического интерфейса языковых настроек, способы автоматизации управления языками и методами ввода вполне стабильны. Да, в Windows 8 вместе с PowerShell 3.0 появились командлеты типа Get-WinUserLanguageList. Тогда же появились компоненты по требованию (features on demand), изменившие в том числе подход к управлению языковыми пакетами и компонентами. Но существенным изменением это было 8 лет назад, а сейчас лишь эволюционирует.

Об авторе

Вадим — владелец этого блога, и почти все записи здесь вышли из-под его пера. Подробности о блоге и авторе здесь. Поддержать автора вы можете тут.

Вас также может заинтересовать:

Я в Telegram

Подпишитесь на канал и читайте интересные записи чаще! Есть вопросы? Задайте их в чате.

комментариев 17

Глядя как вы в очередной раз показываете решение пользовательской задачи через PowerShell, возникает вопрос — а как этот самый PowerShell максимально эффективно и быстро изучить, и где смотреть справочник по командам, с информацией для каких версий ОС/PS оно актуально? Просто это выглядит очень интересно и удобно, но для того с чем сталкивался — обычно проще было сотворить cmd или найти и допилить что-то на базе vbs. Что-то сделанное через PS в основном вижу в этом блоге.

Хороший вопрос! CMD далеко не всегда проще, хотя бывает (тот же schtasks vs. scheduledtasks). Но если вы не осилили FOR (как я), то в CMD будет совсем тяжко 🙂

Andrew D: а как этот самый PowerShell максимально эффективно и быстро изучить

Изучать фундаментально — по книгам, например. Могу порекомендовать на английском:
• Windows PowerShell Cookbook (Lee Holmes)
• Learn Windows PowerShell in a Month of Lunches (Jeffery Hicks, Don Jones)
• Windows PowerShell in Action (Bruce Payette) — это рекомендация Василия Гусева и единственная книга по PS, которую он читал 🙂 Он же настоятельно советует встроенную справку (Get-Help, Get-Command, Get-Member).

Andrew D: где смотреть справочник по командам, с информацией для каких версий ОС/PS оно актуально?

Помимо справки в документации удобно сделано https://docs.microsoft.com/powershell/
Есть браузер модулей, есть справка по командлетам, например, Get-WinUserLanguageList (версия PS в меню слева вверху).

Немного покопался, для понимания «с чего начать» мне кажется годным еще и этот ресурс:
http://get-powershell.ru/2015/vvedenie-v-powershell/

Недавно на Хабре вышел небольшой цикл статей по PS. Для обзорного изучения, кмк достаточно. Детали и тонкости, после, по необходимости. Ибо лучшее изучение, это в процессе использования.

Согласна с комментарием.
Внизу страницы у Вадима есть список «рекомендую ресурсы», там есть источники в том числе и по Powershell.

Да, там хорошие источники (иначе я бы их не рекомендовал), но изучать основы по ним не получится. Там можно найти относительно простые примеры/задачи, но уровень знания PS у этих людей на порядок выше моего и контент соответствующий:)

Нужен командлет Get-WinLanguageList показывающий доступные коды с читаемым названием языка.
Тогда и работа происходила более консистентно

Оба параметра объект. Сейчас, при добавление строка, а при удалении объект

Еще одна неоднозанчность.
$List.Add(«ja-JP») — в кавычках, строка
Set-Culture uk-UA — без кавычек, как бы ссылка на объект.

Не совсем понял. Вот читаемые — EnglishName .

Если речь про все возможные (а не установленные), то можно наверное заморочиться и извлечь все cultures. Но только не все совпадут с LanguageTag, что видно даже из вывода выше. Поэтому можно использовать EnglishName — вполне наглядно.

Lecron: Недавно на Хабре вышел небольшой цикл статей по PS. Для обзорного изучения, кмк достаточно.

Видимо, речь об этом https://habr.com/ru/company/ruvds/blog/503818/ (одна из частей). Может для начинающих он ок, но как по мне — там в основном список командлетов и примеры вывода. Даже в решении практических задач таковых задач фактически нет:)

Думаю, так людей на пошик не вдохновить, поэтому у меня другой подход 😉

Да, все возможные. Хотя бы просто на посмотреть, даже если не будет участвовать в скрипте. А то захочу поставить например голландский, иди броди по сети, ищи коды.

Про englishName не понял. Хотя возможную проблему с languageTag заметил. По полю аккуратно разложены грабли? Или есть рецепт чтобы вход и выход совпадал? Хочется такого

LangCode даже можно принять извне параметром. Set-WinUserLanguageList строки на вход принимает. В вашем примере в список языков кладется обычная строка. Значит можно оперировать только строками языковых кодов. Но никак. Не логично.

Lecron: А то захочу поставить например голландский, иди броди по сети, ищи коды

Зайдете сюда, а ссылка есть в статье, правда в другом разделе: LCID. Думаю, что ИД локали и языков одинаковые.

Lecron: Про englishName не понял

В примере я удаляю по LanguageTag, но можно и по имени. Но добавить так не получится, да.

Lecron: Значит можно оперировать только строками языковых кодов. Но никак. Не логично.

Да, я тоже наступил на эти грабли, поэтому такой вот скрипт удаления и получился 🙂 Объяснить затрудняюсь, это уже к гуру пошика.

Vadim Sterkin: поэтому такой вот скрипт удаления и получился

Все равно что-то царапает. Даже не разница кода, а что пользователю нужно подставлять разные параметры. ja-Jp и (ja или Japanese). То есть вначале выполнить комманду, посмотреть на ее вывод, и только потом отредактировать скрипт.
Как понимаю, отброс суффикса JP происходит, если существует только одна культура с префиксом ja. Для hr такого не произойдет, ибо BA и HR. Список языков нашел как [System.Globalization.Cultureinfo]::GetCultures(«AllCulture») . В идеале, поведение должно быть таким (пример на Питоне):

дальше, как в статье. Кто захочет прокачать скиллы в PS может заняться.

Сейчас, при добавление строка, а при удалении объект

Вообще, строго говоря, в обоих случаях объект. (И даже не только потому, что строка — на самом деле тоже объект. Объект типа «строка», System.String.)

В справке по Get-WinUserLanguageList написано, что коммандлет возвращает объект вот этого типа:

Т.е. это объект, который представляет собой коллекцию (List) объектов типа «WinUserLanguage»

Точно такой же объект принимает параметр -LanguageList коммандлета Set-WinUserLanguageList. Это, опять же, следует из справки.

Когда вы выполняете операции с коллекцией (add или remove), вы используете соответствующие методы .NET, присущие объекту коллекции (типа «List»).

Как следует из документации по этим методам, в качестве аргумента передаётся объект того же типа, которому принадлежат все объекты коллекции. Т.е., в нашем случае, «Microsoft.InternationalSettings.Commands.WinUserLanguage».

Как же так работает, когда вы указываете строку (типа «ja-JP»)? А вот так. PowerShell умеет подспудно превращать одни типы в другие, при соблюдении ряда условий. (Т.е. если он понимает, какой тип от него ожидают, и такое превращение в принципе возможно.)

Как это проверить?

Первая строка создаёт объект. Поскольку мы не указываем тип явно, PowerShell угадывает сам. Тут угадать не сложно — текст по умолчанию считается объектом типа «String». Что мы и проверяем второй строкой, которая выводит полное имя типа. Соответственно, пример выше выводит результат: «System.String». Но это произошло бы в общем случае, если бы мы с этой строкой ничего дальше не делали (и PowerShell бы не испытывал необходимости приводить объект к другому типу).

А что же происходит в нашем случае, когда PowerShell заранее знает, что метод «Add» ожидает получить объект типа «Microsoft.InternationalSettings.Commands.WinUserLanguage»? Он пытается превратить строку, котрую вы указали, в объект нужного типа. Примерно вот так.

Первая строка нужна для того, чтобы PowerShell подгрузил библиотеки, отвечающие за нужный тип. Если её не выполнять (и не запускать предварительно какие-нибудь коммандлеты из этого модуля), то произойдёт ошибка из-за того, что тип не будет найден. (В случае, когда ранее выполнялся коммандлет «Get-WinUserLanguageList» такой необходимости нет, потому что модуль уже загружен).

В третьей строке мы создаём новый объект, явно указывая его тип. На самом деле это несколько избыточно. В примерах Вадима нескольких объектов разных типов не создаётся, вся конвертация происходит «на лету». Но я старался показать в несколько шагов для наглядности. Ну и в результате четвёртая строка проверяет тип нового объекта, и он предсказуемо возвращает значение «Microsoft.InternationalSettings.Commands.WinUserLanguage».

Именно это и происходит «за кадром», когда вы выполняете метод Add, указывая объект типа строка.

В теории, точно так же оно бы работало и для метода «Remove». Но происходит заковыка, связанная с тем, что новый объект не идентичен тому, что уже есть в коллекции. И если пытаться удалить новый объект из коллекции, то объект, который указан как удаляемый, в коллекции не находится. В результате попытка удаления завершается с ошибкой.

Поэтому приходится не создавать новый объект и удалять его, а выбирать его непосредственно из коллекции по фильтру — как и делает Вадим. Считайте это нюансами реализации конкретных коммандлетов. (В общем случае я бы ожидал, что создаваемый объект будет идентичен тому, что в коллекции. Свойства-то у них совпадают).

Но в любом случае, в вызовах обоих методов (Add и Remove) используется именно объект типа «Microsoft.InternationalSettings.Commands.WinUserLanguage», а не строка.

Еще одна неоднозанчность.
$List.Add(«ja-JP») — в кавычках, строка
Set-Culture uk-UA — без кавычек, как бы ссылка на объект.

Почему в первом случае строка в кавычках, я объявнил выше. (Без кавычек не получится, потому что парсер не поймёт, чего вы от него хотите. Метод .Add ожидает объекта, а текст без кавычек — это ещё не объект. И однозначно превратить текст в объект без кавычек в этом случае не получается).

А во втором случае Вадим сделал то, чего я делать настоятельно не рекомендую именно из дидактических соображений. Он пропустил то, что технически можно пропустить. Хотя это добавляет неоднозначности.

На самом деле во втором случае там тоже строка. Просто когда вы указываете строку как значение для параметра, PowerShell понимает, что надо превратить этот текст в строку. По-хорошему всегда надо указывать кавычки, но работает и без кавычек.

Вот так. В случае метода без кавычек не работает, а в случае значения параметра работает. (Ну, если не встречаются пробелы или спецсимволы). Поэтому, конечно, всегда стоит использовать кавычки, чтобы не запутывать неопытных пользователей.

А ещё надо указывать имена параметров. Вот так было бы совсем хорошо.

Все равно что-то царапает. Даже не разница кода, а что пользователю нужно подставлять разные параметры. ja-Jp и (ja или Japanese). То есть вначале выполнить комманду, посмотреть на ее вывод, и только потом отредактировать скрипт.

Опишите, пожалуйста, задачу. Потому что я пока не понимаю, что именно вам не нравится.

Если вы хотите добавить, и не знаете точно, как называется то, что вы хотите добавить — воспользуйтесь ссылкой Вадима. (Я не дам руку на отсечение, что коды всегда совпадают. Потому что не знаю, как именно работает внутри превращение строки к объекту типа «Microsoft.InternationalSettings.Commands.WinUserLanguage». Но в общем, думаю, что предположение Вадима недалеко от истины.)

Если вы хотите удалить — ну, вы, наверное знаете, что именно хотите удалить?

Тут в прошлой записи был задан интереснейший вопрос.

Расскажите в комментариях, почему вы используете или принципиально не используете учетную запись Microsoft.

«При работе с аккаунтом Microsoft есть возможность синхронизации языковых параметров. Если она включена, выполнение действий из этой статьи может привести к неоднозначным результатам.«

Вот поэтому и не использую. Использование «учётной записи» может привести к неоднозначным результатам.

В моей шараге мне вложили в голову золотую мысль, можно сказать правило:
«Если выполнение программы приводит к неоднозначному результату, который трудно или невозможно предсказать, то эта программа плоха, а программист, её написавший — плохой программист.»

Использование учётной записи M$ есть жирный пример такой программы, пользование которой всегда вызывает сомнения в результатах работы. То есть неоднозначный и/или труднопредсказуемый результат.

Произошла ли синхронизация? Какие данные точно синхронизируются, а какие нет? Какие приложения настроили использование облака для синхронизации, а какие нет? Синхронизируются ли параметры? А синхронизируются ли «старые» настройки и параметры? Синхронизируются? А какие из них не синхронизируются? А настройки реестра? А приложения? А почему пропал флажок «автоматический вход»? Что это за новый «пин-код»? Какие данные передаются на сервера? С какой периодичностью? С какой целью? Какие файлы отправляет в M$ защитник и как они соспоставляются с учётными записями? Сколько ресурсов (почему так много. ) используют службы телеметрии и обновлений? Когда в следующий раз я увижу рекламу рекомендации в пуск? И вообще, могут ли предложить мне эти рекомендации что нибудь внятное? Не произойдёт ли через все эти «фичи» и учётные записи утечка слишком чувствительной информации?

Я уж не говорю про политику сбора и использования «персонифицированной информации» (и ключей шифрования, хех), в этом деле вообще никто никогда не сознается, слишком большие деньги (и не только деньги. В основном не деньги.) на кону. Тут правды не ищите, её здесь нет. Однозначность соответствующая.

Существование таких учёных записей есть результат притока в сеть малообразованного (самое интересное, даже не всегда платёжеспособного. Угадайте, чем такие платят.) населения земли из-за экстенсивной политики расширения сетей и «сервисов». Вот за них в M$ и решают, что надо синхронизировать, какую кнопку надо убрать, а где без учётной записи никуда не пустят. Ну это так, лирика.

Чтобы по хорошему использовать виндовые навороты (облачные, дизайновые, системные), вводимые с 2015-го года, необходимо прочесть не один талмуд (половина из них 404, спасибо M$), и не только по «how to..» и юзабилити: крайне рекомендуется глубоко ознакомиться с текущими и запланированными корпоративным процессами, терминологией и прочим мелкомягким энтерпрайзом… И это надо как-то совместить со всеми теми знаниями(опыт и юзабилити всех прошлых версий, НЕМАЛЫЙ И НЕМАЛОВАЖНЫЙ), что были накоплены за прошлые годы, и что вот-вот могут быть ВНЕЗАПНО признаны устаревшими. А ведь кому-то в этом мире приходится быть не только » самолично опытным пользователем ПК», но и техническим специалистом. И в той области, такие вот «бесплатные» «учётные записи» с кучей свистоперделок не канают от слова совсем, там котируются немного другие материи — надёжность, отказоустойчивость, контролируемость процессов и т.д. Здравые идеи, в общем-то, очевидно, что они распространены среди тех, кто просто шарит (и среди тех, кто «шарит». сборщикам и прочим «бесам» привет).

Отвечу только по теме синхронизации языковых настроек. Она в целом корректно работает по моим наблюдениям, в т.ч. я не вижу жалоб в форуме на нее.

Я подспудно ожидал, что не преминут поддеть. Но здесь же я обозначил стандартные грабли. Очевидно, что если вам нужен японский язык периодически и только на одном ПК, то слать это в другие не надо.

Менее очевидно, что многократные изменения за короткий период могут давать неожиданный результат. Но это не практический, а экспериментальный сценарий.