It will be tricky to backport the localized resources to old releases like 7.5 and 7.4. The localization will be based on resource strings in the master branch of GitHub repo. If we blindly backport all localized resources to 7.5 and 7.4, it's highly possible to break something, as some strings may be removed in later versions, but we are not backporting the corresponding code changes to 7.5 and 7.4.

Given that 7.4 is about to reach the end of its life cycle, and 7.5 is not even the stable version today, I think we should not support localization for those 2 versions. For 7.6, the mismatch described above can also happen but should be in a smaller scale.

Do we need to add localization for modules that we ship with PowerShell like Archive, PSGet, PSResourceGet and ThreadJob?

Ideally, yes, we should. I need to talk to Jason about that. But they will need to be localized in their corresponding repos, not in PowerShell repo.

It will raise a new question: how to ship the localized resources for those modules? We cannot ship those modules with all the localized resources dlls, as that will increase the size of the module, which will affect the PowerShell package size.

Could we also:

1. Remove the 15 stale  $excludeList  entries from the five ResourceValidation tests.
2. Add a lightweight test ensuring every neutral  .resx  file is matched exactly once by  LocProject.json , and every  LocItem  matches at least one file?

This would catch both missing localization coverage and stale manifest entries in CI. But these are non blocking.

Remove the 15 stale $excludeList entries from the five ResourceValidation tests.

@jshigetomi, Good catch on the resource tests! They are under test\powershell\engine\ResourceValidation. I will submit a separate PR to clean them up (so I can merge this one to unblock the onboarding request). I will address this feedback in this PR, as Travis, the code owner, has to approve this PR, so I cannot merge it today anyways :)

Add a lightweight test ensuring every neutral .resx file is matched exactly once by LocProject.json , and every LocItem matches at least one file?

I'm not sure how to test that, as the LocProject.json file uses wildcard instead of specifying every file. The wildcard is supposed to include all default .resx files within the specified directories. We can talk about this offline.