enUS locale is exported, but as an empty object

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

import { enUS } from '@material-ui/core/locale'

This import gives me an empty object.

Expected Behavior 🤔

To be able to import enUS (default) locale.

Steps to Reproduce 🕹

These steps are most likely not needed, because the locale is commented in the module: https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/locale/index.ts#L300

Context 🔦

I need to support dynamic language change, which seems not to be supported by current MUI localization. Therefore I’d like to import default locale, so I could use it with e.g. react-i18next.

[niklas-heeros]

As mentioned, the issue is when you need to support dynamic language change.

Context 🔦 I need to support dynamic language change, which seems not to be supported by current MUI localization. Therefore I’d like to import default locale, so I could use it with e.g. react-i18next.

If, for example, I set the pagination labels like this:

<TablePagination
  // `t` is from `react-i18next` and has MUI locales imported into `material-ui` namespace
  labelRowsPerPage={t('material-ui:MuiTablePagination.labelRowsPerPage')}
  labelDisplayedRows={t('material-ui:MuiTablePagination.labelDisplayedRows')}
  nextIconButtonText={t('material-ui:MuiTablePagination.nextIconButtonText')}
  backIconButtonText={t('material-ui:MuiTablePagination.backIconButtonText')}
/>

Is there something I’m missing? If there’s out-of-the-box way for doing this in MUI, I would definitely use that.

[o-dubrovskyi]

I believe the question is rhetorical )

As far as I understand the root of the problem is how to use the localization of the mui along with the localization of the application that uses the mui.

I don’t see any problem with this. We can use a separate provider (like https://react.i18next.com/latest/i18nextprovider) to localize application components as SomeOtherComponent.

Also, to customize the enUS locale of the mui components, in the end, it is needed to create a separate localization object. So I think that uncommenting the enUS locale is not necessary