Add Portuguese-PT locale/translations support

[joaomendoncaa]

wip 🫡

[auroursa]

Just a personal suggestion here (I’m not a native Portuguese speaker), for compatibility reasons, I think using pt instead of pt-PT as the language code might be better. This would provide a fallback option for older devices that don’t support pt-PT and pt-BR.

There’s also a practical reason: as part of the localization, we’d need to modify src\components\hooks\dates.ts and add Portuguese (pt-PT) there. But date-fns doesn’t support pt-PT, only pt here, which might cause some complications.

[joaomendoncaa]

Just a personal suggestion here (I’m not a native Portuguese speaker), for compatibility reasons, I think using pt instead of pt-PT as the language code might be better. This would provide a fallback option for older devices that don’t support pt-PT and pt-BR.

There’s also a practical reason: as part of the localization, we’d need to modify src\components\hooks\dates.ts and add Portuguese (pt-PT) there. But date-fns doesn’t support pt-PT, only pt here, which might cause some complications.

Totally. The date formatting also addresses my question above, thank you.

[joaomendoncaa]

@auroursa there's a lot of people involved in this translation, if I edit the top of pt-PT/messages.po to add a reference to all the people who are involved (but not necessarily commiting directly to the tree); will it be overridden at build time by the lingui cli?

[auroursa]

Let's update the remaining pt-PT (but you can still keep "Português (PT)" in the language list).

[auroursa]

@auroursa there's a lot of people involved in this translation, if I edit the top of pt-PT/messages.po to add a reference to all the people who are involved (but not necessarily commiting directly to the tree); will it be overridden at build time by the lingui cli?

Yes, it won’t be overwritten by the lingui cli.

It looks like you’ve updated all the language files. Please specify the language explicitly when running intl:extract:
yarn intl:extract --locale pt

[auroursa]

Apologies, I forgot this step. You’ll also need to rename the src\locale\locales\pt-PT folder to src\locale\locales\pt.

[surfdude29]

I actually think it would be better to mostly specify pt-PT. I may be understanding it wrong, but from what I've read the default region for the pt language code is BR, not PT, so just using pt rather than pt-PT might cause issues?

