Consider alternative names for the I18n class

[colinrotherham]

What

As a team we're not sure if our I18n "Internationalisation" class is fully-featured enough to carry the name. The class does most of what we need but (knowingly) lacks various features we may need in the future.

Do we need a new name? We should investigate

Why

These features were noted as not supported during the original spike:

#2614 [DO NOT MERGE] Internationalisation support

• Alternative grammar forms, gendered forms, or switching strings based on an arbitrary context.
• Bi-directional (Bidi) text strings (mixing left-to-right and right-to-left strings) without munging up formatting.

We're also aware of things like:

The list of languages currently supported is pretty much arbitrary, and ones we don't need to support can be removed.

Is that a problem?

Who needs to work on this

Developers, Content Designers

Who needs to review this

Developers, Content Designers

Done when

• New name decided (or not)
• New name applied in code

[romaricpascal]

How about Messages or is it too basic? This focuses the role of that class on giving you access to messages more than its internationalisation capacities.

[36degrees]

As we're making the I18n class private (see #2927) I'm not too fussed about resolving this before we ship v4.4.0 as we can change the name without it being a breaking change.

Obviously if we were planning on making it public at some point we'd want to revisit this first.

With that in mind are we happy to take this out of the v4.4.0 milestone and push this conversation down the line a bit?

[colinrotherham]

I'm happy with the "private + same name" combo 👍

Consider it considered, or rename it to Consider making the I18n class public?

As in, once we're happy it's stable and well documented

[romaricpascal]

Sounds good to leave it on the side for now and revisit when/if we make the API public at some point in the future. No need to hold up 4.4.0 for an internal name 😄

[romaricpascal]

That said, the i18n name also appears publicly in the API when you're setting the content of messages, so we may be stuck with that name for a while:

<div ... data-i18n.charactersUnderLimit="...." ...>...</div>

new CharacterCount($element, {
   i18n: {
      charactersUnderLimit: ...
      ...
   }
   ...
})

[querkmachine]

My vague bullet-point thoughts on potential names.

• i18n — The one that (obviously) made most sense to me, as this is a function that explicitly adds internationalisation to Frontend, and wraps/polyfills multiple aspects of JavaScript's own Internationalization API. Conversely might be an overly jargon-ish name.
• intl — Same as above, however Intl is the namespace used by the JS Internationalization API, so using it introduces potential conflict issues.
• l10n — Maybe more technically correct, as we're actually prompting users for localisation strings, not 'internationalisation' strings. However l10n seems to be a less widely recognised abbreviation and the exact distinction between i18n and l10n isn't well recognised.
• messages — Worry that this might lead users to think it's intended for arbitrarily changing strings, which I don't think we want to encourage them to do except for localisation purposes.
• translation — Easily understood and might make more sense when it comes to naming Nunjucks parameters and data-* attributes but potentially confusing in code ("the translation class takes translations through the translations parameter...")

[36degrees]

Have removed from the milestone and will close this in favour of adding a note to #2977 to re-consider the name before making it public.