Doesn't work on non-english operating systems

[endpointmanager]

Running "Find-Package OpenJS.NodeJS -Provider WinGet" on a german OS (Windows 10, x64, 21H2) does not find any packages. (winget-cli is installed)

exception:

Find-Package : No match was found for the specified search criteria and package name 'OpenJS.NodeJS'. Try
Get-PackageSource to see all available registered package sources.
In Zeile:1 Zeichen:1

• Find-Package OpenJS.NodeJS -Provider WinGet

•   + CategoryInfo          : ObjectNotFound: (Microsoft.Power...ets.FindPackage:FindPackage) [Find-Package], Exceptio
   n
    + FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.FindPackage
  

[ethanbergstrom]

What does the WinGet output look like when the following is ran with German localization?
winget search --id=OpenJS.NodeJS

Is the issue with the column names?

[endpointmanager]

Yes, column names are localized:

In german, the word for "Name" and "Version" is the same (compared to english), but in other languages that could be different.

[ethanbergstrom]

Unfortunately, I dont have any great options at the moment. To your point back on the winget-cli project thread, there aren't any good options I can think of to address this, due to how...fluid WinGet's output is.

Which column names are displayed change depending on the parameters passed, can vary in depth into the output depending on cache state, and are the only thing I've found to semi-reliably parse out the data (truncated column data issues aside).

I'm open to a PR to help make it better, but it's not something I'm interested in boiling the ocean to fix when the underlying CLI utility is so in flux and it's output emitter is in such a poor state at the moment.

It looks like the column names are stored in these localization XML files, so maybe if the underlying Cresendo script picked localization, grabbed the localization files from somewhere, and performed the column-wise parsing based on picking the correct set of column names based on the user's locale?

Interestingly - winget actually changed the game on its own localization support a couple weeks ago: microsoft/winget-cli#1761

[ethanbergstrom]

OK fine I might have fixed it :)

@endpointmanager can you try upgrading the Cobalt module to v0.0.8+ to see if that fixes it? I don't have an easy way to test non-en-US locales.

[endpointmanager]

I was not able to get it running at my first attempt (tried with Cobalt v0.0.9), but I figured out why ...

1. Please replace "Get-WinSystemLocale" with "Get-UICulture" ...
   $locale = (Get-UICulture).Name
   ...because "Get-WinSystemLocale" returns the locale (e.g. used for DateTime-Format and so on), and does not represent the display language (e.g. used in winget output)
   (In my case, I'm using "en-US" as locale, and "de-DE" as display language)

2. Not sure, if thats an issue with Crescendo, but the output of the process did not matched some of the Header-Names of the xml, because of the wrong encoding of the winget output.

E.g. "AvailableHeader"...
from xml = "Verfügbar" (correct)
from winget-output (PS) = "Verf├╝gbar" (wrong encoding)
from winget-output (ISE) = "Verfügbar" (wrong encoding)

Only header names with an umlaut was affected.

I solved it temporarily by using
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
before I use any of the cmdlets.

However, this works only in a Powershell window, not in ISE.

[ethanbergstrom]

Thanks, this has been very helpful.

I've updated Cobalt in v0.0.10 to use Get-UICulture and the Winget package provder in v0.0.4 to force interpreting native output encoding as UTF8.

Unfortunately there doesn't seem to be a way with GitHub Actions VMs to change the language pack used, so please give it another test when you're able.

[endpointmanager]

Hi Ethan,

Good news...
Looks like you solved the problem :-)

Starting with v0.0.10 (Cobalt-Module) and v0.0.4 (WinGet-Module), I can use the WinGet Package Management Provider on my german-localized client, and I think it should work with other languages too.

Greetings,
Paul

[ethanbergstrom]

Awesome news, thanks @endpointmanager for all your help on this!