#30400 closed Cleanup/optimization (fixed)
Improve typography of user facing strings.
| Reported by: | Jon Dufresne | Owned by: | Jon Dufresne |
|---|---|---|---|
| Component: | Core (Other) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Inspired by comment: https://code.djangoproject.com/ticket/30399#comment:2
Prefer:
“”for quotes’for contractions—rather than--…rather than...
Change History (12)
comment:1 by , 6 years ago
| Has patch: | set |
|---|---|
| Patch needs improvement: | set |
comment:2 by , 6 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
Agreed, but we have to skip all messages that can appear in a shell output (see #30184).
comment:3 by , 6 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
| Summary: | Improve typography of user facing strings → Improve typography of user facing strings. |
follow-up: 5 comment:4 by , 6 years ago
As for me, #30184 is hopefully not the last word on this issue. Preventing all users from having good typographic output (that is real readability improvements) just because some systems will not make the effort to transition to UTF-8 is not fair.
As we are wrapping those outputs anyway, I think that we should be able to detect the output encoding, and add some ascii simplification/conversion when the output does not support UTF-8.
comment:5 by , 6 years ago
Agreed - It seems a shame that we can't have nice things because the Windows Command Prompt has been neglected for so long.
There is an interesting article on how this is already being fixed, but it will take time until the majority of users do not have a broken command prompt.
I was already looking into sprucing up some of the command output and was considering the exact same possibility of substituting some ASCII alternatives on terminals that do not support UTF-8. Give me a few weeks and I'll resurrect my branch for this to see if there is a possible way forward.
In the meantime, we should stick with the policy of not supporting unicode in shell output.
Also, out of interest, we only support Python 3.6+ for Django 3.0 which includes PEP 528 and PEP 529 and this may mean that issues such as #30184 and #30324 become a thing of the past anyway. I haven't tested this to make sure though, and the ability to disable unicode shell output would be a good idea anyway.
comment:6 by , 6 years ago
+1 there. We should be able to push users forward at this point in history.
Not exactly the same issue but we had a user on Django Dev hitting a unicode error on macOS too, which means they’d set a non-unicode locale (for unknown reason). I feel like we should be able to emit a decent warning in this kind of case linking to a doc explaining what they need to do. (I’ve found myself on servers with broken/primitive locales plenty of times too… similar would help there.)
Anyhow, that’s just emoting at this point.
comment:7 by , 6 years ago
| Patch needs improvement: | unset |
|---|
comment:8 by , 5 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
https://github.com/django/django/pull/11281