$translateProvider.determineLanguage does not work on Safari as expected

[mohlendo]

When I use $translateProvider.determineLanguage in combination with $translateProvider.registerAvailableLanguageKeys, I would expect that the language key en_US would match case-insensitive, but it doesn't.
The following plunker shows that bug. On Safari, no matching language key is found and you see no translation. On Chrome it works as expected.

http://plnkr.co/edit/gFzzNh?p=preview

[0x-r4bbit]

Exactly, 'en_US' and 'en_us' are two different keys for angular-translate. Mind sending a PR? :)

[tspaeth]

@PascalPrecht Can we close this one though?

[yllieth]

I still have this issue in both version 2.2.0 and 2.4.0 of angular-translate. I finally added a decorator to override preferredLanguage method :

angular
  .module('myApp', ['pascalprecht.translate'])
  .config(function($provide) {
    $provide.decorator('$translate', function($delegate) {
      var _preferredLanguage = $delegate.preferredLanguage;

      $delegate.preferredLanguage = function() {
        var guessed = _preferredLanguage();

        // ensure that $preferredLanguage looks like fr_FR or fr_fr [Safari], and not "fr-fr" of just "fr", ...
        var language = guessed.match(/^[a-z]{2}([-_][a-zA-Z]{2})?$/);
        if (language !== null && language[0] === guessed) {
          var splittedLanguages = language[0].replace('-', '_').split('_');
          if (splittedLanguages.length === 1) {
            // fr => fr_FR
            return splittedLanguages[0].toLowerCase() + '_' + splittedLanguages[0].toUpperCase();
          } else if (splittedLanguages.length === 2) {
            // fr_fr => fr_FR
            return splittedLanguages[0].toLowerCase() + '_' + splittedLanguages[1].toUpperCase();
          }
        }

        return guessed;
      };

      return $delegate;
    });
  })

By doing so, preferredLanguage is always well-formatted (en_US, fr_FR) even if detected language looks like fr, fr_fr, ...

I thought that resolution of #722 in 2.4.0 will address this issue, but it still relevant for me.

ℹ️ My configuration of $translateProvider is

angular
  .module('myApp', ['pascalprecht.translate'])
  .config(function($translateProvider) {
    $translateProvider.fallbackLanguage('en_US');
    $translateProvider.determinePreferredLanguage();
    $translateProvider.useStaticFilesLoader({ prefix: './locales/', suffix: '.json' });
  })

[knalli]

Maybe you send this as a PR? :)

[yllieth]

With pleasure! But if I propose this as a PR, I'm going to directly include it in the code, not as a decorator. I think negociateLocale function is the best place, isn't it ?

[knalli]

But if I propose this as a PR, I'm going to directly include it in the code, not as a decorator.

Of course :)

I would prefer either getLocale() (reading user agent locales) or determinePreferredLanguage() (processing them). I'm not sure why we should not straighten the strings internally.

[knalli]

Closing this, we have the open PR (#755). That is still valid.

[knalli]

The PR was replaced with a feature named uniformLanguageTag. Preview available here.