implement locale fallback for all locales

[SamMousa]

This implements language fallbacks in a more generic approach.

Instead of picking the locale string collection at the start, we try the locales and their fallbacks in order searching for a specific string.

The goal is to allow supporting custom locales more easily:

• Setting a survey locale to nl-something, which is unknown would result in strings from the nl translations.
• Allow overriding just a single string for a locale, while other strings are taken from the base locale in a cascading fashion

The idea is that instead of picking a whole locale dictionary at the start, we just define all possible locales.
Imagine this situation:

defaultLocale = "en-US"
currentLocale = "de-DE"
requestedLocale = "nl-test"
requestedMessage= "otherItemText"

In the current version, requesting an unknown language will just use the currentLocale, and if that doesn't exist use the defaultLocale.
This PR changes this behavior to be more granular. It will check each dictionary:

1. Check this.locales["nl-test"] if found return
2. Check this.locales["nl"] if found return
3. Check this.locales["de-DE"] if found return
4. Check this.locales["de"] if found return
5. Check this.locales["en-US"] if found return
6. Check this.locales["en"] if found return
7. If not found call this.onGetExternalString(...)

Marking as a draft so we can discuss the implementation. Tests still pass even though the implementation and behavior changed, this means that the tests were not thorough enough to detect this change in behavior.

[SamMousa]

Please review & provide me some feedback. The failing CI jobs are brittle and not related to any of the code changes!

[SamMousa]

@andrewtelnov apologies for the brutal ping. Could you check if this is something you would like in the core?

[andrewtelnov]

Why do you remove "getCurrentStrings"?
It can be used by somebody to get strings object by locale.

[andrewtelnov]

@andrewtelnov apologies for the brutal ping. Could you check if this is something you would like in the core?

Hello Sam,
No problem at all.

Thank you,
Andrew

[SamMousa]

Why do you remove "getCurrentStrings"?

In this implementation a string is picked based on the best matching language, so it is no longer the case that a single object can be found for a language.

For example, the result of getCurrentStrings('nl-NL-informal') could just contain: {"completeText": "Informal thanks"}.
But the getString() function would actually work for all SurveyJS strings.

What is missing in the library is some documentation on what is considered part of the public API. I assumed this was not part of the public API and as it was no longer used internally I chose to remove it.
If you insist that it is part of the SJS public API then that would be indeed a breaking change; however due to the new way it works its result would already change so it is already a somewhat breaking change.

Note that since locales is already a public property the getCurrentStrings() is just a getter that offers no clear benefits except a fallback. But using it with the fallback doesn't actually work as expected with the new per string fallback mechanism.

[andrewtelnov]

@SamMousa I got an idea.
In my mind, it should work in the following way:

1. Check this.locales["nl-test"] if found return
2. Check this.locales["nl"] if found return
3. Check default locale if found return
4. Check this.locales["en"] locale if found return
   If not found call this.onGetExternalString(...)

I will need to write a unit test on this functionality.

Thank you,
Andrew

[andrewtelnov]

@SamMousa I am sorry, I have created my own PR. Here is the related issue.
I write code in TDD style and it is easy for me to create Unit test first and then write the code to make it works. I used your idea, but code is a litle bit different.
Please review PR, is it OK?

Thank you,
Andrew

[SamMousa]

Will do later today