Announcement

Collapse
No announcement yet.
X
Collapse
  • Page of 1
  • Filter
  • Time
Clear All
new posts
Previous template Next
    #1

    Problem with date format in Danish locale

    Hi Isomorphic,

    please see this sample (locale in link) and select Aug, 16th.
    Click image for larger version Name: Danish date format.PNG Views: 120 Size: 30.1 KB ID: 254296

    As you can see, it is dd/MM/yyyy.

    In here (GWT i18n file) it shows:
    Code:
    dateFormats = EEEE 'den' d. MMMM y, d. MMM y, dd/MM/y, [B]dd/MM/yy[/B]
    I know that the sample is JS and is not using GWT, but IMHO it should behave the same. So this seems to be a bug somewhere. I don't care to yy or yyyy, but for the day/month order.
    GWT seems to not include locale permutations. I'm pretty sure it did before. showcase.nocache.js only lists 5 permutations.

    Best regards
    Blama
    Tags: None
    #2
    Hi Isomorphic,

    I just "translated" dateItem_selectorFormat and date_inputFormat in Danish to DMY. Could you please accept my changes and update the translations with the current ones from getlocalization?
    Also, opposed to what I had written here, the translation agency did the remaining French translations in getlocalization as well.

    Best regards
    Blama

    Comment

      #3
      Hi Isomorphic,

      I'm assuming this is the root cause for my original problem. But it is, isn't it?

      Best regards
      Blama

      Comment

        #4
        Yes, that's right - we'll fold your changes into tomorrow's builds.

        Comment

          #5
          Hi Isomorphic,

          this is still current, even though it seems that your changes were applied in smartgwtpower.jar from v11.1p_2018-08-04.

          SmartGwtMessages_da.properties excerpt (as expected):
          Code:
          ...
dateItem_selectorFormat=DMY
...
date_inputFormat=DMY
...
          You can see the same behavior as in the sceenshot also in the sample from #1 (now on v11.1p_2018-08-07).

          So it seems this is related to some other setting.

          Best regards
          Blama

          Comment

            #6
            hmm, yes, we see this - we'll take another look and get back to you shortly.

            Comment

              #7
              This one's been fixed for builds dated August 9 and ;later - the locale-file on getlocalization needed another couple of strings updating - date_short[Date/Datetime]Format - these needed changing from "toUSShortDate/Datetime" to "toEuropeanShortDate/Datetime".

              You can change those entries locally in the Danish locale file if you want to test the fix.

              Comment

                #8
                Hi Isomorphic,

                OK, thanks. I'll wait for the next release containing the changes.

                Another note: I checked date_shortDateFormat, dateItem_selectorFormat and date_inputFormat in the languages relevant to me now: DA, DE, FR, IT, ES, NL.

                Code:
                NL dateItem_selectorFormat is translated to "nul"
DA date_inputFormat is translated to "MDY" (should be DMY, my suggestion is there, but not #1)
                Best regards
                Blama

                Comment

                  #9
                  Also, I read your "Unicode support" section here.

                  It seems that, as your l10n files are also partially used by the server (default server validator messages etc), they should not contain any non-"normal" characters. Is this correct?

                  If so, there might be a problem here, as in all languages, these are mixed:
                  E.g. SmartGwtMessages_da.properties from smartgwtpower.jar from v11.1p_2018-08-04, which includes text like "Ønsker du stadig at fortsætte?"
                  The french file includes both, references like "ic\u00f4ne" and texts like "La ligne nº $firstBadRow était la première à ne pas avoir été analysée.", which includes many language specific characters.

                  Best regards
                  Blama





                  Comment

                    #10
                    With that last comment, it seems like you are speculating that there *may* be a problem. Can you point to a specific scenario where the server uses a specific string from a specific language pack, and the encoding causes a problem where it appears incorrectly in the UI?

                    Comment

                      #11
                      Hi Isomorphic,

                      no, no real problem here for me. I just wanted to let you know that the style here is not consistent in getlocalization.

                      I do use my own properties files from server code though (to get field titles for column names in mails) and here I have to make sure to do the utf8-translation with nativetoascii.exe like you suggest in the docs.
                      It might work without for DataSourceLoader, but as I'm using the same file in a different way, this is necessary for me. But this does not affect your framework properties files.

                      I also saw that you tackled the issues from #8 and the initial issue from #1, thanks.

                      Best regards
                      Blama

                      Comment

                      Previous template Next
                      Working...
                      X