Adding Local Experience Packs to your Windows image

On Windows 10 2004 en-US,

I'm imported the appx french local experience pack into a package,

UILanguage and other setting = fr-FR in the unattend,

Result : en-US display and settings say I'm in french display .........

And on the mdt log I can see "Updated E:\MININT\Unattend.xml with UILanguage=en-US (value was fr-FR)"

Why changing my settings .... MYSTERE

Auto Pilot works, but with so many limitations that for us its practically useless.  Most of these limitations really come down to limitations in Intune.  Here are what I view many of the limitations are:

1. Domain Join to AD you have to be connected to the intranet.  That might have been addressed, I haven't checked lately.  So sending a machine to a user and having them domain join doesn't work.  Microsoft is trying to push everyone to Azure AD instead, that actually does work.  Unfortunately we require AD.
2. Machine naming is a prefix, after that its a random number.  Completely brain dead on trying to assign a machine name.  This isn't a huge technical detail, but it does cause some issues with asset tracking and support.
3. Very limited OU support.
4. Targeting is mostly user based, and while you can do some machine targeting, it treats pretty much everyone the same.  Setting these up to deal with local or business differences is very difficult.  Its not like SCCM where you can create dynamic collections, variable assignments, or even ask questions during OSD. 
5. Dependencies is the main show stopper.  If you need language packs installed before you install a language adaptable application you have to use an advanced packaging technique called batch files.  On the positive side batch files can be setup to do limited decision tree operations.  In other words no precedence, dependency or conditional branching.

The whole Intune idea is that everything is a cloud based experience where user's have control.  If everything is in the cloud, apps are all store based, and work independently of each other it might be possible.  That's basically what happens on a smartphone.  Here's the problem, Windows computers the applications can and do interact.  For instance, if you use WebEx and want the Office extensions to be loaded, Office has to be installed before the WebEx components.  Try and explain to users that they need to add things in order.  I've never gotten a user to follow a set of instructions completely.  That's why Auto Pilot doesn't work.

Bob_Panick No, I'm still fighting the same fight. In what way does Autopilot not work? I was hoping to evaluate it to address this issue, among others.

Did anyone find a solution to this?

I've been beating my head against the wall on it.  I thought I had it solved, only to discover that the LXP routines fail when you try to add them offline because of missing dependencies.  Analyzing German DE-DE I discovered that when you install from the store it adds a bunch of X86 components and updates some existing components.  It looks like the main issue is getting all the prereqs.   But I have concerns that even if I get them installed in a task sequence that the users won't see them because it appears that LXPs are user focused not device focused.

Part of the problem with this is, that many language aware applications need the OS languages installed before they themselves are installed.  Microsoft's answer may be to use Auto Pilot, which quite frankly doesn't work.  Even if we get around all the other Auto Pilot problems, we still have the problem of how do we make sure the LXPs are installed before the applications.  We use task sequences because we can guarantee a sequence of installed items with some intelligence built in.

Well at this point, I think this all moot. Even when you add the languages to the list, it is ONLY for the current user. I hate to think that MS does not have a process for making this available for all users thru via an OSD process or just running a script.

Forgive my ignorance, but I installed the full language packs (.cab) using lpksetup.exe. When I run dism /online /get-intl, I see the installed languages, but as partially localized. That said, is that sufficient if a user wants to change his/her keyboard, UI, etc. language? If not, would I then need to install the local experience packs? One other thing to mention, in the ISO I got from the VLSC for the languages, there were only the local experience packs, and the full languages (.cab) files on there. There were no FOD included, Is that a separate ISO that I need to download? Found this on Benjamin Dudley's comment:

Get-ChildItem -filter *.cab | % {Add-WindowsPackage -Online -PackagePath $($_.name)}

After they are all added, run these commands (Japanese for example):

$LangCode = "ja-JP"
$langs = Get-WinUserLanguageList
$langs.add($LangCode)
Set-WinUserLanguageList $langs -force

Does that mean I need to run this for every language? We have 30 languages for all the countries we are in. We build one gold image. I just want a process that would make the languages available for all users. The machine is already built, so an online process would be ideal. When I injected the languages into the install.wim, cortana/searchUI.exe, for some reason would not work once the machine was built, so I had to end up using lpksetup.exe afterwards.

It seems that after installing the CAB file using DISM on Windows 10 1809, you still have to do more to add the language to the list in the language settings. There are a couple powershell commands you can run to do this... but they have to be run AS THE USER that needs to select the language. In my case (and maybe others), there does not appear to be a way to add languages to a machine during build time and have those languages available for any user to select.

For reference, here is what works for me:

Installing ALL language CAB files (client language pack plus ALL FOD CAB files) via DISM:

Get-ChildItem -filter *.cab | % {Add-WindowsPackage -Online -PackagePath $($_.name)}

After they are all added, run these commands (Japanese for example):

$LangCode = "ja-JP"
$langs = Get-WinUserLanguageList
$langs.add($LangCode)
Set-WinUserLanguageList $langs -force

I hope this helps others.

I have the same problem as EDubs. I can successfully add language packs online using DISM, but the language never shows up in the Settings to select. I even followed this article from Microsoft on how to deploy these with SCCM.

https://support.microsoft.com/en-us/help/4468362/deploy-language-pack-as-application-in-configuration-manager

After it's installed, I verified that the language pack is installed via Dism /online /get-intl. But it's still not in the language settings.

I've even tried to use the FOD commands (add-windowscapability) to add the languages and it's still the same... the just don't show up for the user to select.

Dear EDubs, 

These files ARE the traditional LP's.

You have to config the unattend.xml to config the LP's as "Permanent".

Dear oJHPqptYugMPIJwf ,

Here the way to the LP's:

regards

Christoph

After Weeks of banging my head it's sooo nice to see I'm not the only person struggling with this issue.

I am trying to create a 1903 build, via MDT, that is based on en-gb, but that a user can select to switch to either en-us, zh-cn or zh-hk.

Like others before me I can inject the LP's and LXP's but can't get the GUI to show an easy and visible option for the users to switch without having to download.

MS - C'mon this used to be easy - why have you over complicated it?

Thanks, btw, to all those who have contributed to this forum - it has certainly put my (almost mental) mind at rest. I can now see (and, after many weeks of head banging,  produce evidence) that this is a wider problem.

If anyone does come to a sensible method of doing this via mdt with little user interaction - please step forward and share your knowledge (other wise we appear to be in the hands of, what so far has been an incompetent) Microsoft 😞