Use of useFallbackTranslation results in faulty language selection

I’m submitting a…

[ ] Regression (a behavior that used to work and stopped working in a new release)
[X] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

Setting useFallbackTranslation causes transloco to assume that the fallback language is scoped when it’s not, which results in a requested lang that has a / prefix. E.g. /en

1. Specify a fallback fallbackLang: 'en'
2. Setting active language to sv-SE (it should not be listed as available either)
3. Have a missing translation for foo in sv-SE
4. Notice that the HttpLoader getTranslation is first called with sv-SE
5. Notice that the HttpLoader getTranslation is then called with /en

Note that the default HttpLoader most likely survives as two slashes often works:

@Injectable({ providedIn: 'root' })
export class TranslocoHttpLoader implements TranslocoLoader {
  constructor(private http: HttpClient) {}

  getTranslation(lang: string) {
    return this.http.get<Translation>(`/assets/i18n/${lang}.json`);
  }
}

With this loader the computed url would be /assets/i18n//en.json.

If the loader loads translations from an api like /lang=${lang} it will result in /lang=/en and perhaps break.

Expected behavior

A language should only be considered scoped if the language name contains a /. A fallback language maybe shouldn’t require to be under the primary language scope. Currently foo/bar will fallback to foo/${lang}.

This function that checks for scope should be checking if the language id contains a /:

  _isLangScoped(lang: string) {
    return this.getAvailableLangsIds().indexOf(lang) === -1;
  }

Workaround

Just assume the requested language exists just to avoid it being considered scoped:

transloco.setAvailableLangs([locale.language]);
const availableLanguages = transloco.getAvailableLangs() as string[];
if (!availableLanguages.includes(locale.language)) {
	// Just assume this language is available somewhere
	transloco.setAvailableLangs([...availableLanguages, locale.language]);
}
transloco.setActiveLang(locale.language);

Though this makes it harder to actually use scoped translations

Minimal reproduction of the problem with instructions

For bug reports please provide the STEPS TO REPRODUCE and if possible a MINIMAL DEMO of the problem, for that you could use our stackblitz example

What is the motivation / use case for changing the behavior?

Environment

Angular version: X.Y.Z


Browser:
- [ ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

[shaharkazaz]

@krokofant Seems like this is a breaking change. If there is a point where you do know the languages you add them at runtime via the API, if not you can still use your solution. Also, please check that your tests are passing before opening a PR (we also have a pre-push hook for it, you might have bypassed it)

[krokofant]

@shaharkazaz Did you see the reproduction? I could supply a PR if I get some direction