[Feature Request] Provide localized builds in the NPM distribution

There is currently no easy way to add a couple of CDNs for several languages of the UI, then load the correct UI based on a parameter.

The page is in a certain language, how to make sure the correct UI gets used even after the user chooses a different language?

My suggestion is to make it so, the UI with the language can be chosen like so after adding those languages as CDN:

var uiJA = new firebaseui.ja.auth.AuthUI(firebase.auth());
var uiEN = new firebaseui.en.auth.AuthUI(firebase.auth());

or even firebaseui_ja or something.

Now, no matter how many different CDNs with languages, they all point to the same variable: firebaseui so it’s difficult to change that after the user switches languages. (especially talking about SPA’s with vueJS)

[nicolasgarnier]

I would use lazy-loading of the library. Your app will be too big and it is not good for performance to include all languages in the same bundle.

So you could still use a URL parameter or a has fragment, for instance let say you load

https://www.example.com/auth?lang=en

your code can be:

const locale = 'en' // Read the locale from the URL parameter here!

const firebaseUILoader;
if (locale === 'en') {
  firebaseUILoader = import('../statics/firebaseui__en.js')
} else if ( (locale === 'ja') {
  firebaseUILoader = import('../statics/firebaseui__ja.js')
}

firebaseUILoader.then(firebaseui => {
  // You can use FirebaseUI here.
});

This is using Webpack’s dynamic import feature. The different localised versions of Firebase will be generated in different chunks that will be loaded on the fly when requested.

As you can see above the library is loaded asynchroneously so you’ll get firebaseui in a Promise. it gets nice though if you use async/await:

const locale = 'en' // Read the locale from the URL parameter here!

async function loadFirebaseUI() {
  const firebaseui;
  if (locale === 'en') {
    firebaseui = await import('../statics/firebaseui__en.js')
  } else if ( (locale === 'ja') {
    firebaseui = await import('../statics/firebaseui__ja.js')
  }

  // You can use Firebase UI here.
}

btw @bojeil-google, it would be cool to provide all the localised JS files in the NPM distrib so taht developers could do that easily.

[tohagan]

Each internationalized version is a separate build. Including all the versions in one file is not feasible.

Oh dear. Looks like you’ve used the wrong implementation architecture to support i18n for SPA web apps!

Typically if a user switches languages, you would redirect to another page (eg. https://www.example.com/auth?lang=ja") and load the UI version with the selected language."

Except that we’re all coding SPA web apps today so we don’t reload pages from the server just one static page index.html and our client side “pages” are not server side rendered (remember: Firebase hosting is for static pages!) So making a Firebase UI build per language is inherently broken.

More commonly we wish to provide a feature in our SPA app to allow the user to change their language, dynamically. We expect that we can call a firebaseui.setLanguage() function that will lazy load a small JSON file to import the language changes. You could provide a firebaseui.getLocale() which inspectswindow.navigator.languages and map the browser locale to a matching FirebaseUI locale. If implemented this way, Firebase UI can just work by auto selecting the language.

Workarounds …

Okay so I can kinda patch this up by inspecting window.navigator.languages, then creating a mapping function to convert real browser locales to the different ones provided by Firebase UI and do a dynamic load from the CDN of the language specific build.

I now need to build just RTL and non-RTL versions of my index.html file since I cannot (currently) dynamically load CSS files with webpack.

Reference

• Browser Locales
• Firebase UI Locales

Postlude

I’ve now had a closer look at how you’re doing i18n and I see that you’re using Angular’s 18n that forces you to do per language SDK builds. I still think you need a way to lazy loading the language build based on browser locale. My SPA framework assists with this restriction so i can workaround this.