Defaults for days of week too short - should be 3 letters, Mon, Tue,

[httpete]

Please remember, the issues forum is NOT for support requests. It is for bugs and feature requests only.
Please read https://github.com/ng-bootstrap/ng-bootstrap/blob/master/CONTRIBUTING.md and search
existing issues (both open and closed) prior to opening any new issue and ensure you follow the instructions therein.

Bug description:

By default, the i18n choice for the days of the month from the datepicker is: Mo, Tu, We

It should be Mon, Tue, Wed etc like the old one:

https://angular-ui.github.io/bootstrap/ (search for datepicker)

IT would be an easy fix on your end, the enum Const that stores the i18n length just needs to be Abbreviation not Short.

Overridding it is hard, https://stackoverflow.com/questions/50900233/internationalization-of-datepickers

You can see that in order to change it we have to override that provider with our own.

Link to minimally-working plunker that reproduces the issue:

You can fork a plunker from one of our demos and use it as a starting point.
Please note that we can not act on bug reports without a minimal reproduction scenario in plunker. Here is why:
https://github.com/ng-bootstrap/ng-bootstrap#you-think-youve-found-a-bug

Version of Angular, ng-bootstrap, and Bootstrap:

Angular: All

ng-bootstrap: latest

Bootstrap: no matter

[maxokorokov]

Hey, @httpete !

It should be Mon, Tue, Wed etc like the old one

Well, that's not a valid argument, I say it should be Mo, Tu, We :)

An option would be to change existing:

@Input() showWeekdays: boolean;

to

// 1. change existing input
@Input() showWeekdays: boolean | TranslationWidth;

// 2. introduce a new one and remove existing `showWeekdays`
@Input() weekdays: boolean | TranslationWidth;

// 3. introduce a new one without removing the existing
@Input() weekdayFormat: TranslationWidth;

// 4. introduce it via the injection token
{ provide: NGB_DATEPICKER_WEEKDAY_FORMAT, useValue: TranslationWidth.XXX }

I prefer 2, but 1 is a non-breaking change
1-3 can also be overridden with NgbDatepickerConfig where necessary

[httpete]

Hi Max, yes I was being a little terse but it should be configurable without having to override the provider (although I am learning alot about Angular DI in the process!). Are you saying that ngbDatePickerConfig can do this in one place for our whole app?

[benouat]

Hi all !

If we want to align to Intl.DateTimeFormat, then @httpete is right

For weekday, possible options are narrow (F), short (Fri) and long (Friday)

Do we want to align with this API ? I don't know.
We might also use directly Angular for that. Then, discussion would be over.

[maxokorokov]

@benouat, interesting. We already use Angular internally, and align with what Angular comes with:

export declare enum TranslationWidth {
    Narrow = 0,
    Abbreviated = 1,
    Wide = 2,
    Short = 3,
}

It's just we default to TranslationWidth.Short for no specific reason. In Angular terms short is Fr, not Fri though, as they're mapping this: https://github.com/unicode-cldr/cldr-dates-full/blob/master/main/en/ca-gregorian.json#L105-L141

[httpete]

it would be such an easy fix to align to the standard, but even better if it were configurable.

[benouat]

Closing as we won't introduce a new feature for that, especially that could be worked around by as @maxokorokov suggested by providing this in any component where the datepicker would be used.

// 4. introduce it via the injection token
{ provide: NGB_DATEPICKER_WEEKDAY_FORMAT, useValue: TranslationWidth.Abbreviated }

TranslationWidth.Abbreviated provides that 3 letters translations

https://github.com/unicode-cldr/cldr-dates-full/blob/6227cc013572391189a63350cec2544f0e0b3624/main/en/ca-gregorian.json#L104-L114

[urielzen]

I am having trouble implementing this recommendation

// 4. introduce it via the injection token
{ provide: NGB_DATEPICKER_WEEKDAY_FORMAT, useValue: TranslationWidth.Abbreviated }

Does this apply to the latest version? I cannot find where to import NGB_DATEPICKER_WEEKDAY_FORMAT from.

[maxokorokov]

There was a misunderstanding, I guess. There is no workaround at the moment, so I'll reopen this feature request.