Skip to content

25 general dynamically load language list#42

Draft
junc-nf wants to merge 4 commits into
masterfrom
25-general-dynamically-load-language-list
Draft

25 general dynamically load language list#42
junc-nf wants to merge 4 commits into
masterfrom
25-general-dynamically-load-language-list

Conversation

@junc-nf

@junc-nf junc-nf commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@junc-nf junc-nf requested a review from Copilot June 25, 2026 19:23
@junc-nf junc-nf linked an issue Jun 25, 2026 that may be closed by this pull request

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates PasswordValidatorService to determine supported language codes dynamically from the project’s compiled resource sets (instead of a hardcoded switch), and adds unit tests to validate language-code acceptance/rejection behavior.

Changes:

  • Replace hardcoded supported-language switch with a lazy, resource-backed supported language set.
  • Add unit tests covering supported, unsupported, and culture-specific (e.g., en-US) language codes.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
Easy-Password-Validator/PasswordValidatorService.cs Builds supported languages from available Resources.*.resx via ResourceManager, and uses it to validate languageCode.
Easy-Password-Validator-Test/PasswordValidatorTests.cs Adds test coverage for supported/unsupported language codes and common culture-code formats.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +453 to +460
try
{
return _rm.GetResourceSet(c, true, false) != null;
}
catch
{
return false;
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good suggestion. I'm not sure how specific we want to be with exception handling here. @thirstyape please provide guidance.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What other exceptions can occur? It's probably not worth implementing this feature at all if we are introducing the potential for new exceptions.

@junc-nf junc-nf Jun 25, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on my research, GetResourceSet(System.Globalization.CultureInfo culture, bool createIfNotExists, bool tryParents) may throw mainly three exceptions:

  1. ArgumentNullException: only if culture == null, won't happen
  2. MissingManifestResourceException: resources not found with fallback rules
  3. MissingSatelliteAssemblyException, a culture-specific resource is expected but missing, less common

These should be rare in a correctly built package?

Since this is just a feature check (whether a language is supported), it seems reasonable to treat any failure as “not supported” and use a general catch that returns false, rather than introducing new exceptions for consumers, i.e. maybe we can ignore this suggestion?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don’t want to introduce this extra complexity, I think we can keep the original explicit contract and just express it more cleanly with a static HashSet<string> instead of a switch.

Comment on lines +481 to +484
else if (languageCode.Length == 5 && languageCode[2] == '-')
{
return _supportedLanguages.Value.Contains(languageCode.Substring(0, 2));
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if I should touch the original way of checking. @thirstyape please suggest.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot has it backwards based on the library design. We only add region-specific when there is already a 2-letter version. Not entirely clear based on the default being en. In the resource files, Resources.resx is en, then there is also en-CA and en-US for things like neighbor vs neighbour.

In general, if we were to accept a PR for fr-CA we would leave the existing fr, or if someone wanted to submit something such as pt-BR we would change the name to pt as there is not already anything existing for that.

In short, you can ignore Copilot, either what you have here or what was originally there are good.

@junc-nf junc-nf requested a review from thirstyape June 25, 2026 19:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[General]: Dynamically load language list

3 participants