SorenLundt / WinGet-Wrapper

PowerShell Scripts to bulk import WinGet packages to InTune including all package metadata.
GNU General Public License v3.0
95 stars 15 forks source link

Winget language and errors with the detection rules #10

Open mdurini-swisscom opened 11 months ago

mdurini-swisscom commented 11 months ago

Hi, I found that winget output language is based on the Microsoft Account display language. The detection rule is searching for the string "version:" at a certain point, but in my output is "versione:" (italian), so it's failing. I can workaround it, changing the detection rules of my package, but it will be nice if you will find a way to have this check language agnostic. Thank you in advance

SorenLundt commented 9 months ago

Hi, The detection script is built up by running winget commands and extract results and use within script/variables etc. Winget does not give us any option to output using a different language and rewriting the script to support every language is a challenge of course. However maybe we could re-write the script to find the version without actually using "version:" in the search.

Any other ideas ?

InnovationForge-com commented 8 months ago

Hi, I had the same issue even though I have an English Windows. That's because Winget CLI uses the language which is first in the priority list under the Windows Language settings. Which was German in my case. So, in theory a workaround is to put English always first, even if another system language is used.

Another workaround would be to use the Winget PowerShell module like mentioned here: https://github.com/microsoft/winget-cli/discussions/3461 Sadly, it's not part of the default install but it seems to be regularly updated by Microsoft and mentioned in the official Winget release log.

https://www.powershellgallery.com/packages/Microsoft.WinGet.Client Commands to use to get the package infos: Find-WinGetPackage Get-WinGetPackage

SorenLundt commented 8 months ago

Hi, Yeah, basically it means that Winget-Wrapper only support en-US currently, until a solution is found. Using the WinGet PowerShell Module makes sense, however requires a huge tasks to re-write big parts of WinGet-Wrapper.

Also had a look at the Module Microsoft.WinGet.Client as you mentioned and unfortunately it does not support running in SYSTEM context,. And actually using winget with system context was the exact reason winget-wrapper started.. See the issue here: https://github.com/microsoft/winget-cli/issues/4422

If you have a good solution and a chance to work on this, i appreciate collaboration in form of a pull request