Uploaded image for project: 'Click'
  1. Click
  2. CLK-650

Load DateField translations from JDK

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 2.2.0
    • Fix Version/s: 2.3.0-M1
    • Component/s: extras
    • Labels:
      None

      Description

      From CLK-624:

      Before we all go ahead and submit translations for month and day names (and abbreviations), I think it would make more sense for DateField to generate these names from here:

      http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormatSymbols.html#getMonths%28%29
      http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormatSymbols.html#getShortMonths%28%29
      http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormatSymbols.html#getWeekdays%28%29
      http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormatSymbols.html#getShortWeekdays%28%29

      By creating the arrays from java's names we will AFAIK also instantly "support" all language so that DateField.SUPPORTTED_LANGUAGES can be removed.

      1. datefield.patch
        4 kB
        Bob Schellink
      2. datefield_no_js.patch
        33 kB
        Finn Bock

        Activity

        Hide
        bckfnn Finn Bock added a comment -

        I have updated the patch, but I'll like to check if it is ok before I commit because it changes the current behaviour.

        The language javascript files in extras/src/META-INF/resources/click/calendar/ have been removed.

        The months and day names are created from java's DateFormatSymbols.

        The week days shown in the popup header, is configured in the DateField_XX.properties, and if not found there the getShortWeekdays() names are used.

        But this changes the default texts shown when we do not have a translation for the browser's locale. If for instance the server is running on a polish Windows (we have a DateField_pl.properties file with weekdays defined) and the browser locale is swedish (we do not have a DateField_sv.properties file) then the week day heading is shown in english right now, but will be in polish with this patch.

        The patch makes popup headers behave consistent with error messages and other translated text.

        For languages where we have a .properties file, but have no .js file, the patch will show translated weekdays instead of english week day headings.

        Show
        bckfnn Finn Bock added a comment - I have updated the patch, but I'll like to check if it is ok before I commit because it changes the current behaviour. The language javascript files in extras/src/META-INF/resources/click/calendar/ have been removed. The months and day names are created from java's DateFormatSymbols. The week days shown in the popup header, is configured in the DateField_XX.properties, and if not found there the getShortWeekdays() names are used. But this changes the default texts shown when we do not have a translation for the browser's locale. If for instance the server is running on a polish Windows (we have a DateField_pl.properties file with weekdays defined) and the browser locale is swedish (we do not have a DateField_sv.properties file) then the week day heading is shown in english right now, but will be in polish with this patch. The patch makes popup headers behave consistent with error messages and other translated text. For languages where we have a .properties file, but have no .js file, the patch will show translated weekdays instead of english week day headings.
        Hide
        sabob Bob Schellink added a comment -

        Thinking a about this today, one of the nice things about using Javascript to localize messages is the translations are externalized into a JS file which gets download once and cached by the browser. The proposed change will "inline" the translations, which becomes part of the page markup. It could have performance impact in a scenario where a page uses a FormTable with multiple datefield columns.

        PS: a bit off topic but we really should try and find a replacement for the DateField Javascript library. The JS popup library is now unmaintained and quite sluggish on IE. It is also tied to the Prototype library which doesn't play nice with other libraries.

        Show
        sabob Bob Schellink added a comment - Thinking a about this today, one of the nice things about using Javascript to localize messages is the translations are externalized into a JS file which gets download once and cached by the browser. The proposed change will "inline" the translations, which becomes part of the page markup. It could have performance impact in a scenario where a page uses a FormTable with multiple datefield columns. PS: a bit off topic but we really should try and find a replacement for the DateField Javascript library. The JS popup library is now unmaintained and quite sluggish on IE. It is also tied to the Prototype library which doesn't play nice with other libraries.
        Hide
        bckfnn Finn Bock added a comment -

        I find it unreasonable to leave translations of day and month names to our users. Including English, we have 10 translations. 5 of them (da, de, fi, fr & pt) are so incorrect that the popup becomes useless.

        Try picking a date in october with a german (de) locale and press Submit:

        http://www.avoka.com/click-examples/form/extra-controls-form.htm

        The field value is "20 Oct 2010" and mesages is:

        Date Field ist ungültig. Das Datums-Format ist dd MMM yyyy

        And for all the languages for which we do not have a .js file, we demand that users must type in english month and day names! I would expect most uses of the DateField to use a number only date format to avoid these issues.

        I suppose we could generate cacheable javascript files with the correct day and month names for each locale with a custom ant task during the build but I find that to be overkill.

        Re. multiple date fields in formtables, then you are right, that is bug in my patch. The translations should only be added to the page once. I'll upload a new patch.

        Show
        bckfnn Finn Bock added a comment - I find it unreasonable to leave translations of day and month names to our users. Including English, we have 10 translations. 5 of them (da, de, fi, fr & pt) are so incorrect that the popup becomes useless. Try picking a date in october with a german (de) locale and press Submit: http://www.avoka.com/click-examples/form/extra-controls-form.htm The field value is "20 Oct 2010" and mesages is: Date Field ist ungültig. Das Datums-Format ist dd MMM yyyy And for all the languages for which we do not have a .js file, we demand that users must type in english month and day names! I would expect most uses of the DateField to use a number only date format to avoid these issues. I suppose we could generate cacheable javascript files with the correct day and month names for each locale with a custom ant task during the build but I find that to be overkill. Re. multiple date fields in formtables, then you are right, that is bug in my patch. The translations should only be added to the page once. I'll upload a new patch.
        Hide
        sabob Bob Schellink added a comment -

        Good points Finn. Think this can go in. We should add a note on the upgrade path about this change as it could affect existing systems, but probably in a good way.

        With regards to the default date format, it is quite easy to change globally in an application page.properties files:

        date-format-pattern=dd/MM/yyyy

        Another optimization we could add is to define static defaults to cut down on the amount of setup options being rendered. For example we only need to render the JS options 'buttons, time, formatValue, and year_range' if the differ from the default value. If you don't have time to add this I'll try and get it done.

        Show
        sabob Bob Schellink added a comment - Good points Finn. Think this can go in. We should add a note on the upgrade path about this change as it could affect existing systems, but probably in a good way. With regards to the default date format, it is quite easy to change globally in an application page.properties files: date-format-pattern=dd/MM/yyyy Another optimization we could add is to define static defaults to cut down on the amount of setup options being rendered. For example we only need to render the JS options 'buttons, time, formatValue, and year_range' if the differ from the default value. If you don't have time to add this I'll try and get it done.
        Hide
        bckfnn Finn Bock added a comment -

        > With regards to the default date format, it is quite easy to change globally in an application page.properties files:
        > date-format-pattern=dd/MM/yyyy

        I would not do that. Of the 135 locales in my jdk1.6, only 32 uses dd/MM/yyyy. It would IMO be better if the default pattern was taken from DateFormat.getDateInstance(MEDIUM) if date-format-pattern is unspecified. That way the default is reasonable and it is possible to override if the locales default is too old-fashioned or cumbersome. However, that is for another JIRA issue and patch.

        Show
        bckfnn Finn Bock added a comment - > With regards to the default date format, it is quite easy to change globally in an application page.properties files: > date-format-pattern=dd/MM/yyyy I would not do that. Of the 135 locales in my jdk1.6, only 32 uses dd/MM/yyyy. It would IMO be better if the default pattern was taken from DateFormat.getDateInstance(MEDIUM) if date-format-pattern is unspecified. That way the default is reasonable and it is possible to override if the locales default is too old-fashioned or cumbersome. However, that is for another JIRA issue and patch.
        Hide
        bckfnn Finn Bock added a comment -

        patch (with fix for multiple date fields) applied.

        Show
        bckfnn Finn Bock added a comment - patch (with fix for multiple date fields) applied.
        Hide
        a_adrian Adrian A. added a comment -

        > patch (with fix for multiple date fields) applied.
        Could you please describe for this "new" DateField what Keys really need to be translated to the various languages cause I see many inconsistencies between keys of the various languages?

        Thank you,
        Adrian.

        Show
        a_adrian Adrian A. added a comment - > patch (with fix for multiple date fields) applied. Could you please describe for this "new" DateField what Keys really need to be translated to the various languages cause I see many inconsistencies between keys of the various languages? Thank you, Adrian.
        Hide
        bckfnn Finn Bock added a comment -

        The keys in DateField.properties are:

        date-title. The title attribute of the input field.
        calendar-image-title. The title attribute of the calendar image icon
        calendar-weekdays-heading. A comma separated list of abbreviated week day names starting with Sunday. The default value is "S,M,T,W,T,F,S". If not defined for a locale, the abbreviated week day names from the JDK is used. The names are used as column heading in the popup.
        calendar-ok. The label on the "OK" button.
        calendar-now. The label on the "Now" button.
        calendar-today. The label on the "Today" button.
        calendar-clear. The label on the "Clear" button.
        date-format-pattern. The pattern

        Show
        bckfnn Finn Bock added a comment - The keys in DateField.properties are: date-title. The title attribute of the input field. calendar-image-title. The title attribute of the calendar image icon calendar-weekdays-heading. A comma separated list of abbreviated week day names starting with Sunday. The default value is "S,M,T,W,T,F,S". If not defined for a locale, the abbreviated week day names from the JDK is used. The names are used as column heading in the popup. calendar-ok. The label on the "OK" button. calendar-now. The label on the "Now" button. calendar-today. The label on the "Today" button. calendar-clear. The label on the "Clear" button. date-format-pattern. The pattern

          People

          • Assignee:
            bckfnn Finn Bock
            Reporter:
            sabob Bob Schellink
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development