Automate locale selection for dashboard users

[agjohnson]

Currently users can select localization manually, but perhaps we could automate this feature.

A less aggressive version of this would be to give the user the English translation and provide a notification to "Switch to Spanish" to match the Accept-Language header provided by the browser.

A more aggressive version of this is to do the opposite, and automatically give the user the locale that they specify in their browser, and provide an easy button to "Switch to English".

The language selector will always still be there however. So this could be manually controlled via the dropdown as well.

For folks on the team that are not english native speakers, what sort of preference would you have here? (Let's assume our UI is fully localized and up to date :grimacing: )

[astrojuanlu]

I have the locale of my browser in English 😅 I only use Spanish for government sites, buying trains in the national railway company, and stuff like that.

I think the language should be chosen from the browser locale, while giving the user the choice to switch.

[stsewd]

For folks on the team that are not english native speakers, what sort of preference would you have here? (Let's assume our UI is fully localized and up to date grimacing )

Same as Juanlu, I have everything set to english on my browser/OS/etc/. I have seen sites that make this change based on my IP too (don't like this). So, for me, it would be option 1, default to english and then ask the user (only once per session) if they want to switch. Also, that option is kind of better for us since our translation are never up-to-date with every release we do.

[humitos]

Same as the others 😄

However, I would go one step forward to what @stsewd said and save the user's preference into the user's profile. There is no need to select the language preference each time that the user logs in. We should save it in our db and give them the ability to change it from their preferences.

[agjohnson]

Haha yeah, as it usually goes, I figured the theoretical use of localization doesn't quite match the real world use of localization.

It seems there was a missed third option, and that is: if the provided Accept-Language header provided by the client is not English -- though we probably expect the user to use English regardless of their native language -- then ... switch automatically to the requested locale and give a notification to switch back to English?

Maybe to pile on more conditional logic, we shouldn't automatically switch to locales below a threshold of completed translation?

I agree with @humitos that this should be a user setting. It's a session setting now, if you know to find the language dropdown way down in the footer.

[agjohnson]

To sprinkle a pinch of data on this dish, here's Oct 2021 dashboard views by what I can only assume is locale requested by the browser (though knowing Google it's probably also some creepier data collection point):

So, lots of english locales. We have or could have pretty good localization in simplified chinese and portuguese, indonesian though, didn't expect that.

[agjohnson]

Thinking about this more, I'm don't know we have the data to prioritize this. We don't know what percentage of those locales are switching their language, and it's most likely a fairly small percentage of users.

If 25% of zh-cn clients are using localized UI, that's 4k pageviews a month. Not trivial, but hard to prioritize anything major just yet.

The two smallest steps possible here are to emit a log line when the language is switched, if we aren't already, so we have metrics on feature usage, and to make the language selector more prominent in the UI, to promote more usage. We can decide a direction from there, and these two changes are rather minor overall.

From there, we can see if it would be helpful to automate and move the setting to be a user settings instead of a session setting. Or, the numbers don't support us working much more on features here yet.

[astrojuanlu]

The two smallest steps possible here are to emit a log line when the language is switched, if we aren't already, so we have metrics on feature usage, and to make the language selector more prominent in the UI, to promote more usage.

+1!

[humitos]

We are using Django's internal function on the language selector: https://docs.djangoproject.com/en/3.2/topics/i18n/translation/#django.views.i18n.set_language. If we want to log something we may need to write a wrapper for that since it doesn't trigger a signal or something we can hook to log that line.