Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update format customizations handling #332

Merged
merged 3 commits into from Nov 12, 2021
Merged

Update format customizations handling #332

merged 3 commits into from Nov 12, 2021

Conversation

cdubz
Copy link
Member

@cdubz cdubz commented Nov 11, 2021

@Amith211 馃憢 -- I'd appreciate your feedback on this branch. This moves the format handling to middleware because there seems to be no agreeable way to make this work with format modules.

Re: the 12h vs. 24h display -- Django's default formats for en-GB actually use 12h format. The USE_24_HOUR_TIME_FORMAT setting needs to be implemented per-locale when overriding the defaults. Do you think that should be necessary here? I'm not sure what the standard is in the UK but I'd be surprised if Django's defaults are not the norm.

Fixes #324.

@cdubz cdubz temporarily deployed to babybuddy-pr-332 November 11, 2021 04:31 Inactive
@cdubz cdubz added bug Reports of unexpected problems or errors i18n/L10n Issues relating to internationalization and/or localization labels Nov 11, 2021
Not sure why this is so damn finicky!
@cdubz cdubz temporarily deployed to babybuddy-pr-332 November 11, 2021 04:38 Inactive
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.02%) to 98.472% when pulling 28fe6ab on 324-en-gb-datetimes into 4b884fd on master.

@cdubz
Copy link
Member Author

cdubz commented Nov 12, 2021

I'm pretty confident in this approach so I'll move it forward (want to move a 1.9.1 release but not with the en-GB unhappiness). Will address any issues in further tickets.

@cdubz cdubz merged commit d74f35d into master Nov 12, 2021
@cdubz cdubz deleted the 324-en-gb-datetimes branch November 12, 2021 18:13
@cdubz cdubz added this to the v1.9.1 milestone Nov 12, 2021
@Amith211
Copy link
Contributor

@cdubz Apologies, I didn't get a chance to have a look the other day.

I'm not familiar enough with Python/Django to make any strong comments regarding implementation; I mainly using c#. For my understanding, would the overrides follow the same partern here, requiring a update_{locale}_date_formats() function to implement USE_24_HOUR_TIME_FORMAT for that lang?

I'll open a new issue to address the 24h format for en_GB. The short version is that for en_GB USE_24_HOUR_TIME_FORMAT needs to be implemented as this would be the expected format when shown on a digital display for most, if not all, Brits.

@cdubz
Copy link
Member Author

cdubz commented Nov 12, 2021

No worries! I'm just antsy for a release (:

So yeah for customizing a particular locale you could pretty much follow exactly what was done for "en_US" in this PR. I figured 24H time made more sense for y'all and I find it very odd that Django doesn't use that as its own format default for en-GB.

@Amith211
Copy link
Contributor

Amith211 commented Nov 12, 2021

Yeah, odd they don't seem to follow the 'modern' standard, 12h is more common in spoken communication (this would be said as 'three in the morning/afternoon' rather than 'AM/PM'), but not for written communication, especially when formal or digital. I'll see you over at #333 so I don't get confused :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Reports of unexpected problems or errors i18n/L10n Issues relating to internationalization and/or localization
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Custom en date formats interfere with en-GB language
3 participants