Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DataGrid] Include MUI core component localizations in localeText #1913

Merged
merged 9 commits into from
Jun 18, 2021

Conversation

DanailH
Copy link
Member

@DanailH DanailH commented Jun 16, 2021

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

@DanailH DanailH added bug 🐛 Something doesn't work breaking change component: data grid This is the name of the generic UI component, not the React module! labels Jun 16, 2021
@DanailH DanailH self-assigned this Jun 16, 2021
MuiAlert: {},
MuiBreadcrumbs: {},
MuiRating: {},
MuiAutocomplete: {},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member

@oliviertassinari oliviertassinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

DanailH commented Jun 16, 2021

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
Copy link
Member

oliviertassinari commented Jun 16, 2021

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
Copy link
Member Author

DanailH commented Jun 16, 2021

@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.

},
},
...coreTranslations?.components,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

DanailH and others added 2 commits June 18, 2021 16:22
Co-authored-by: Matheus Wichman <matheushw@outlook.com>
Co-authored-by: Matheus Wichman <matheushw@outlook.com>
@DanailH DanailH requested a review from m4theushw June 18, 2021 13:22
Comment on lines +52 to +60
const theme = createMuiTheme(
{
palette: {
primary: { main: '#1976d2' },
},
},
bgBG,
coreBgBG,
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@DanailH DanailH merged commit 04b1149 into mui:master Jun 18, 2021
Comment on lines +1 to +9
import { Localization as CoreLocalization } from '@material-ui/core/locale';

// @ts-expect-error We have different structure in v5
type MuiComponentsLocalization = CoreLocalization['props'] | CoreLocalization['components'];

/**
* Set the types of the texts in the grid.
*/
export interface GridLocaleText {
export interface GridLocaleText extends Partial<MuiComponentsLocalization> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change bug 🐛 Something doesn't work component: data grid This is the name of the generic UI component, not the React module!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[DataGrid] Changing Rows per page localization missing keys [DataGrid] Pagination localization
4 participants