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

  • Главная
  • Windows
  • SSD
  • Программы
  • Разное
  • Об авторе
Вы тут: Главная → Popular → Трюки управления языковыми параметрами из PowerShell и командной строки

Трюки управления языковыми параметрами из PowerShell и командной строки

Рубрики: Popular, Windows, Вопрос - Ответ Обновлено: 03.12.2020 комментариев 17

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

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

  • Замечание об учетной записи Microsoft
  • Добавление и удаление языков
  • Управление методами ввода (раскладками)
  • Управление региональными форматами
  • Управление различными языковыми настройками одной командой
  • Бонус: настройка предпочитаемого языка интерфейса в Windows 10 20H1
  • Заключение

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

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

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

Теперь к делу!

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

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

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

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

Трюки управления языковыми параметрами

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

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

$List = Get-WinUserLanguageList
$List.Add("ja-JP")
Set-WinUserLanguageList $List -Force
$List

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

$List = Get-WinUserLanguageList
$remove = $List | where LanguageTag -eq "ja"
$List.Remove($remove)
Set-WinUserLanguageList $List -Force
$List

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

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

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

Трюки управления языковыми параметрами

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

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

$List = Get-WinUserLanguageList
$List[1].InputMethodTips.Clear()
$List[1].InputMethodTips.Add('0419:A0000419')
Set-WinUserLanguageList $List -Force
$List

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

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

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

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

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

Set-Culture uk-UA

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

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

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

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

<!--  control.exe intl.cpl,,/f:"C:\Scripts\lang.xml" 
		https://support.microsoft.com/help/2764405/  -->
<gs:GlobalizationServices xmlns:gs="urn:longhornGlobalizationUnattend">
<!-- Пользователи. Здесь текущий, но с правами администратора можно настроить
	 систему и профиль Default, т.е. все будущие учетные записи -->
    <gs:UserList>
        <gs:User UserID="Current" CopySettingsToDefaultUserAcct="false" CopySettingsToSystemAcct="false"/>  
    </gs:UserList>
<!-- Регион, язык и раскладка клавиатуры в комплекте с ним  -->
    <gs:UserLocale>
        <gs:Locale Name="uk-UA" SetAsCurrent="true" ResetAllSettings="false">
        </gs:Locale>
    </gs:UserLocale>
 <!-- Добавление и удаление раскладок клавиатуры -->
    <gs:InputPreferences>
		<gs:InputLanguageID Action="add" ID="0419:A0000419"/>  
		<gs:InputLanguageID Action="remove" ID="0419:00000419"/> 
    </gs:InputPreferences>
<!-- Язык для программ, не поддерживающих Юникод. Для этого параметра
		команду необходимо запускать с правами администратора.
    <gs:SystemLocale Name="ru-RU"/> -->
 </gs:GlobalizationServices>

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

С помощью 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 лет назад, а сейчас лишь эволюционирует.

Метки: DISM, PowerShell, автоустановка, скрипты, язык Информация в статье применима к Windows 7 и новее

Об авторе

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

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

  • Как грамотно настроить язык ввода на экране входа в Windows 10
  • Как грамотно настроить язык интерфейса Windows 10, магазинных приложений и ввода по умолчанию
  • Как удалить неудаляемые языки в Windows 10
  • 6 языковых настроек Windows, которые могут поставить вас в тупик
← Нюансы беспарольного входа в Windows 10
Fix | Как включить автоматический вход в систему в Windows 10 2004 →
Telegram logo

Я в Telegram

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

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

