[core] Remove dead translation key

[oliviertassinari]

The key doesn't seem to be used. It was added #15401. I guess we can remove it?

I also wonder:

• if we should we use a // Common structure for the data grid like used for the pickers:

  mui-x/packages/x-date-pickers/src/locales/enUS.ts

  Lines 87 to 88 in 483fc6a

  	// Common
  	empty: 'Empty',

  
  We start to have quite some duplication for clear: x3. https://github.com/search?q=repo%3Amui%2Fmui-x+Clear+path%3A%2F%5Epackages%5C%2Fx-data-grid%5C%2Fsrc%5C%2Fconstants%5C%2F%2F&type=code.

• if we should add translation keys for unstable features. People then tends to create PRs to translate those, but it can be noise until it's stable.

[mui-bot]

Localization writing tips ✍️

Seems you are updating localization 🌍 files.

Thank you for contributing to the localization! 🎉 To make your PR perfect, here is a list of elements to check: ✔️

• Verify if the PR title respects the release format. Here are two examples (depending if you update or add a locale file)

  [l10n] Improve Swedish (sv-SE) locale
  [l10n] Add Danish (da-DK) locale

• Update the documentation of supported locales by running pnpm l10n
• Clean files with pnpm prettier.

Deploy preview: https://deploy-preview-15566--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against be4680d

[MBilalShafi]

I agree with both the points.

1. Having common ones would reduce the need to translate repeating ones like Search, Clear, Reset, etc.
2. Having the translation keys skipped for an unstable feature would control some noise, however we'd need to be a bit more careful to have the translation keys in place when making such a feature stable.

[flaviendelangle]

if we should add translation keys for unstable features. People then tends to create PRs to translate those, but it can be noise until it's stable.

We were discussing last week how to make those new features (that we currenctly mark as experimental or unstable) more appealing in order to have feedbacks.
I fear that not translating those features before they are stable would cause yet another reason not to use those features, making it harder to stabilize them.

[arminmeh]

if we should we use a // Common structure like used in:

in most of the cases this should be fine, but we should be careful with it because you lose context and it can make the word (or its spelling) different in other languages.

example: word Add is in Croatian translated to Zbroji if it is a math operation and Dodaj if it is an action to append an item to the list

[oliviertassinari]

We were discussing last week how to make those new features (that we currenctly mark as experimental or unstable) more appealing in order to have feedbacks.
I fear that not translating those features before they are stable would cause yet another reason not to use those features, making it harder to stabilize them.

@flaviendelangle en-US is 50% of the internet content: https://en.wikipedia.org/wiki/Languages_used_on_the_Internet. Might be similar to our customers/developer users as well. However, if we look at the Internet users by language:

It seems that 10 locales could give us 70% of coverage. (It's almost the Pareto principle here). So for unstable features, maybe we don't need 100 locales, only the top 10? This could be a way:

• change the translation keys to be prefixed with unstable_
• update https://github.com/mui/mui-x/blob/master/scripts/l10n.ts to only output translations for
  • en-US
  • zh-CN
  • es-ES
  • ar-EG
  • pt-BR
  • fr-FR
  • ja-JP
  • ru-RU
  • de-DE

Not super important in any cases.