[2012-07-19] Datefield, DatePicker not displayed in the user language

[silverstripe-issues]

created by: otiteca
created at: 2012-07-19
original ticket: http://open.silverstripe.org/ticket/7687

---

For now the Date picker is displayed only in English when using a DateField.

reason:
the jquery i18n language files are not existing in thirdparty folder under framework.

for my personal case, i did want it in French.
What i did to solve the problem:

DateField.php line 470, added a map for fr_FR:

    static $locale_map = array(
        'en_GB' => 'en-GB',
        'en_US' => 'en', 
        'en_NZ' => 'en-GB', 
        'fr_CH' => 'fr-CH',
                'fr_FR' => 'fr',
        'pt_BR' => 'pt-BR',
        'sr_SR' => 'sr-SR',
        'zh_CN' => 'zh-CN',
        'zh_HK' => 'zh-HK',
        'zh_TW' => 'zh-TW',
    );

then into framework/thirdparty/jquery-ui, i

svn co http://jquery-ui.googlecode.com/svn/trunk/ui/i18n/

(I did not find the minified versions).

then I modified DateField.php line 514:

Requirements::javascript(
                    sprintf(
                        THIRDPARTY_DIR . '/jquery-ui/i18n/jquery.ui.datepicker-%s.js',
                        // can be a mix between names (e.g. 'de') and combined locales (e.g. 'zh-TW')
                        $lang
                    ));

this was to point the not minified version i checkout.

[silverstripe-issues]

comment by: otiteca
created at: 2012-07-19

---

I modified the DateField.php class and now it's fully working with i18n support in jquery.
So Datepicker display the calendar in the user language. And the date is valid upon form post.

I attach the modified DateField to this ticket. I keep the ticket open, until one of the contributor push the modified file to the repo.

Olivier

[silverstripe-issues]

comment by: otiteca
created at: 2012-07-20

---

I saw that this issue have been changed from Critical to Medium.
I wonder to know what is Critical issue ?

On my point of view, if you're not applying the changes i posted, Silverstripe is unusable for international users, that uses DataField.

I think that's critical.

[silverstripe-issues]

comment by: @vanlawrence (clawrence)
created at: 2012-07-21

---

Replying to [comment:3 otiteca]:

I saw that this issue have been changed from Critical to Medium.
I wonder to know what is Critical issue ?

On my point of view, if you're not applying the changes i posted, Silverstripe is unusable for international users, that uses DataField.

I think that's critical.

I'll be taking this up with Hamish on Monday, and if he is able I'm sure he'll merge your fix. Thank you for your contribution, please don't think the change in priority is related to the importance of the issue but rather a number of factors, including existing backlog issues, resource management and the fact that the issue you raised had already been solved (by you).

In the future, you might find that your fixes are reviewed much sooner if you submit a pull request.

Thanks for your help and I apologise for any misunderstanding.

[silverstripe-issues]

comment by: @kmayo-ss (kmayo)
created at: 2012-07-24

---

Hi Otiteca,

I have been testing the changes you have made on a fresh SilverStripe install which has been set to French and I have not been able to replicate the fix.
I have created a new page type which uses a datepicker field on the backend and I have pulled the translations from jQuery.

One of the things I noticed is that the changes you made were to Datefield_View_JQuery::onAfterRender which does not actually make any changes to the html that has been passed to it and the Javascript files it adds do not end up in the final page source.

I think I will go over this with a colleague in case there is something that has been missed and will update this ticket accordingly.

Regards Kirk

[silverstripe-issues]

comment by: otiteca
created at: 2012-08-09

---

Sorry to not come back earlier.

To explain, you have to remember that we are talking about a javascript calendar.
So, depending on the parameters that you pass to the jquery calendar it displays differently at runtime.
What i did, is that i fixed the parameters, and added the necessary files, for that calendar to be able to display in the right user language.
From memory, it was missing the locale parameters, and the translation files were missing, plus the path to this translation files was not correct.

so if you did not see the difference using my fix, certainly you forgot to download the date translation files for jquery, which are not part of the 3rd party framework, you guys omitted it.
Let me know if you want us to do a screen share session, for me to demo you the different behavior and the "working" fix.

"working", because there's still an issue for which i opened an ticket for userdefinedform modules, and their date field.
The issue is not coming from their, but from:

• the format use to grab date
• the difference of short date translation between Zend_Date and Jquery calendar

[g4b0]

+1 we also need a localized calendar

[tractorcow]

It might be the case, once we get further to a react-based user interface, that we build a new date picker field that supports custom formats. :D

[chillu]

We'll fix this by simply removing our reliance on jQuery UI, and using built-in browser behaviour for 4.x: #6626