[zbraniecki]

We have been talking about this problem a bit. The tension here is that UX mocks a particular locale as "pixel perfect" and doesn't really "care" about how it'll i18n into other locales.

So they want "do the right thing" for 103 out of 104 locales, but "do what I told you" for "MY" locale.

This is a bit of a conundrum because we don't want to treat any locale as "special". To translate it to code you'd write something like:

  if (currentLocale == "THE_ONE_UX_CREATED_MOCKS_FOR") {
    let value = formatToUXProvidedPattern(data);
  } else {
    let value = data.toLocaleString(currentLocale);
  }

I don't have a great answer how to approach it since there are severe drawbacks and risks to all known potential approaches to "squeeze just one particular format that UX provided into i18n database", but I just wanted to say that we're aware that Intl API has the clash with the UX-driven-development.

[arvinsim]

I think the problem is that design teams don't bake in internationalization when it is not explicitly asked for. It used to be the same thing for responsive pages.

[felixfbecker]

Design tools are also severely lacking here. Even modern tools like Figma have no way to manage copy well (e.g. swap out copy for different "sets" of strings to test the design with variable-length translations). Heck, you can't even use the spell checker or Grammarly on text boxes or comments despite it being a browser-based app.