[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search
 
Modify

CLDR Ticket #11152(new data: needs-more-info)

Opened 2 weeks ago

Last modified 6 days ago

Updated Locale data for DateFormatSymbols.getLocalPatternChars()?

Reported by: jasonexe@… Owned by: anybody
Component: datetime Data Locale:
Phase: dsub Review:
Weeks: Data Xpath:
Xref:

Description

Hi, I was recently working on a page on which I would like to add a single text box for a user to enter a date, ie: 01/31/2018. I'd like to show a mask to prompt them to enter it, "DD/MM/YYYY."

However, I could not figure out a standard way to localize the actual letters in this string. Making the order of "DD/MM/YYYY" locale appropriate, as well as the separators, is doable, but there's no built in way I could see to localize the actual letters to, for example, "ي‌ي/ش‌ش/س‌س‌س‌س" in Arabic. The setDateFormatSymbols() method seems to be the way to do this, but the built-in DateFormatSymbols don't cover all locales (for example, Arabic. Also Chinese, Hungarian, and I'm sure many others)

I realize there are other ways to handle doing this - IE: 3 separate dropdown fields where it's clear which segment of a date each contains, or to instead first populate an example date and put "Example: 01/31/2018". However, in my opinion choosing dates from a dropdown isn't as easy as just typing a date, especially if it's a date I can easily recall like my birthday, and it is easier, in my opinion, to mentally parse "MM/DD/YYYY" to a date format than "01/31/2018"

It looks like localized DateStrings were discussed here: https://unicode.org/cldr/trac/ticket/1424 and deprecated, which could maybe be rethought?

To summarize: My ideal flow would be the ability to have this code print a mask that is entirely localized:

String skeleton = "yyyyMMdd";
SimpleDateFormat simpleDateFormat =
    (SimpleDateFormat) DateFormat.getInstanceForSkeleton(skeleton, locale);
DateFormatSymbols symbols = DateFormatSymbols.getInstance(locale);
simpleDateFormat.setDateFormatSymbols(symbols);
System.out.println("Localized pattern: " + simpleDateFormat.toLocalizedPattern());

The current hiccup seems to be with the DateFormatSymbols.getInstance(locale).getLocalPatternChars() not returning translated pattern characters.

Thank you for your time!

Attachments

Change History

comment:1 follow-up: ↓ 2 Changed 11 days ago by mark

  • Cc pedberg added
  • Status changed from new to closed
  • Resolution set to needs-more-info

We used to have localized versions of the characters, but found that they were not used much. As the number of symbols grew (https://unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table), having the translators come up with the different varieties of symbols was onerous (and error prone, especially for non-Latin languages). Moreover, the more sophisticated mechanisms for customizing formats (eg https://www.wikihow.com/Change-the-Date-Format-on-a-Mac) don't really use those special characters.

It sounds like your use case is somewhat different; the user isn't supplying a localized pattern that they expect to have dates formatted with (such as a custom date format in Excel or sheets). Rather, you are just giving the user the indication of what format they are expected to type in. That might be a more scoped feature. The simplest scope would be:

  • only numeric
  • only separate dates and times (not in one string)
  • only year, month, day, hour, minute, second, day-period

In that case we could have basically fields corresponding to:

YYYY
MM
DD

HH
MM
SS
A (am/pm)

Thoughts?

comment:2 in reply to: ↑ 1 Changed 11 days ago by jasonexe@…

Having separate fields seems like it would be a great solution :) would there also be a field for the correct separator (/ - etc)? I'm sure there already is a way to extract the separator from an existing method, but I think an explicit one along with the other fields would be helpful too

Replying to mark:

We used to have localized versions of the characters, but found that they were not used much. As the number of symbols grew (https://unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table), having the translators come up with the different varieties of symbols was onerous (and error prone, especially for non-Latin languages). Moreover, the more sophisticated mechanisms for customizing formats (eg https://www.wikihow.com/Change-the-Date-Format-on-a-Mac) don't really use those special characters.

It sounds like your use case is somewhat different; the user isn't supplying a localized pattern that they expect to have dates formatted with (such as a custom date format in Excel or sheets). Rather, you are just giving the user the indication of what format they are expected to type in. That might be a more scoped feature. The simplest scope would be:

  • only numeric
  • only separate dates and times (not in one string)
  • only year, month, day, hour, minute, second, day-period

In that case we could have basically fields corresponding to:

YYYY
MM
DD

HH
MM
SS
A (am/pm)

Thoughts?

comment:3 Changed 6 days ago by jasonexe@…

  • Status changed from closed to new
View

Add a comment

Modify Ticket

Action
as new
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.