fix(l10n): fix date localization in sub management

[StaberindeZA]

Because

• Subscription management date is localized to en locale, regardless of browser language.
• SecurityEvent created date is not being localized.

This pull request

• Pass FluentDate to Fluent localization libraries to correctly localize dates.
• Add localization string for SecurityEvent created date.

Issue that this pull request solves

Closes: #FXA-7795

Checklist

Put an x in the boxes that apply

• My commit is GPG signed.
• If applicable, I have modified or added tests which pass locally.
• I have added necessary documentation (if appropriate).
• I have verified that my changes render correctly in RTL (if appropriate).

Screenshots (Optional)

Please attach the screenshots of the changes made in case of change in user interface.

Subscription Management

English

German

Settings Security

English

German

Security Events

English

German

[vbudhram]

LGTM 👍🏽

[vpomerleau]

This might be a question for @bcolsson, but wouldn't Fluent handle localization of the date if we passed in a date variable instead of a string?

According to Fluent's documentation :

If the variable passed from the developer is a date and is used in a placeable, FTL will implicitly call a DATETIME function on it.

In most cases, Fluent will automatically select the right formatter for the argument and format it into a given locale.

https://projectfluent.org/fluent/guide/builtins.html

[bcolsson]

I believe that's what the getLocalizedDate function is doing, providing a datetime that can be parsed by fluent:

fxa/packages/fxa-react/lib/utils.tsx

Lines 23 to 57 in be6538e

	/**
	* This method is used to provide Fluent with a localizable value that can be formatted per .ftl file based on localization requirements
	*
	* @param milliseconds
	* @param numericDate
	*/
	export const getLocalizedDate = (
	milliseconds: number,
	dateOptions: LocalizedDateOptions
	): FluentDateTime => {
	let options: Intl.DateTimeFormatOptions | undefined;
	switch (dateOptions) {
	case LocalizedDateOptions.NumericDate:
	options = {
	day: 'numeric',
	month: 'numeric',
	year: 'numeric',
	};
	break;
	case LocalizedDateOptions.NumericDateAndTime:
	options = {
	year: 'numeric',
	month: 'numeric',
	day: 'numeric',
	hour: 'numeric',
	minute: 'numeric',
	};
	break;
	default:
	options = undefined;
	}
	return new FluentDateTime(milliseconds, options);
	};

[vpomerleau]

Right, I see that we're using this to pass localization options with the date.

Equivalent to passing the options in more explicitly, as documented? @bcolsson would it be preferable to expose these options to localizers so they can have visibility on the date formatting? If not like below, then at least in a comment?
today-is = Today is { DATETIME($date, month: "long", year: "numeric", day: "numeric") }

@StaberindeZA this is non-blocking BTW - I'm somewhat hijacking your PR to get more details on how to handle date localization in the future :)

[bcolsson]

In the case of things like correct date and number formatting, typically it is expected that the internationalization layer should handle the correct formatting for each locale without intervention by the linguists.

[bcolsson]

That being said, I see your point regarding how a date is displayed. We could definitely add a comment if you wanted to include how it appears.