Definitely the former, apologies for making it confusing.
> What is the equivalent of xgettext.pl
There is no standard one, although people build their own.
The general consensus is that source strings should not be inlined into code. The closest analogy is to "style" vs "class" in HTML/CSS - the clean separation of concerns comes from the "id" being the contract.
```
{GENDER, select,
male {He answered}
female {She answered}
other {They answered}
}
```
Fluent:
```
user-answered =
{ $gender ->
[male] He answered.
[female] She answered.
*[other] They answered.
}
```
> How does layering pt_BR on pt_PT work?
MF does not prescribe fallback behavior. It also more popular to treat each locale as "complete" and fill "gaps" at build time. So at runtime you have `pt-BR` which has pt-BR strings and missing ones "completed" from `pt` (parent locale).
Fluent has a "resource manager" (simple one like this: https://github.com/projectfluent/fluent-rs/tree/main/fluent-... or more complex like Mozilla L10nRegistry), which can fallback at runtime, allowing for what we call "partial locales" which can roll out to production with gaps and the resource manager will fetch the fallback strings from the parent locale.
> What is a compelling reason to switch?
If you and your users are happy with gettext, none!
> What is the equivalent of xgettext.pl
There is no standard one, although people build their own. The general consensus is that source strings should not be inlined into code. The closest analogy is to "style" vs "class" in HTML/CSS - the clean separation of concerns comes from the "id" being the contract.
You can read more about it here: https://github.com/projectfluent/fluent/wiki/Fluent-vs-gette...
There are attempts to "merge" those two philosophies, by extracting and "generating" slugs as ids. Examples: - https://formatjs.github.io/docs/getting-started/message-extr... - https://lingui.dev/guides/message-extraction - https://app.studyraid.com/en/read/15768/550728/setting-up-th...
I'm fairly skeptical of this approach.
> the file extension for the main catalog file `.po`
In MF1.0 world, the file format is JSON or XML. You encode id=>Message pairs. In Fluent world there is a Fluent (FTL) file format. In MF2.0 the format itself is, again, message scoped. On top of it there's a proposal by Mozilla to create MessageResource - https://github.com/w3c/i18n-discuss/blob/gh-pages/explainers... and that may feed into DOM L10n - https://github.com/mozilla/explainers/blob/main/dom-localiza...
> the __ function?
see the (1) and links to "generated ids".
> How does gender work (small example)?
MF 1.0:
``` {GENDER, select, male {He answered} female {She answered} other {They answered} } ```
Fluent: ``` user-answered = { $gender -> [male] He answered. [female] She answered. *[other] They answered. } ```
> How does layering pt_BR on pt_PT work?
MF does not prescribe fallback behavior. It also more popular to treat each locale as "complete" and fill "gaps" at build time. So at runtime you have `pt-BR` which has pt-BR strings and missing ones "completed" from `pt` (parent locale).
Fluent has a "resource manager" (simple one like this: https://github.com/projectfluent/fluent-rs/tree/main/fluent-... or more complex like Mozilla L10nRegistry), which can fallback at runtime, allowing for what we call "partial locales" which can roll out to production with gaps and the resource manager will fetch the fallback strings from the parent locale.
> What is a compelling reason to switch?
If you and your users are happy with gettext, none!
If either of those groups complain, there may be many: - https://github.com/projectfluent/fluent/wiki/Fluent-vs-gette...
Hope that helps!