[DataGrid] Include MUI core component localizations in localeText

[DanailH]

Fix #1107
FIx #1854

I had a thought about how to solve the problem mentioned in the 2 tickets above and I have a possible solution without introducing any duplication and without adding regressions to the way the grid localization currently works.

I added a Breaking Change label because I needed to change some of the types but even with this we still support v5, people can use the localization with the theme and in addition, they can just provide all the localizations through the localeText prop.

The only duplication is that I needed to list the components for which there are localizations in the core (but without any actual values, only their names).

Preview: https://deploy-preview-1913--material-ui-x.netlify.app/components/data-grid/localization/

ToDo:

• Update the Localization docs

[dtassone]

We don't natively use all these components. Why should we add them all?

[oliviertassinari]

One question I would have is, let's say we want to implement Ant Design, as a design specification. How does these change fit?

[DanailH]

We don't, correct but for some of them, it does make sense to have them. Technically we only use the MuiTablePagination so we can only keep that one and add the rest on demand if we happen to use them in the future. The benefit is that that way all the localizations are kept together.

@oliviertassinari regarding the Ant Design - I didn't understand the problem - is it if we use a different pagination component?

Actually, these are only here because the way that the getLocaleText API works is that it throws an error if the key doesn't exist. If that was not the case we woudn't need to keep these here at all.

[m4theushw]

I would keep only MuiTablePagination. If we add all of them it might create doubts for who is doing translations.

[oliviertassinari]

is it if we use a different pagination component?

Different design specs can be supported in different ways. The most likely path (>80%) we will take is that we will expose the same MuiPagination structure, but styled differently. The only thing that we would need to do is to reinject the new components. So we might be able to use the same translation keys, as we would display the same content. (I was initially worried about the coupling of the translation keys, all good)

[oliviertassinari]

It also seems that a large part of the issue was with the lack of documentation on his aspect (the core components). So adding something about it might help. I mean, we likely want to explain that developers have to translate the core components used. And how it works.

[DanailH]

It also seems that a large part of the issue was with the lack of documentation on his aspect (the core components). So adding something about it might help. I mean, we likely want to explain that developers have to translate the core components used. And how it works.

I know what you mean. The thing is that the solution that @m4theushw described here #1854 (comment) is missing from the docs (or at least from the Localization docs). Probably it makes sense to add a section for it.

[oliviertassinari]

the solution that @m4theushw described here #1854 (comment)

@DanailH Not necessarily, what I had in mind is to make sure we have the documentation counterpart of the solution we deploy. Solutions don't have to be source changes only, it could also heavily depends on the documentation.

We have a couple of different options, ranging from:

1. Hide the notion of core components to the developers, have each translation key flat in the locale, no need to update the docs
2. A documentation only fix, explain how the problem can be solved with the componentsProps prop.
3. The hybrid, what we have started to do here. We are partially coupled with the core components, but still get a single place where developers can find all the props that can be translated, updating the docs still seems important.

[DanailH]

@oliviertassinari Understood. I tried to go with 1. but listing the props flat is a problem since we have to respect the typings and more importantly because we support both v4 and v5.

Option 2. is the easiest and would require the least effort.
Option 3. - if we can agree on the implementation of course I will update the docs with what has changed and add examples.

[m4theushw]

We need to revert this line and its v4 counterpart below. If another component from the core is used, it will not get translations.

[oliviertassinari]

@m4theushw It seems that you envision a different solution. This change seems to be OK/aligned with the intent to have all the translations happening inside MuiDataGrid.localeText, even for the core components.

[m4theushw]

I have no problem with appending the core translations into MuiDataGrid.localeText. My point is that if another component from the core (e.g. Alert) is used outside the DataGrid it will not get translations. That's because in the docs we recommend to use the locale from the data-grid package to create the theme. Open this CodeSandbox and note that the standalone TablePagination is not translated.

[DanailH]

I see your worry - I will update the docs to match this implementation. That's why it's marked as a breaking change because you will no longer import all translations from the X package, you would need a mixed solution depending on your case.

[oliviertassinari]

Open this CodeSandbox and note that the standalone TablePagination is not translated.

The table component not translated sounds like the expected behavior, translations do no longer leak.

[m4theushw]

👍

[oliviertassinari]

This type is not correct, we extend any:

1. This should fail: https://codesandbox.io/s/material-demo-forked-d8djr?file=/demo.tsx, it doesn't. Fixed in [DataGrid] Fix localeText type #2117.
2. The tests of [docs] Fix DataTable.tsx demo in v4 material-ui#27196 shouldn't fail, they do. Fixed in [DataGrid] Fix localeText type #2117
3. It allows regressions like [DataGrid] Add missing localeText types #2118