Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LocalizationService.GetLanguageByIsoCode my return language different to the one requested #5959

Closed
KevinJump opened this issue Jul 19, 2019 · 7 comments · Fixed by #6090
Closed

Comments

@KevinJump
Copy link
Contributor

Calling the LocalizationService GetLanguageByIsoCode may return a 'parent' language to the one requested if it can't find it.

e.g GetLanguageByIsoCode("en-US") will return the "en" language if the en-US language is missing.

this may or may not be a bug but the method should be at least annotated to tell you that you might not get what you asked for - maybe there should be a fallback option exposed?

ultimately it happens in the repo:

public int? GetIdByIsoCode(string isoCode, bool throwOnNotFound = true)

@kjac
Copy link
Contributor

kjac commented Jul 19, 2019

For reference: The reason for doing so is described in #4519

The new option to localize the backoffice using the language files (#5358) may also weigh in on any decision to undo #4519 😄

@ronaldbarendse
Copy link
Contributor

Ouch, that's not a change you would add to a repository, especially without opt-in! 😮

And PR #4519 doesn't correctly get the parent culture for cultures that contain multiple dashes or just different names (e.g. zh-Hans-HK, which parents are zh-CHS > zh-Hans > zh).

@kjac
Copy link
Contributor

kjac commented Aug 8, 2019

I'll pick this one up 👍

@kjac
Copy link
Contributor

kjac commented Aug 8, 2019

OK so... we can't solve this with an opt-in/overload on the affected method(s) without causing a breaking change on ILanguageRepository.

Given how #5358 now allows us to localize the backoffice independently of the dictionary and the active languages, perhaps the best approach here is to simply revert #4519 and no longer (attempt to) support fallbacks to culture invariant translations in the dictionary? Unless there is some Cloud implication I am unaware of here - can you have user defined language overrides on Cloud?

@nul800sebastiaan
Copy link
Member

Thanks @kjac - I know you slept on it and had some more clever ideas, look forward to seeing those!

@kjac
Copy link
Contributor

kjac commented Aug 10, 2019

@nul800sebastiaan you got it 😆 new PR in #6090 reverts the changes from #4519 and adds the same feature by other means.

@nul800sebastiaan nul800sebastiaan added community/pr release/8.1.3 type/bug and removed state/needs-more-info We don't have enough information to give a good reply labels Aug 12, 2019
@nul800sebastiaan
Copy link
Member

Fixed in #6090

Cherry picked to 8.1.3 in 87845ee

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants