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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix hyphen symbol being used instead of the appropriate emdash #4267

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

bunkmate5127
Copy link

The "-" symbol is a hyphen, it serves only a singular purpose: as a hyphen forming hyphenated words, i.e. "mother-in-law".

The correct grammatical symbol in this context is the emdash "—". Lazy folk will often substitute a hyphen with a space on either side into contexts where an emdash should be used.

The "-" symbol is a hyphen, it serves only a singular purpose: as a hyphen forming hyphenated words, i.e. "mother-in-law".

The correct grammatical symbol in this context is the emdash "—". Lazy folk will often substitute a hyphen with a space on either side into contexts where an emdash should be used.
@DogmaDragon
Copy link
Collaborator

From a grammatical point of view, you are correct, but I think it looks ugly.

@bunkmate5127
Copy link
Author

bunkmate5127 commented Nov 7, 2023

The units and the spacing of them is a cluster-fuck as far as I can ascertain. Different UI components have it embedded in them directly instead of having a nice little universal/central helper function for display. Ideally every unit would be separated from its value by a space (i.e. SI compliant). This string is a particular disaster at the moment because it displays like this:

"1Y 2M 3W 4D - 5 TB"

Issues:

  • Units are mixed between having a space and not having a space separating it from their values.
  • The filesize unit should be TiB (already submitted PR).
  • The use of a dash implies "minus" to a lot of folk. Is this negative 5 TB? Are we trying to subtract "5 TB" from "4D"?
  • The lack of a space in the time units implies algebra.
  • The symbols used for the time units are not recognised/standard.

Ideally you have (recognised/popular symbols and SI symbols where available):
"1 a 2 mo 3 weeks 4 d—5 TiB"
or (long-hand unit names):
"1 year 2 months 3 weeks 4 days—5 TiB"

I'd prefer the later, because of lack of all-encompassing standards that recognise all of year, month, week, and day. But these options carry appropriate units/symbols and are grammatically correct (it also looks better, but that's subjective). SI don't recognise weeks and months: months for obvious reasons; weeks I don't know why. SI years are also always Julian (i.e. exactly 365.25 d), which are not cosmologically correct. They're also not even Gregorian (365.2425 d) so e.g. 2100 will not be a Gregorian leap year, but it will be a Julian leap year. The code is calculating neither Julian, nor Gregorian years, (or any other form of cosmological year), instead it's calculating years to be of length 365 days.

Thanks for reading my wall of autism.

@bunkmate5127
Copy link
Author

I just realised the code is calculating months wrong also. It calculates a month to be 30 days, instead of 1/12th of a year.

Won't this result in (e.g.):

0 years 12 months 0 weeks 4 days

before it gets to:

1 year 0 months 0 weeks 0 days

@DingDongSoLong4
Copy link
Collaborator

DingDongSoLong4 commented Nov 7, 2023

This kind of thing is highly subjective, and everyone is of course going to have their own opinion. I have nothing against changes that make the UI more consistent or increase clarity, but I don't think replacing the existing hyphen with an em dash really achieves either in the eyes of the average user.

Personally I also think a dash (em dash) without any surrounding spaces looks horrible – if we're going to use a dash then I'd much prefer an en dash with spaces (which is what I've used in this sentence, and had to copy from Wikipedia because I have no idea how to actually type a dash). This preference for spaced en dashes over em dashes seems to be yet another US/UK English issue: "Dashes have been cited as being treated differently in the US and the UK, with the former preferring the use of an em dash with no additional spacing and the latter preferring a spaced en dash." (from Wikipedia).

The units and the spacing of them is a cluster-fuck as far as I can ascertain. Different UI components have it embedded in them directly instead of having a nice little universal/central helper function for display.

I agree, there are definitely improvements that can be made here. Consistency is something that suffers when you have multiple people each with their own preferences contributing to the same project.

Ideally every unit would be separated from its value by a space (i.e. SI compliant). This string is a particular disaster at the moment because it displays like this:

"1Y 2M 3W 4D - 5 TB"

Issues:

  • Units are mixed between having a space and not having a space separating it from their values.

This I agree with, it is indeed inconsistent. I have no preference regarding spaces/no spaces however.

  • The filesize unit should be TiB (already submitted PR).

This I also agree with - it recently caused some confusion on Discord where someone was comparing macOS's decimal (1000) GB to Stash's binary (1024) GB. Then again, few people actually know about the difference between GiB and GB, but at least those who do won't be receiving conflicting information anymore.

The reason for this is likely because most users (and many Stash contributors) use Windows, which still displays MB/GB/TB despite the fact that they're actually calculated as binary (1024) units.

  • The use of a dash implies "minus" to a lot of folk. Is this negative 5 TB? Are we trying to subtract "5 TB" from "4D"?

While this is technically true, language depends very much on context, and I strongly doubt anyone has been significantly confused by it. Negative storage obviously makes no sense, and I think it's quite clear that it's only a spacer and not any kind of math.

  • The lack of a space in the time units implies algebra.

Again, I believe the context makes it quite clear that they are just units and not some kind of math.

  • The symbols used for the time units are not recognised/standard.
    Ideally you have (recognised/popular symbols and SI symbols where available): "1 a 2 mo 3 weeks 4 d—5 TiB" or (long-hand unit names): "1 year 2 months 3 weeks 4 days—5 TiB"

While the units might not be SI units, I again think it's clear enough and I don't think a user needs to think hard at all to figure out what they mean. I'd argue that the unit a is way more difficult to decipher - nobody really uses the word "annus". I also think the long-hand unit version is a bit cumbersome:

image

This is just too much imo.

SI don't recognise weeks and months: months for obvious reasons; weeks I don't know why. SI years are also always Julian (i.e. exactly 365.25 d), which are not cosmologically correct. They're also not even Gregorian (365.2425 d) so e.g. 2100 will not be a Gregorian leap year, but it will be a Julian leap year. The code is calculating neither Julian, nor Gregorian years, (or any other form of cosmological year), instead it's calculating years to be of length 365 days.

I see the total duration counters as rough estimates rather than precise numbers - knowing that you have exactly 1.2332... years of porn isn't really that useful. It's more so you can say "holy shit, I have over a year of porn!" and then re-evaluate your life decisions. Or just to brag on the Discord server or wherever else.

So essentially I don't think this is really too much of an issue, but fixing it does seem simple enough and I'm not seeing any real downside. Changing the year to be a fractional number of days does make it much more difficult to convert the display into just days, for example (ie 1Y 12D != 377D), but again they're estimates so I don't think that's a real issue.

I just realised the code is calculating months wrong also. It calculates a month to be 30 days, instead of 1/12th of a year.

Won't this result in (e.g.):

0 years 12 months 0 weeks 4 days

before it gets to:

1 year 0 months 0 weeks 0 days

Just checked, and this is indeed the case. I also don't think this is a big problem, but it might as well be fixed along with the year issue.

So yeah, to come back to the em dash issue, I think the current hyphen is perfectly fine, but I understand why you'd want to use a more correct dash. I do much prefer a spaced en dash over an unspaced em dash though.

@AdultSun
Copy link
Contributor

AdultSun commented Nov 7, 2023

As an American myself, we're usually taught to use the longer emdash as a separator with the shorter endash really only used for numerical spans, for example "1–2 years" or "1999–2000". There might be other places within Stash or Stash-Box that would benefit from an endash for those spans instead of the default hyphen, I can't remember and haven't double-checked. Most likely in the performer fields somewhere but the more recent UI update there may have fixed it already.

But ultimately, there's not a lot of consistency in the US either and most people who don't need to know the difference between each dash for school or work probably don't even know there is a difference at all. Depending on the style guide, I've seen the emdash used with spaces around it too — doing it like this is usually my preference as well — and that seems to be a widely accepted alternative. It takes up more space so still might not be preferable within the UI, but it looks cleaner to me than an emdash with no spaces around it.

As for the question about how to type it, I have to use an AutoHotkey script: Alt+- becomes the shorter endash, and Alt+Shift+- becomes the longer emdash.

@bunkmate5127
Copy link
Author

Spaced en dashes are just wrong on so many levels.

  1. "-" is a dash, it's used for hyphenation.
  2. "–" is an endash, it's used for ranges, i.e. "98–99 out of every 100 Americans uses dashes wrong".
  3. "—" is an emdash, it's used for linking two thoughts together, that aren't quite independent enough to warrant different sentences.

No dash should ever have a space around it.

Also, if you're on linux, then you should know about and use the Compose key. I'm surprised it hasn't been copied verbatim into windows yet. I don't know how people live without it.

@DingDongSoLong4
Copy link
Collaborator

DingDongSoLong4 commented Nov 8, 2023

No dash should ever have a space around it.

This statement just isn't universally true. It's like saying the spelling "neighbour" (UK) is always incorrect, and that "neighbor" (US) is the correct spelling.

From the Wikipedia article I linked in my above comment:

Various style guides and national varieties of languages prescribe different guidance on dashes. Dashes have been cited as being treated differently in the US and the UK, with the former preferring the use of an em dash with no additional spacing and the latter preferring a spaced en dash.[37] As examples of the US style, The Chicago Manual of Style and The Publication Manual of the American Psychological Association recommend unspaced em dashes. Style guides outside the US are more variable. For example, The Elements of Typographic Style by Canadian typographer Robert Bringhurst recommends the spaced en dash – like so – and argues that the length and visual magnitude of an em dash "belongs to the padded and corseted aesthetic of Victorian typography".[8] In the United Kingdom, the spaced en dash is the house style for certain major publishers, including the Penguin Group, the Cambridge University Press, and Routledge. However, this convention is not universal. The Oxford Guide to Style (2002, section 5.10.10) acknowledges that the spaced en dash is used by "other British publishers" but states that the Oxford University Press, like "most US publishers", uses the unspaced em dash.

Spaced en dashes are just wrong on so many levels.

  1. "-" is a dash, it's used for hyphenation.

  2. "–" is an endash, it's used for ranges, i.e. "98–99 out of every 100 Americans uses dashes wrong".

  3. "—" is an emdash, it's used for linking two thoughts together, that aren't quite independent enough to warrant different sentences.

If we're going to be pedantic, "-" is not a dash, it's a hyphen, and even more pedantically, that specific character (the one produced by the "-" on your keyboard is called a "hyphen-minus" by Unicode. A hyphen according to Unicode is "‐", which probably uses an identical glyph but is actually a different code point (there's a separate minus sign in Unicode as well "−"). This is all from the same Wikipedia article I mentioned above. That article (and Firefox's spellchecker) also spells en dash and em dash as separate words (i.e. not endash or emdash)

Also, if you're on Linux, then you should know about and use the Compose key. I'm surprised it hasn't been copied verbatim into windows yet. I don't know how people live without it.

I use Linux and macOS, and I'd never heard of the Compose key until I was looking up info about the various dashes for my previous comment. It happens very rarely, but if I ever need to input a character that isn't directly on my keyboard, I usually end up just searching for the symbol online and copying it. Word/LibreOffice also automatically autocorrect hyphens to dashes where necessary, so I don't think about it when using them, and I personally don't care enough to make the effort to use the correct dashes in other programs that don't autocorrect hyphens to dashes.

I do see the value in a Compose key, but I can definitely see how most people (me included) can live without it. Most people just don't need to type alternative characters very often, or ever.

I think it's also relevant to keep in mind what specific area of the UI we're considering here. The hyphen/dash isn't being used to "link two thoughts together", it's being used as a simple visual separator. There's no reason why a pipe "|" wouldn't work just as well, or even a slash "/" (though I think that looks too weird), and they definitely aren't valid punctuation here.

image

@AdultSun
Copy link
Contributor

AdultSun commented Nov 8, 2023

Pipe looks okay to me too. I'd be fine with that, an endash with spaces around it, or an emdash with spaces around it. I really don't have much preference between those three, they all look like clean separators. The current hyphen is probably my least favorite option of the three sizes of dash for this part of the UI, but the emdash with no spaces looks even more awkward.

Having a consistent visual style for these questions throughout the UI would be a more important consideration than one single instance anyways. There's no objectively "correct" answer for any of this, it's just what styling we prefer to use.

@scruffynerf
Copy link

Of the discussed options, the endash would be fine, not the emdash, and definitely not the pipe or slash.

the PR isn't the answer, as far as I can tell.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants