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

Change locale of RangePicker #8635

Closed
GrishaAngelov opened this issue Dec 15, 2017 · 6 comments
Closed

Change locale of RangePicker #8635

GrishaAngelov opened this issue Dec 15, 2017 · 6 comments

Comments

@GrishaAngelov
Copy link

@GrishaAngelov GrishaAngelov commented Dec 15, 2017

Version

3.0.1

Environment

Linux Mint 17, Chrome 63.0.3239.108

Reproduction link

https://codepen.io/anon/pen/aEOrLZ?editors=1010

Steps to reproduce

Provide locale object as prop to <DatePicker.RangePicker>

What is expected?

Locale to be changed and strings in header and footer of RangePicker to be translated to the language in locale object

What is actually happening?

The language is not changed and is still the default one (en)


After some experimenting I found the following thing:
If we open antd/lib/date-picker/wrapPicker.js and change

{
      key: 'render',
      value: function render() {
        return React.createElement(
          _LocaleReceiver2['default'],
          { componentName: 'DatePicker', defaultLocale: this.getDefaultLocale},
          this.renderPicker
        );
      }
    }

to

 {
            key: 'render',
            value: function render() {
              const getLocale = () => this.props.locale

              return React.createElement(
                    _LocaleReceiver2['default'],
                    { componentName: 'DatePicker', defaultLocale: this.props.locale.lang ? getLocale : this.getDefaultLocale},
                    this.renderPicker
                );
            }
        }

then the locale is changed as it should (and if not provided then we have the default one).

So it looks that always is applied the default locale without check for the user defined.
In the previous versions e.g. 2.13.x providing with locale object was enough.
This is my observation, am I missing something ?

@Atala
Copy link

@Atala Atala commented Dec 19, 2017

Hi,

I am under the impression that the fix is not working with antd 3.0.2 (which include
7919d76 ) and the codepen linked above (https://codepen.io/anon/pen/MryzKd?editors=1010 with antd 3.0.2).

Maybe something specific to the RangePicker component.

Thanks for your dedication & great project,

@afc163 afc163 reopened this Dec 20, 2017
@GrishaAngelov
Copy link
Author

@GrishaAngelov GrishaAngelov commented Dec 20, 2017

I have updated antd to 3.0.2 and everything seems to work correct - the strings that have not been translated before now are ok

@Atala
Copy link

@Atala Atala commented Dec 20, 2017

Quite surprised, in my project the translation of the calendar days doesn't seem to work (I am working on the french translation).

It seems the same to me in your Codepen, the calendar days are still not translated (in russian) in 3.0.2 - maybe I am missing something?

capture d ecran 2017-12-20 a 10 01 06

capture d ecran 2017-12-20 a 10 00 50

@yutingzhao1991
Copy link
Contributor

@yutingzhao1991 yutingzhao1991 commented Dec 20, 2017

Part of locale of DatePicker, MonthPicker, RangePicker, WeekPicker is read from value. So, please set the locale of moment correctly.

ref: https://codepen.io/yutingzhao1991/pen/aEZbaB

image

@Atala
Copy link

@Atala Atala commented Dec 20, 2017

Yes indeed I noticed it in the docs, but got confused with this bug + correctly loading the moment locales.

No problem with Antd then.

Thanks for your answer!

@didmehh
Copy link

@didmehh didmehh commented Dec 25, 2017

https://codepen.io/benjycui/pen/KgPZrE?editors=001
if change the locale to zh_CN, it don't work when the second selected.that will change to en

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants