Localize lang selectors according to the app language

[Signez]

There are two main things that are not yet translatable in Bluesky's UI:

• Default feed names and descriptions (but this may be a can of worms to open, apart from the specific case of Following);
• Language selectors, in the composer and in the settings screens.

As the second one is quite ironic (don't you think? 🎶) and quite visible on a daily basis, nagging at me as the main translator of Bluesky's app into French with @surfdude29, I thought it would be great to help you out and fix it myself, so you don't have to take time away from your heavy roadmap 😅

---

In this pull request, I use Intl.DisplayName to offer a best-effort translation of the language names, if the browser or target provides it.

⬆️ Here, notice the Français language name. It would show French on main.

Of course, I took the time to fix the same problem in the Languages screen:

⬆️ This screen always offered a translation for the app language, and I don't touch it to help anyone revert an unwanted change of app language settings.

Note: This is a best-effort fix: if Expo's runtime on the mobile apps do not support the Intl.DisplayNames, it will not do anything, and simply show English names as of today.

[auroursa]

I tested Chinese, Japanese and Korean and they work perfect for me👍

[tkusano]

I haven't tested it exhaustively, but I gave it a quick run in Firefox and it looks good. Because Hermes engine ,iOS and Android use, doesn't seem to support Intl.DisplayNames API, polyfilling @formatjs/intl-displaynames might be a option.

[surfdude29]

This is a great idea @Signez 👌

[JoshMLeslie]

Could this be rewritten as a hook, to avoid needing to pass in langPrefs everywhere?
e.g.

export function useLanguageName(language: Language): string {
  const {appLanguage} = useLangPrefs();
  ...
}

[Signez]

As hooks shall not be called conditionally, an hypothetical useLanguageName hook could not be used as-is inside .map calls… where most of the existing calls to codeToLanguageName are done.

So yeah, I am not convinced we would gain readability by using a hook here!

[gaearon]

not gonna do right now but please remind me to look next week

[Signez]

Just rebased on main, pinging you this week @gaearon as you suggested ✨

[Signez]

Rebased on main, with a nasty bug (caught by @c960657) fixed.

[pfrazee]

Nice! My main issue is that, at least in my sim tests, Intl.DisplayNames wasn't available on either android or ios. This only worked for me in my web test. You correctly handle that situation, and I want to go ahead and merge so we make progress. Hopefully that api comes to Hermes someday.

[Signez]

Thanks! It was indeed what @tkusano spotted; they suggested that we could use @formatjs/intl-displaynames (and it would work), but it would be a waste to package it in every installation when there is native APIs that would allow us to use the strings already stored by the system: getDisplayLanguage(Locale locale) on a java.util.Locale on Android, and localizedString(forLanguageCode: string) on Fondation's Locale on iOS.

I thought it would be a good follow-up PR in the future, maybe contributing an Expo package (or an improvement to expo-localization) to offer this to other projects too!