как сменить язык в командной строке windows 10
Гарантированная локализация/русификация консоли Windows
Введение
Данный материал не предлагает строгий алгоритм действий, а направлен на описание узловых проблем, с которыми неизбежно сталкивается разработчик локализованного консольного приложения, а также некоторые возможные пути их разрешения. Предполагается, что это позволит разработчику сформировать стратегию работы с локализованной консолью и эффективно реализовать существующие технические возможности, большая часть которых хорошо описана и здесь опущена.
Виды консолей
В общем случае функции консоли таковы:
управление операционной системой и системным окружением приложений на основе применения стандартных системных устройств ввода-вывода (экран и клавиатура), использования команд операционной системы и/или собственно консоли;
запуск приложений и обеспечение их доступа к стандартным потокам ввода-вывода системы, также с помощью стандартных системных устройств ввода-вывода.
Отдельным видом консоли можно считать консоль отладки Visual Studio (CMD-D ).
Конфликт кодировок
Совет 1. Выполнять разработку текстовых файлов (программных кодов, текстовых данных и др.) исключительно в кодировке UTF-8. Мир любит Юникод, а кроссплатформенность без него вообще невозможна.
Совет 2. Периодически проверять кодировку, например в текстовом редакторе Notepad++. Visual Studio может сбивать кодировку, особенно при редактировании за пределами VS.
Поскольку в консоли постоянно происходит передача управления от приложений к собственно командному процессору и обратно, регулярно возникает «конфликт кодировок», наглядно иллюстрируемый таблица 1 и 2, сформированных следующим образом:
Команды и код приложения под катом
> Echo ffffff фффффф // в командной строке
PS> Echo ffffff фффффф // в PowerShell
код тестового приложения:
Командную часть задания все консоли локализовали практически без сбоев во всех кодировках, за исключением: в WPS неверно отображена русскоязычная часть команды во всех кодировках.
Табл. 1. Результат выполнения команды консоли Echo ffffff фффффф
Вывод тестового приложения локализован лишь в 50% испытаний, как показано в табл.2.
Табл. 2. Результат запуска приложения LoggingConsole.Test
Сoвет 3. Про PowerShell забываем раз и навсегда. Ну может не навсегда, а до следующей мажорной версии.
По умолчанию Windows устанавливает для консоли кодовые страницы DOS. Чаще всего CP437, иногда CP866. Актуальные версии командной строки cmd.exe способны локализовать приложения на основе русифицированной кодовой страницы 866, но не 437, отсюда и изначальный конфликт кодировок консоли и приложения. Поэтому
Проблемы консолей Visual Studio
Отдельной опцией Visual Studio является встроенная односеансная консоль отладки, которая перехватывает команду Visual Studio на запуск приложения, запускается сама, ожидает компиляцию приложения, запускает его и отдает ему управление. Таким образом, отладочная консоль в течение всего рабочего сеанса находится под управлением приложения и возможность использования команд Windows или самой консоли, включая команду CHCP, не предусмотрена. Более того, отладочная консоль не воспринимает кодовую страницу по умолчанию, определенную в реестре, и всегда запускается в кодировке 437 или 866.
Совет 6. Тестирование приложения целесообразно выполнять во внешних консолях, более дружелюбных к локализации.
Локализация отладочной консоли Visual Studio
Ниже приведен пример вывода тестового приложения в консоль, иллюстрирующий изложенное. Метод Write получает номера текущих страниц, устанавливает новые кодовые страницы вводного и выводного потоков, выполняет чтение с консоли и записывает выводную строку, содержащий русский текст, в том числе считанный с консоли, обратно в консоль. Операция повторяется несколько раз для всех основных кодовых страниц, упомянутых ранее.
приложение запущено в консоли с кодовыми страницами 1251 (строка 2);
приложение меняет кодовые страницы консоли (current, setted);
приложение остановлено в консоли с кодовыми страницами 1252 (строка 11, setted);
Приложение адекватно локализовано только в случае совпадения текущих кодовых страниц консоли (setted 1251:1251) с начальными кодовыми страницами (строки 8 и 10).
Код тестового приложения под катом
Совет 7. Обязательный и повторный! Функции SetConsoleCP должны размещаться в коде до первого оператора ввода-вывода в консоль.
Стратегия локализации приложения в консоли
Удалить приложение PowerShell (если установлено), сохранив Windows PowerShell;
Установить в качестве кодовую страницу консоли по умолчанию CP65001 (utf-8 Unicode) или CP1251 (Windows-1251-Cyr), см. совет 5;
Разработку приложений выполнять в кодировке utf-8 Unicode;
Контролировать кодировку файлов исходных кодов, текстовых файлов данных, например с помощью Notepad++;
Реализовать программное управление локализацией приложения в консоли, пример ниже под катом:
Пример программной установки кодовой страницы и локализации приложения в консоли
Как я могу изменить язык в CMD?
Как я могу изменить язык клавиатуры с помощью CMD?
На вкладке «Клавиатуры и язык» щелкните «Сменить клавиатуру». Щелкните Добавить. Разверните нужный язык.
Как изменить язык командной строки в Windows 10?
Открыть настройки. Перейдите в раздел «Время и язык». Слева нажмите на Регион и язык. Справа выберите язык, на котором вы хотите отображать Windows 10.
Как я могу изменить язык моего ПК на английский?
Изменить языковые настройки
Какой язык программирования CMD?
CMD технически является языком сценариев оболочки, таким как bash, sh или csh. Это полезно для автоматизации задач, связанных с вызовом существующих программ из командной строки.
Как изменить язык клавиатуры в PowerShell?
Установить раскладку клавиатуры по умолчанию с помощью PowerShell
Как открыть экранную клавиатуру в CMD?
Щелкните Начать экранную клавиатуру. Нажмите клавиши Windows + R, чтобы открыть окно «Выполнить», или откройте командную строку. Введите osk и нажмите Enter. Это немедленно откроет экранную клавиатуру.
Как изменить язык отображения?
Измените язык отображения
Выбранный вами язык отображения изменяет язык по умолчанию, используемый такими функциями Windows, как «Настройки» и «Проводник». Нажмите кнопку «Пуск», затем выберите «Настройки»> «Время и язык»> «Язык». Выберите язык в меню языка отображения Windows.
Почему я не могу изменить язык отображения Windows?
Выполните всего три шага; вы можете легко изменить язык отображения в Windows 10. Откройте «Настройки» на своем ПК. Щелкните Время и язык, а затем перейдите в меню «Регион и язык». Нажмите «Добавить язык», чтобы найти нужный язык и загрузить его.
Как я могу изменить язык моего ноутбука?
Могу ли я изменить язык Windows 10?
Выбранный вами язык отображения изменяет язык по умолчанию, используемый такими функциями Windows, как «Настройки» и «Проводник». Выберите Пуск> Параметры> Время и язык> Язык. Выберите язык в меню языка отображения Windows.
Как поменять язык обратно на английский?
Как изменить язык на Android
Почему я не могу изменить язык в Windows 10?
Путь: клавиша Windows, настройки, время и язык, регион и язык. Если желаемого языка нет в списке, нажмите «Добавить язык», найдите его и загрузите. Тот же путь: клавиша Windows, настройки, время и язык, регион и язык. Щелкните нужный язык, а затем щелкните «Параметры».
Какая польза от CMD?
Что такое командная строка. В операционных системах Windows командная строка — это программа, которая имитирует поле ввода на экране текстового пользовательского интерфейса с графическим пользовательским интерфейсом Windows (GUI). Его можно использовать для выполнения введенных команд и выполнения расширенных административных функций.
Каковы основные команды Windows?
Здесь мы представляем основные команды, которые должен знать каждый пользователь Windows.
…
Команды командной строки 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 предпочитаемый язык интерфейса ОС можно задать:
Это не решает проблем с уже установленными ОС, но позволяет их избежать в новых установках.
Заключение
Несмотря на многочисленные итерации графического интерфейса языковых настроек, способы автоматизации управления языками и методами ввода вполне стабильны. Да, в 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 — без кавычек, как бы ссылка на объект.
Если речь про все возможные (а не установленные), то можно наверное заморочиться и извлечь все 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: поэтому такой вот скрипт удаления и получился
дальше, как в статье. Кто захочет прокачать скиллы в PS может заняться.
Сейчас, при добавление строка, а при удалении объект
Вообще, строго говоря, в обоих случаях объект. (И даже не только потому, что строка — на самом деле тоже объект. Объект типа «строка», System.String.)
В справке по Get-WinUserLanguageList написано, что коммандлет возвращает объект вот этого типа:
Т.е. это объект, который представляет собой коллекцию (List) объектов типа «WinUserLanguage»
Точно такой же объект принимает параметр -LanguageList коммандлета Set-WinUserLanguageList. Это, опять же, следует из справки.
Как следует из документации по этим методам, в качестве аргумента передаётся объект того же типа, которому принадлежат все объекты коллекции. Т.е., в нашем случае, «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 — без кавычек, как бы ссылка на объект.
А во втором случае Вадим сделал то, чего я делать настоятельно не рекомендую именно из дидактических соображений. Он пропустил то, что технически можно пропустить. Хотя это добавляет неоднозначности.
На самом деле во втором случае там тоже строка. Просто когда вы указываете строку как значение для параметра, PowerShell понимает, что надо превратить этот текст в строку. По-хорошему всегда надо указывать кавычки, но работает и без кавычек.
Вот так. В случае метода без кавычек не работает, а в случае значения параметра работает. (Ну, если не встречаются пробелы или спецсимволы). Поэтому, конечно, всегда стоит использовать кавычки, чтобы не запутывать неопытных пользователей.
А ещё надо указывать имена параметров. Вот так было бы совсем хорошо.
Все равно что-то царапает. Даже не разница кода, а что пользователю нужно подставлять разные параметры. ja-Jp и (ja или Japanese). То есть вначале выполнить комманду, посмотреть на ее вывод, и только потом отредактировать скрипт.
Опишите, пожалуйста, задачу. Потому что я пока не понимаю, что именно вам не нравится.
Если вы хотите добавить, и не знаете точно, как называется то, что вы хотите добавить — воспользуйтесь ссылкой Вадима. (Я не дам руку на отсечение, что коды всегда совпадают. Потому что не знаю, как именно работает внутри превращение строки к объекту типа «Microsoft.InternationalSettings.Commands.WinUserLanguage». Но в общем, думаю, что предположение Вадима недалеко от истины.)
Если вы хотите удалить — ну, вы, наверное знаете, что именно хотите удалить?
Тут в прошлой записи был задан интереснейший вопрос.
Расскажите в комментариях, почему вы используете или принципиально не используете учетную запись Microsoft.
«При работе с аккаунтом Microsoft есть возможность синхронизации языковых параметров. Если она включена, выполнение действий из этой статьи может привести к неоднозначным результатам.«
Вот поэтому и не использую. Использование «учётной записи» может привести к неоднозначным результатам.
В моей шараге мне вложили в голову золотую мысль, можно сказать правило:
«Если выполнение программы приводит к неоднозначному результату, который трудно или невозможно предсказать, то эта программа плоха, а программист, её написавший — плохой программист.»
Использование учётной записи M$ есть жирный пример такой программы, пользование которой всегда вызывает сомнения в результатах работы. То есть неоднозначный и/или труднопредсказуемый результат.
Произошла ли синхронизация? Какие данные точно синхронизируются, а какие нет? Какие приложения настроили использование облака для синхронизации, а какие нет? Синхронизируются ли параметры? А синхронизируются ли «старые» настройки и параметры? Синхронизируются? А какие из них не синхронизируются? А настройки реестра? А приложения? А почему пропал флажок «автоматический вход»? Что это за новый «пин-код»? Какие данные передаются на сервера? С какой периодичностью? С какой целью? Какие файлы отправляет в M$ защитник и как они соспоставляются с учётными записями? Сколько ресурсов (почему так много. ) используют службы телеметрии и обновлений? Когда в следующий раз я увижу рекламу рекомендации в пуск? И вообще, могут ли предложить мне эти рекомендации что нибудь внятное? Не произойдёт ли через все эти «фичи» и учётные записи утечка слишком чувствительной информации?
Я уж не говорю про политику сбора и использования «персонифицированной информации» (и ключей шифрования, хех), в этом деле вообще никто никогда не сознается, слишком большие деньги (и не только деньги. В основном не деньги.) на кону. Тут правды не ищите, её здесь нет. Однозначность соответствующая.
Существование таких учёных записей есть результат притока в сеть малообразованного (самое интересное, даже не всегда платёжеспособного. Угадайте, чем такие платят.) населения земли из-за экстенсивной политики расширения сетей и «сервисов». Вот за них в M$ и решают, что надо синхронизировать, какую кнопку надо убрать, а где без учётной записи никуда не пустят. Ну это так, лирика.
Чтобы по хорошему использовать виндовые навороты (облачные, дизайновые, системные), вводимые с 2015-го года, необходимо прочесть не один талмуд (половина из них 404, спасибо M$), и не только по «how to..» и юзабилити: крайне рекомендуется глубоко ознакомиться с текущими и запланированными корпоративным процессами, терминологией и прочим мелкомягким энтерпрайзом… И это надо как-то совместить со всеми теми знаниями(опыт и юзабилити всех прошлых версий, НЕМАЛЫЙ И НЕМАЛОВАЖНЫЙ), что были накоплены за прошлые годы, и что вот-вот могут быть ВНЕЗАПНО признаны устаревшими. А ведь кому-то в этом мире приходится быть не только » самолично опытным пользователем ПК», но и техническим специалистом. И в той области, такие вот «бесплатные» «учётные записи» с кучей свистоперделок не канают от слова совсем, там котируются немного другие материи — надёжность, отказоустойчивость, контролируемость процессов и т.д. Здравые идеи, в общем-то, очевидно, что они распространены среди тех, кто просто шарит (и среди тех, кто «шарит». сборщикам и прочим «бесам» привет).
Отвечу только по теме синхронизации языковых настроек. Она в целом корректно работает по моим наблюдениям, в т.ч. я не вижу жалоб в форуме на нее.
Я подспудно ожидал, что не преминут поддеть. Но здесь же я обозначил стандартные грабли. Очевидно, что если вам нужен японский язык периодически и только на одном ПК, то слать это в другие не надо.
Менее очевидно, что многократные изменения за короткий период могут давать неожиданный результат. Но это не практический, а экспериментальный сценарий.