Localization Documentation

[jetpacktuxedo]

I was working on adding Brazilian Portuguese localizations for a labeler, but I'm not sure what language code to use for that. My instinct would be br, but IETF language tags don't split Brazil from Portugal and just uses pt for both. Bluesky uses Portuguese (BR) on the app side:

I wasn't able to find docs anywhere that lists what codes are accepted (or better a mapping of codes to countries), so I'm just kind of guessing right now.

Related, it may be nice to document what language setting needs to be flipped in the app in order to verify that the locales are working. I assume it should be the "Primary Language" setting?

[bnewbold]

The way web language codes usually work is that there is a language group (like en or pt), which are about the language/linguistics. And then regional/cultural localization specifier following it, like en-US (English as spoken in USA) or pt-BR (Portuguese as spoken in Brazil), distinct from pt-PT (Portuguese as spoken in Portugal). The full localization covers things like units (meters vs feet), date formatting, currency, etc.

You can read more about "content negotiation" on the web, using Accept-Language, here: https://en.wikipedia.org/wiki/Content_negotiation

We use content negotiation for the bsky web app, and would presumably do the same for Ozone. I don't know if we have the framework for that set up yet, and have a lot of urgent other work going on, but would certainly be interested in having translations/localization of the Ozone UI in the near future.

[jetpacktuxedo]

Ozone already has a locales block in the label definitions:

  "labelValueDefinitions": [
    {
      "blurs": "none",
      "locales": [
        {
          "lang": "en",
          "name": "Label",
          "description": "A Test Label"
        },
      ],
      "severity": "inform",
      "adultOnly": false,
      "identifier": "label",
      "defaultSetting": "warn"
    }
]

I assumed I should be able to just add a second locale with the right lang value and it should work, but I couldn't find it documebted anywhere and my labeler is currently so rate limited that I haven't been able to actually test it yet, so I've just been operating entirely on assumption so far 😅

[heikadog]

Hi @jetpacktuxedo! My labeller uses localization for Brazilian Portuguese in production, and this is what I was sent by the operator of the SonaSky labeller as an example so I could do it myself:

"locales": [
        {
          "lang": "en",
          "name": "Rabbit",
          "description": "This user is a Rabbit! AKA: bunny, bnuy, bun"
        },
        {
          "lang": "pt-BR",
          "name": "Coelha/Coelho",
          "description": "Este usuário é um Coelho! AKA: Coelho, Coelinho."
        }
]

Here, the lang parameter in the JSON is the language code. You can find a full list of the language codes you can use here, including pt-BR for Brazilian Portuguese: https://github.com/bluesky-social/social-app/blob/main/src/locale/languages.ts#L7C1-L26C3

I do feel like this should be more clearly documented in the ATProto docs or something, though.

[jetpacktuxedo]

Oh perfect, that's exactly what I did, I just wasn't able to tell if it worked or not because I'm still rate limited 😅

[jetpacktuxedo]

It wasn't actually the rate limit that was blocking me, my json just had an extra field on it that I didn't notice and didn't give a visible error but was being rejected somewhere silently 🙈

For future viewers that find this issue, the language used for the localizations is determined by your "app language" setting: