-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[pickers] Add l10n support #4517
Conversation
These are the results for the performance tests:
|
@mnajdova @oliviertassinari I would be interested in your opinion about the theme structure here (see @alexfauquette PR description) Another point : should we drop the prop ( |
The DataGrid has a single entry, the
Yes, I think. In the DataGrid we don't have props to change specific string inside internal components, everything comes from |
Following @m4theushw recommendation, I moved the This allows to update the text as follow:
When a prop for text is not
Also added a page for the localization |
@@ -61,7 +61,7 @@ module.exports = { | |||
parserOptions: { tsconfigRootDir: __dirname, project: ['./tsconfig.json'] }, | |||
}, | |||
{ | |||
files: ['docs/src/pages/components/**/*.js', 'docs/src/pages/components/**/*.tsx'], | |||
files: ['docs/data/**/*.js', 'docs/data/**/*.tsx'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just realized this rule was not applied
@alexfauquette the title still contain |
e07cb43
to
9f5233a
Compare
@flaviendelangle Yes you can review it. Since it is affecting a lot of files, I've redo the commits such as you can review commit by commit |
Truth is, I would delete the current props instead of deprecating them |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
When removing props, I realized I was breaking the action buttons, because they rely on the definition of Need #4655 to be done in order to distinguish the button content and if it should be rendered |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work !
That will be so much cleaner with it
const [locale, setLocale] = React.useState<keyof typeof maskMap>('ru'); | ||
const [value, setValue] = React.useState<Date | null>(new Date()); | ||
|
||
const selectLocale = (newLocale: any) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can probably type it correctly
Create a LocalKey
type type LocalKey = keyof typeof maskMap
and use it both for the state init and here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a copy past from other pages so I created a dedicated issue #4915
|
||
# Pickers - Localization | ||
|
||
<p class="description">Pickers allow to support users from different locales, with formatting, RTL, and localized strings.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<p class="description">Pickers allow to support users from different locales, with formatting, RTL, and localized strings.</p> | |
<p class="description">Date and time pickers allow to support users from different locales, with formatting, RTL, and localized strings.</p> |
The official naming of the project is "Date and time pickers"
I think we can shortcut with "pickers" when inside a page that already clearly scoped the topic.
But for a title / description we should probably be explicit
Same for the title I think
On the Getting Start page we have "Date / Time pickers" which is not great I think (https://mui.com/x/react-date-pickers/getting-started/)
@samuelsycamore I you have a preference
|
||
Localization can impact pickers components rendering in two distincts ways: The date format, and the components attributes such as `aria-label`. | ||
|
||
### Date-engine locale |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a fan a date-engine
but I don't have a better naming
packages/x-date-pickers/src/DesktopDatePicker/DesktopDatePicker.tsx
Outdated
Show resolved
Hide resolved
packages/x-date-pickers/src/LocalizationProvider/LocalizationProvider.tsx
Outdated
Show resolved
Hide resolved
packages/x-date-pickers/src/LocalizationProvider/LocalizationProvider.tsx
Outdated
Show resolved
Hide resolved
packages/x-date-pickers/src/locales/utils/pickersLocaleTextApi.ts
Outdated
Show resolved
Hide resolved
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Fix #4500
new doc page: https://deploy-preview-4517--material-ui-x.netlify.app/x/react-date-pickers/localization/
Initial solution
To support localization we could define an object with
defaultProps
to provide needed translations at all components.I wanted to have something similar to the DataGrid: one file per location. The problem is that we have much more than one component here and it's hard to list for each component which translation key do they need.
In this draft PR What I propose to do is to add a
localText
prop to every component we export and set the default value with theThemeProvider
Another option could be to Create a fake component
'MuiPickers'
of'MuiPickersLocale'
such that components reads default props of both as followCurrent Solution
The
LocalizationProvider
accepts a new prop:localeText
that contains all the translationsComponents that were setting translation by default have now their props deprecated. If no prop is provided, the local text is obtained from
useLocaleText
. All keys are available inenUS
and contributors can add other translationsAbout where the defaults are set:
Works for a follow-up PR
defaultGetClockLabelText
yarn l10n
script for the new files