↓
  1. Andrew D

    17.06.2020 в 12:00

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

    Ваша оценка: Thumb up Thumb down +3
    • Vadim Sterkin

      17.06.2020 в 12:42

      Хороший вопрос! 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 в меню слева вверху).

      Ваша оценка: Thumb up Thumb down 0
      • Andrew D

        17.06.2020 в 13:45

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

        Ваша оценка: Thumb up Thumb down 0
        • Lecron

          17.06.2020 в 14:21

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

          Ваша оценка: Thumb up Thumb down +1
  2. Valentina Lemiakina

    17.06.2020 в 12:23

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

    Ваша оценка: Thumb up Thumb down 0
    • Vadim Sterkin

      17.06.2020 в 12:53

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

      Ваша оценка: Thumb up Thumb down 0
  3. Lecron

    18.06.2020 в 10:21

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

    $List = Get-WinUserLanguageList
    $lang = Get-WinLanguageList | where LanguageTag -eq "ja"
    $List.Remove($lang)
    #$List.Add($lang)
    Set-WinUserLanguageList $List -Force
    $List

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

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

    Ваша оценка: Thumb up Thumb down 0
    • Vadim Sterkin

      18.06.2020 в 12:01

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

      Get-WinUserLanguageList | ft -Property LanguageTag, EnglishName
      
      LanguageTag EnglishName
      ----------- -----------
      en-US       English
      ru          Russian

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

      Ваша оценка: Thumb up Thumb down 0
  4. Vadim Sterkin

    18.06.2020 в 11:47

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

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

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

    Ваша оценка: Thumb up Thumb down 0
    • Lecron

      18.06.2020 в 17:18

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

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

      $LangCode = "ja-JP"
      $List = (Get-WinUserLanguageList).LanguageTag
      $List.Remove($LangCode)
      #$List.Add($LangCode)
      Set-WinUserLanguageList $List -Force
      $List
      

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

      Ваша оценка: Thumb up Thumb down 0
      • Vadim Sterkin

        18.06.2020 в 18:06

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

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

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

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

        $lang = Get-WinLanguageList | where EnglishName -eq "Japanese"

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

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

        Ваша оценка: Thumb up Thumb down 0
        • Lecron

          19.06.2020 в 09:51

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

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

          lang_code = 'ja-JP'
          prfeix = lang_code.rpartition('-')[0]  # берем код без последнего токена, ибо он может быть тройным ks-Arab-IN
          lang_code = prefix if len([1 for lang in AllCulture() if lang.name.startswith(prefix + '-')]) == 1 else lang_code

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

          Ваша оценка: Thumb up Thumb down +1
          • artem

            20.06.2020 в 08:56

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

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

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

            System.Collections.Generic.List&lt;Microsoft.InternationalSettings.Commands.WinUserLanguage&gt;

            (https://docs.microsoft.com/powershell/module/international/Get-WinUserLanguageList)

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

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

            (https://docs.microsoft.com/powershell/module/international/Set-WinUserLanguageList)

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

            https://docs.microsoft.com/dotnet/api/system.collections.generic.list-1.add
            https://docs.microsoft.com/dotnet/api/system.collections.generic.list-1.remove

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

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

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

            Ну, например.

            $Object = 'ja-JP'
            $Object.GetType().FullName

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

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

            Import-Module -Name 'International'
            $Object = 'ja-JP'
            [Microsoft.InternationalSettings.Commands.WinUserLanguage]$NewObject = $Object
            $NewObject.GetType().FullName

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

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

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

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

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

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

            Ваша оценка: Thumb up Thumb down +1
          • artem

            20.06.2020 в 09:04

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

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

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

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

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

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

            Set-Culture -CultureInfo 'uk-UA'
            Ваша оценка: Thumb up Thumb down +2
          • artem

            20.06.2020 в 09:11

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

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

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

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

            Ваша оценка: Thumb up Thumb down 0
  5. gryzun

    27.06.2020 в 15:23

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

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

    Расскажу.

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

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

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

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

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

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

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

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

    Ваша оценка: Thumb up Thumb down 0
    • Vadim Sterkin

      28.06.2020 в 01:55

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

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

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

      Ваша оценка: Thumb up Thumb down 0

Обсуждение завершено.

Subscribers

Популярные записи

  • Как изменить издание Windows, сохранив настройки и установленные программы (204)
  • 5 веских причин использовать учетную запись Microsoft в Windows (207)
  • Как правильно ассоциировать типы файлов с программами в Windows, и почему вам нужно учиться этому заново (215)
  • Создание настроенного образа операционной системы (390)
  • Как удалить неудаляемые языки в Windows 10 (9)
  • 10 мифов Windows 10 LTSC, которые никогда не умрут (204)
  • В чем риск работы в устаревшей операционной системе (180)
  • Еще →

Свежие комментарии

  • Виктор Гораев к записи diskusage vs. dfp: анализ занятого места на диске из командной строки
  • Vadim Sterkin к записи diskusage vs. dfp: анализ занятого места на диске из командной строки
  • Stanislav Vershinin к записи diskusage vs. dfp: анализ занятого места на диске из командной строки
  • Vadim Sterkin к записи diskusage vs. dfp: анализ занятого места на диске из командной строки
  • Vadim Sterkin к записи diskusage vs. dfp: анализ занятого места на диске из командной строки
  • Diogen к записи diskusage vs. dfp: анализ занятого места на диске из командной строки
  • Alexander Kuzin к записи diskusage vs. dfp: анализ занятого места на диске из командной строки
  • Vadim Sterkin к записи diskusage vs. dfp: анализ занятого места на диске из командной строки

Рекомендую ресурсы

  • Windows 10, etc — канал этого блога в Telegram
  • Инсайдеры Windows 10 — чат блога в Telegram
  • Community — новости предварительных сборок
  • Николай Павлов — тайны планеты Excel
  • Вадимс Поданс — PKI, PowerShell и Тера Патрик
  • Василий Гусев — PowerShell и другие скрипты
  • Kazun — PowerShell для взрослых

Реклама

Измененная тема eleven40 Pro на платформе Genesis · Архивы и метки · Правила (16+) · О рекламе · Обратная связь · Вход

Допускается копирование материалов без изменений, с указанием имени автора и гиперссылки на сайт.