I read this somewhere else (can't remember where unfortunately) but one place that definitely says it is the Unicode CLDR Likely Subtags list.

edit: It's stated more explicitly here:

Portuguese (Brazil) [pt_BR] is the default content locale for Portuguese [pt]

[auroursa]

I actually think it would be better to mostly specify pt-PT. I may be understanding it wrong, but from what I've read the default region for the pt language code is BR, not PT, so just using pt rather than pt-PT might cause issues?

I read this somewhere else (can't remember where unfortunately) but one place that definitely says it is the Unicode CLDR Likely Subtags list.

edit: It's stated more explicitly here:

Portuguese (Brazil) [pt_BR] is the default content locale for Portuguese [pt]

I am concerned about compatibility with some browsers and older devices. Their language list only includes Portuguese, so it will output pt by default. I’m not sure if the current AppLanguage matching mechanism can handle this situation. If it doesn’t match any regional suffix, it might fall back to English.

I noticed that the Portuguese government website uses both pt and pt-PT, but you are right. I still need to investigate further.

[auroursa]

No, I think in web development, we should use pt instead of pt_PT to represent Portuguese (PT), because the module we use to localize dates date-fns doesn’t have the pt_PT option, and it will cause the date format fallback to English.

[surfdude29]

No, I think in web development, we should use pt instead of pt_PT to represent Portuguese (PT), because the module we use to localize dates date-fns doesn’t have the pt_PT option, and it will cause the date format fallback to English.

I'm not sure that should be a particular issue, for date-fns we can just use pt while using pt-PT elsewhere :)

[auroursa]

No, I think in web development, we should use pt instead of pt_PT to represent Portuguese (PT), because the module we use to localize dates date-fns doesn’t have the pt_PT option, and it will cause the date format fallback to English.

I'm not sure that should be a particular issue, for date-fns we can just use pt while using pt-PT elsewhere :)

Please give me some time to test it. I want to compile it on different platforms and check the results.

[auroursa]

@joaomendoncaa May I ask about your browser language list and mobile language list settings? I want to make sure my settings are correct.

[surfdude29]

Please give me some time to test it. I want to compile it on different platforms and check the results.

Of course, there's no rush :)

I may well be wrong and pt on its own might be the better option, but my gut feeling from all the localization things I've read is that it will generally work better to include a region tag to distinguish between two locales with the same language. (It doesn't apply in the case of English of course because en-US is the universal default 😅)

[joaomendoncaa]

Apologies, I forgot this step. You’ll also need to rename the src\locale\locales\pt-PT folder to src\locale\locales\pt.

This whole process might deserve an update to docs/internationalization.md. It's not everyday bluesky will add a language, but the process is a little quirky.

Let's update the remaining pt-PT (but you can still keep "Português (PT)" in the language list).

Now that I think of it, we might be better off expanding them to Português (Portugal) - Portuguese (Portugal) and Português (Brasil) - Portuguese (Brazil).

May I ask about your browser language list and mobile language list settings? I want to make sure my settings are correct.

I don't know how to view the underlying codes used by my language preferences. I'm seeing different languages on different browsers. Arc even has Portuguese, Portuguese (PT), and Portuguese (BR).

---

Re: pt vs pt_PT, I also believe pt (for the code2 definition) as a "default" is a better option; as far as I'm aware, all i18n implementations recognize pt (and the ones that introduce brazilian pt-BR), but not all of them recognize pt-PT. I'd leave the rest of the codebase as pt-PT to avoid ambiguity, but I can also understand the counter argument of confusion. Since we're on a misstep, I'll wait for @auroursa's decision.

Appreciate all the help.

[auroursa]

Currently need some additional information. could you open your browser developer tools (F12) > Console > and then enter this command: navigator.language I’d like to know which languages are included in its output and their order of priority.

[joaomendoncaa]

Currently need some additional information. could you open your browser developer tools (F12) > Console > and then enter this command: navigator.language I’d like to know which languages are included in its output and their order of priority.

@surfdude29 might be right, pt seems to default to pt-BR on all my browsers (zen + arc) — pt-PT is the outlier

[auroursa]

If I’m mistaken, please forgive me, but I assume you have a local build environment. If you’re willing, could you test both pt and pt-PT under your current browser settings, to see if Bluesky automatically switches to Portuguese on the first load?

It seems to work both on my end, but I’m not sure how it behaves in other browsers (I’m using Firefox).

[auroursa]

I tested pt on both a Galaxy S22 and an Android emulator. When the system language is set to Portuguese (Portugal), it switches to the correct language (as shown in the video), both browsers and Android seem to redirect pt to pt-PT rather than pt-BR.

test.mp4

If it also works correctly in your browser tests, I think this comes down to a matter of personal preference. Either pt or pt-PT should be fine.

[joaomendoncaa]

I tested pt on both a Galaxy S22 and an Android emulator. When the system language is set to Portuguese (Portugal), it switches to the correct language (as shown in the video), both browsers and Android seem to redirect pt to pt-PT rather than pt-BR.

test.mp4
If it also works correctly in your browser tests, I think this comes down to a matter of personal preference. Either pt or pt-PT should be fine.

I don't know why, but I'm not being able to see any language changes in any browser, nor in mobile automatically (when changing the preferred language in settings). I have to manually switch it everytime regardless of what I do. When I do change it manually, it's changing correctly to the desired language.

I think the best option here might just be explicitness (adding the 3 cases, and pointing them explicitly toward one case):

      case 'pt':
        return AppLanguage.pt_BR
      case 'pt-PT':
        return AppLanguage.pt_PT
      case 'pt-BR':
        return AppLanguage.pt_BR

Keeping the cohesion with pt falling back to pt-BR from what we've seen, and being explicit about all options since every device will have one, or more versions of the above.

I promise the people actually doing the translations know more about my own language than I apparently do...

[auroursa]

Okay let’s reset to bf430e9 because the current code is a bit messy…

As you mentioned, we should add a case for pt to pt-BR in helpers.ts to ensure compatibility with older devices. Additionally, we need to make some adjustments in src/components/hooks/dates.fs to allow pt-PT properly utilize date-fns.

dates.fs:

import {
  …
  pt,
  ptBR,
  …
} from 'date-fns/locale'

const locales: Record<AppLanguage, Locale | undefined> = {
  …
  ['pt-PT']: pt,
  ['pt-BR']: ptBR,
  …
}

[joaomendoncaa]

Alright, everything looks good to me. Now the hard part.

[surfdude29]

Would it be possible to add one more change to this PR? If you could add a 'pt-PT', entry to app.config.js here please, that would be great:

social-app/app.config.js

Lines 115 to 116 in 770eeb5

	'pt-BR',
	'ru',

Portuguese is already displayed as a supported language in the App Store listing so it won't make any changes there. However, because both Portuguese (Brazil) and Portuguese (Portugal) are listed as iPhone Languages:

I feel like it's probably best to have specific, separate entries for them both in the CFBundleLocalizations key rather than just one pt entry, to hopefully ensure that the TextInput context menus are translated properly for iOS users who have either locale set as their device language :)

[joaomendoncaa]

Would it be possible to add one more change to this PR? If you could add a 'pt-PT', entry to app.config.js here please, that would be great:

Added all three keys in line with our reasoning above — thank you for the heads up!