Certain date elements are not currently translated

We could try looking into using NumberFormatter for the ordinal, but then we lose the flexibility for users to override the translation to support their specific use case e.g. some clients would prefer to remove the ordinal suffix, or use a custom one instead.

On further investigation, it's actually not as straightforward as I thought as some languages don't support ordinal suffixes, and outright skip them. Using translations using the .po file doesn't accept empty strings as far as I'm aware.

https://en.wikipedia.org/wiki/Ordinal_indicator#Ordinal_dot

The only workaround to enforce the empty string is potentially something like this in your settings.php:

$settings['locale_custom_strings_cy']['date_ordinal_suffix'] = [
  'st' => '',
  'nd' => '',
  'rd' => '',
  'th' => '',
];

The only other option is to introduce a translatable config which users can configure to choose the date format to pass into the date formatter (that way, they can choose to omit S or use a different notation as necessary)

After revisiting #3004425-58: Date formats with abbreviated month name (M) and ordinal suffix are not translated using context → , I believe the best option is to make the day format a config that can be translated by site builders based on the language.

This removes the reliance on core, and provides support for ordinals that might show up before the number rather than after.

Introducing the config allows us to further extend the translations/theming in the future.

This feels like it's adding a lot of code for a use case that hasn't really come up before. I can see the wisdom of using the date formatter service instead of PHP's date function, but I'm inclined to say we should provide a way to call that service within twig and let sites that need more customization can override the provided values by using that service within smart-date-recurring-text-rule.html.twig

The issue is that most sites/modules rarely take translations into account, but there is a use case for it.
I think translations isn't something that should be handled on the templating level (given it's based on the whatever language is active at the time), and is precisely the reason the date_format config property is made to be translatable, and scales a bit better.

The additional code is merely to support the UI translation elements of things (which I feel is the best option for full translation support without reopening future issues), however if you're strongly against the addition of the UI elements, we can have it be a hidden translatable config that can be overridden by the site builder as necessary similar to how $config['image.settings']['allow_insecure_derivatives'] = TRUE; is used in core (the config exists, but there's no native UI to actually enable it).