Talk:Hyphen

For the other uses

For the other uses section, I always thought it was em dash, not en dash. Speling12345 (talk) 1:16, 18 December 2013 (UTC)

Nope, en dash is correct. But the "more proper" assertion was wrong. I fixed that section and provided a cross-ref to the main discussion of that topic. "The hyphen and en dash are often used to express number ranges (see details at Dash > En dash > Ranges of values)." Quercus solaris (talk) 03:12, 18 December 2013 (UTC)

So it is en dash. What correction did you make in the page? Speling12345 (talk) 3:17, 18 December 2013 (UTC)

I added the sentence (with cross-ref) quoted above. You can click this link to see the edit diff. Cheers, Quercus solaris (talk) 03:27, 18 December 2013 (UTC)

Do you use hyphens in abbreviations? Would you, e.g. write TEM-grid or TEM grid?

Do you always/normally/rarely write hyphens between abbreviations and words they are conjucted to? As in the given example (a grind for transmission electron microscopy), is it a TEM-grid or a TEM grid ?--Polis Tyrol (talk) 16:27, 15 January 2014 (UTC)

I would default to normal hyphen rules, treating the TEM as any other word. So TEM grid used as a noun has no hyphen by in "TEM-grid holder" used as an adjective it would (though it's often omitted if the meaning is judged to be clear enough to the intended audience). Not "TEM grid-holder" as some do. Dicklyon (talk) 16:33, 15 January 2014 (UTC)

Deleted unsourced thing probably sourceable

This was removed:

The ISO date format sorts correctly using a default collation, which can be useful in many computing situations including for filenames, so many computer systems and IT technicians have switched to this method. The government of the Commonwealth of Massachusetts, for example, has switched to this method.

I suspect it's easily sourceable, if anyone cares. I think the collation point is useful, but the Mass. one is not.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:42, 16 March 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Hyphen. Please take a moment to review my edit. You may add {{cbignore}} after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether, but should be used as a last resort. I made the following changes:

• Attempted to fix sourcing for http://www.uhv.edu/ac/newsletters/writing/grammartip2004.11.30.htm

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 06:45, 30 March 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Hyphen. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20141120120157/http://www.tlg.uci.edu/~opoudjis/unicode/punctuation.html to http://www.tlg.uci.edu/~opoudjis/unicode/punctuation.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 12:45, 21 July 2016 (UTC)

Examples.

Disregard

 – Off-topic.

I like reading a concise article that's not cluttered up with useless data. Some examples to see how to use these tools would be nice. 50.64.119.38 (talk) 06:32, 2 November 2017 (UTC)

You appear to be posting to the wrong page. This is the talk page for an article on a punctuation mark, and has nothing to do with tools or with reduction of data clutter.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  11:32, 2 November 2017 (UTC)

Thank you for pointing that out. I followed a link from WP:MOS that offered more info. i had assumed it was on editing, not the history of the hyphen. I'm sorry if I seemed to be whining or anything and for wasting your time. 50.64.119.38 (talk) 14:46, 3 November 2017 (UTC)

Not at all, you just didn't seem to be at the right place. I think what you want is Wikipedia talk:Manual of Style, if you mean "on editing" at Wikipedia. If you mean to ask a question about editing in general and how to use hyphens, try WP:Reference desk/Language.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:45, 4 November 2017 (UTC)

Don't confuse...except when they are

"Although hyphens are not to be confused with en dashes and minus signs, there are some overlaps in usage (in which either a hyphen or an en dash may be acceptable, depending on user preference; discussed below) and in character encoding (which often uses the same character, called a "hyphen-minus", to represent both the hyphen and minus sign entities; discussed below)." Don't know about anyone else but that seems to say "don't confuse these with those, except when you do because they're the same thing." Personally, I laugh at all the distinctions people try to draw between these floating straight lines. Nobody writes them all distinctly different on a consistent basis and virtually no typeface makes them easily distinguishable. Just admit that the same character can have different usages. --Khajidha (talk) 16:35, 28 November 2017 (UTC)

קו מפריד hebrew

this article is connected to the wrong article in the hebrew wiki. 129.69.140.138 (talk) 12:20, 30 October 2018 (UTC)

The hyphen-minus character is also often used when specifying command-line options.

I propose to delete the paragraph beginning "The hyphen-minus character is also often used when ..." from the "hyphen-minus" section in this article, as it is too far off topic for an article about hyphen and runs into wp:Fork. Comments? --John Maynard Friedman (talk) 09:19, 3 July 2020 (UTC)

I agree. I have never heard somebody use the word "hyphen" when discussing command line options, so it is an unrelated subject to "hyphen".Spitzak (talk) 19:33, 6 July 2020 (UTC)

ASCII and Unicode hyphens꞉ The Unicode Standard seems disingenuous

According to the section "Dashes and Hyphens" on pages 263 –265 in Chapter 6 of The Unicode Standard:

U+2010 hyphen represents the hyphen as found in words such as "left-to-right" ... When typesetting text, U+2010 hyphen is preferred over U+002D hyphen-minus.

The section is nicely typeset with full justification. In the entire section, however, including the phrase "left-to-right", the hyphens are all ASCII hyphens, i.e., in Unicode terminology, hyphen-minuses.

In the Wikipedia section Hyphen § Hyphen-minuses I have flagged with {{cn}} both the claim that U+2010 is the form "used in professional type-setting" and the related claim that "wherever optimal typography is desired, the formal hyphen ... should be used". I suppose that I could replace the latter {{cn}} by a citation to the phrase I quote above from the Unicode Standard as to what is "preferred" but, given that the Standard does not observe its own recommendation, the claim is rather dubious. Poking around in passages from professional journals available online, I have yet to find a Unicode hyphen (U+2010), so the earlier {{cn}} stands.

Of course, one cannot tell which hyphen is used in printed matter. In online text, I can copy a hyphen, paste it into Wordpad, and use Alt+X to determine the code point.

Peter Brown (talk) 23:50, 20 December 2020 (UTC)

John Maynard Friedman has suggested that "disingenuous" is too strong a word — that it would be better to attribute a "cock-up", a blunder, to The Unicode Standard. Perhaps "disingenuous" is too strong, but "blunder" is definitely too weak; this is not on a par with Dominic Cummings's March 2020 visit to Durham which got Cummings into trouble but set no standard.

The Unicode Standard, on the other hand, is a standard. Keith Houston, for example, concurs: in The Secret Life of Punctuation, Symbols, & Other Typographical Marks (© 2013), he calls the ASCII hyphen "an ugly chimera called the hyphen-minus—a hyphenated hyphen, no less" . Only the Unicode hyphen, he maintains, "is properly considered a hyphen."

I object to the disparagement of the ASCII hyphen which, so far as I can determine, is universally used in The Unicode Standard and in other work available online. I therefore think that the hyphen article needs to be revised. The statement in the article that the Unicode hyphen is common in professional type-setting is incorrect and needs revision, as is the statement that it should be used "wherever optimal typography is desired".

Of course, per WP:NEUTRAL, Wikipedia must "represent fairly, proportionately, and, as far as possible, without editorial bias, all the significant views that have been published by reliable sources on a topic." This includes the view of Houston and The Unicode Standard. What I really want is a reliable source that promotes, or at least defends, the use of the ASCII hyphen in work published online. Is anybody reading this aware of such a source?

Peter Brown (talk) 18:52, 21 December 2020 (UTC)

Jukka Korpela, in a personal communication, concurs "that the Unicode Standard does not follow its own recommendations" and adds that his own web page "Dashes and hyphens" also does not. He continues, "I will edit it to point this out, but I need some time to review the page, as it is somewhat dusty. ... People just don’t use HYPHEN. There is not much to be gained by using it ..."

Once he does this edit, I will be able to use the revised page as a source.

Peter Brown (talk) 00:02, 28 December 2020 (UTC)

Done. I have edited the Hyphen-minus article. Peter Brown (talk) 18:27, 30 December 2020 (UTC)

confusion between dash and hyphen in Unicode?

What is this quote from the article supposed to mean?:

U+2010 ‐ HYPHEN (HTML &#8208; · &dash;, &hyphen;)

--Espoo (talk) 07:50, 8 April 2021 (UTC)

There is no real confusion in Unicode, though it may be that there is a confusion or compromise in HTML. Unicode has a code-point for an unambiguous hyphen symbol, ‐, at 2010₁₆. This was uniquely specified such as to be distinct from U+002D - HYPHEN-MINUS (aka the keyboard dash/minus/hyphen) and U+2212 − MINUS SIGN (&minus;). The first HTML mnemonic form, ‐ just uses the formal Unicode name. The second form, ‐, looks like a compromise: "we need a generic dash, which is not an mdash or an ndash, so let's just repurpose the hyphen". (That is not an actual quote, just speculation. Actual facts would be welcome.)

(I'm assuming that you haven't been misled by the output of {{unichar}}? The symbol after the U+nnnn is the symbol in question, not just a gesture. Compare U+0040 @ COMMERCIAL AT (&commat;).)

Or have I completely misunderstood the point of your question? --John Maynard Friedman (talk) 10:05, 8 April 2021 (UTC)

Yes, you understood my confusion correctly. Your speculation sounds logical and reasonable. Let's hope we can find some source so we can add an explanation why it's called both a hyphen and a dash in html. In any case we should change the coding of {{unichar|2010... to produce first and not second what is the more logical or at least more unicode-conform html code and what you also call the first form, ‐.

The dot in the middle of the line and the comma after ‐ are also weird and confusing.

Does the soft hyphen produce the same symbol as U+2010 when it's visible? And why does {{unichar|2010... produce what looks like this hyphen - produced by a smartphone keyboard but copied produces this short underline ‐ that looks like the smartphone keyboard's hyphen once this wikitext is published? --Espoo (talk) 17:03, 8 April 2021 (UTC)

You would need to go to template talk:unichar to make your broader point. Most uses of {{unichar}} with the html option produce just the decimal value of the hex (&#8208; for 2010); the ones most people see only have one html mnemonic form, just a few have two names. I notice in this article, in the section on dictionaries, the interpunct (·) is used similarly.

I suspect there is a clue to the history of this one in the preceding discussion: nobody uses this hyphen in the real world so it was 'fair game'. The problem with hyphen-minus is its ambiguity. If I write 2001-2010, do I mean "minus nine" or do I mean ten years (inclusive)? Of course I should write that as 2001{{ndash}}2010, but if I knew to use &ndash; then why would I bother to write &dash;? So it wouldn't surprise me if nobody uses &dash; either.

No, soft hyphen has its own codepoint, U+00AD SOFT HYPHEN (&shy;). Your confusion here is between (a) the source code (where would specify lots of soft hyphens if wanted very tight justification no matter how narrow or wide the receiving screen) and (b) its interpretation by the web-browser, which 'knows' the window size and tells the OS what to display. It is not really useful to say whether or not it becomes a hard hyphen. The technical term is "sub-architectural", always a good one to use when a hand-waving explanation runs into the sand. :-D --John Maynard Friedman (talk) 22:15, 8 April 2021 (UTC)

Why does Unicode call the ASCII hyphen the "hyphen-minus"?

@John Maynard Friedman: You have removed "As the same character is used as a minus sign in applications like Microsoft Excel" as being the reason for the hyphen-minus being thus named, writing that this is unsupported "and redundant in any case". Unsupported I grant; a {{cn}} would have been appropriate, but why redundant? Where else in the article text is any reason given for this nomenclature? If you know of another reason, please provide it rather than deleting the obvious explanation.

Peter Brown (talk) 18:56, 9 December 2021 (UTC)

@Peter M. Brown: So shall I say "As the same character was used to hyphenate displays in Times Square ..."? If not, why not? It seems to me that the Excel claim is almost as wild a speculation and has no place in the article, even as a place holder. It doesn't even merit a {{dubious}}. The history of Unicode just about predates that of Excel. If the claim had been for Visicalc or Lotus 123, I might just about have suspended disbelief.

It is indisputable that the same symbol was widely used for any and all of hyphen, minus and n-dash (twice for m-dash): it is far more credible that the Unicode Consortium simply recognised the facts on the ground. Most computer users at the time were using terminals attached to mainframes, personal computers were an expensive luxury. At that time, the symbol was probably used far more often as a minus than as a hyphen.

So yes, I accept that a citation is needed for the provenance of the name but let's not muddy the waters with fairy-tales. Far better to start with a clean slate.

(As for redundancy, I meant that it is not essential information in the section where it was. Yes, it is needed, just not there.)--John Maynard Friedman (talk) 20:24, 9 December 2021 (UTC)

The Unicode 1.0 specification, chapter 3.2: symbols, says this (p. 75): "In many cases, current standards include generic characters for punctuation instead of the more precisely specified characters used in printing. Examples include … dash …. The Unicode standard includes these generic characters, but also encodes the unambiguous characters independently: … em-dash, en-dash, minus, hyphen …". It also elaborates on the ambiguity of hyphen-minus on page 76, noting that hyphen-minus and figure dash should be treated as a minus sign in equations and as a hyphen in other contexts. So, I think the Excel claim is silly, but it does seem to be intended for compatibility with existing ambiguous uses. --Pokechu22 (talk) 20:44, 9 December 2021 (UTC)

Thank you, that was what I was looking for. Yes of course it was intended for compatibility with existing uses but to say the excel was the justification is, as you say, just silly. So we just need to write some words on the provenance. I'll see what I can do. --John Maynard Friedman (talk) 20:54, 9 December 2021 (UTC)

Page 30 of https://www.unicode.org/versions/Unicode1.0.0/ch03_1.pdf says

Loose vs. Precise Semantics. Some ASCII characters have multiple uses, either through ambiguity in the original standards or through accumulated reinterpretations of a limited codeset. For example, 27 hex is defined in ANSI X3.4 as apostrophe (closing single quotation mark; acute accent), and 2D hex as hyphen minus. In general, the Unicode standard provides the same interpretation for the equivalent code values, without adding to or subtracting from their semantics. The Unicode standard supplies unambiguous codes elsewhere for the most useful particular interpretations of these ASCII values; the corresponding unambiguous characters are cross-referenced in the character names list for this block. In a few cases, the Unicode standard indicates the generic interpretation of an ASCII code in the name of the corresponding Unicode character, for example U+0027 is APOSTROPHE-QUOTE'.

So we have a citation but it would be good to track back to the primary source (ANSI X3.4). Mañana unless anyone wants to do it in UTC+08:00 time zone (overnight my time, UTC+00:00). --John Maynard Friedman (talk) 23:25, 9 December 2021 (UTC)

It was I who introduced the mention of Excel. The context was "applications like Excel", which I expected the reader to understand, as Excel is prominent these days. Back in the 1970s, I was programming in COBOL, and of course I used the ASCII hyphen as a minus sign, but it didn't occur to me, in this day and age, to write of "applications like COBOL" as no one uses COBOL for development any more. Pokechu22 writes that "the Excel claim" is silly, but neither I nor anyone else has claimed that Excel was involved in the genesis of Unicode, if that is what is meant.

Peter Brown (talk) 23:50, 9 December 2021 (UTC)

(edit conflict) I found ANSI X.34-1977 (as FIPS 1-2, PDF warning); on page 8, it is labeled as "Hyphen (Minus)". Other research suggests some names were changed in the later ANSI X.34-1986 revision, to conform to ISO 646-1983, but I'm having trouble finding details on this. --Pokechu22 (talk) 23:55, 9 December 2021 (UTC)

So it looks like just another misunderstanding caused, I think, by trying to get three concepts into one sentence: what happened, why (practically) it happened, and the context for it happening. The reference to Excel was intended to respond to just the last of these. The 'what' and the 'why' belong in the hyphen-minus article, we don't need a fork here. As for the context, do we actually need anything more than the current Nevertheless, in many spreadsheet and programming applications the hyphen-minus must be typed to indicate subtraction, as use of the Unicode minus sign will produce an error.? If anyone thinks it needs more, feel free.

[Come to think of it, should that sentence be revised to read Nevertheless, in many spreadsheet and programming applications the hyphen-minus must be typed to indicate subtraction, since these applications do not generally recognise the Unicode minus as a subtraction operator and its use will produce an error. or am I being too pedantic?] --John Maynard Friedman (talk) 12:14, 10 December 2021 (UTC)

Partial revert of a discussion of the soft hyphen

In this edit, Beland undid some changes I had made to the section Soft and hard hyphens. I am undoing these changes, but not others made in the same edit, and not changes made in a subsequent edit.

In particular, I used single quotes around a letters to refer to the letter itself; these were changed to double quotes, and I have changed them back. I find nothing relevant in either MOS:QUOTE or WP:QUOTE. My choice of single quotes accords with the note in Use-mention distinction that

If quotation marks are used, it is sometimes customary to distinguish between the quotation marks used for speech and those used for mentioned words, with double quotes in one place and single in the other

though my concern is with letters mentioned, not words. I do think that the use of single quotes scans better. I also changed "ſ" to 'ſ ', not only replacing double quotes by single but also inserting a narrow no-break space between the character and the quote so that the top of the character does not get lost when it is followed by a quote. Finally, instead of referring to "a round s, 's' " I enlarged the character between the single quotes slightly, so the phrase reads "a round s, 's' ". I think making the quoted character a bit larger in this context reduces potential confusion. Peter Brown (talk) 03:34, 9 January 2023 (UTC)

Hmm, that's an interesting tidbit on Use–mention distinction. MOS:DOUBLE doesn't have an exception for use-mention differentiation, but I don't think it applies here anyway, because both the letters and words are being mentioned, not used? And come to think, if "prinſesſen" and variations are in Norwegian, they should be in italics using {{lang}}, which would let us use italics vs. double quotes for words vs. letters. Does that make sense? I thought the Manual of Style had guidance for individual letters somewhere, but I couldn't put my finger on it. -- Beland (talk) 05:37, 9 January 2023 (UTC)

Forgot to @Peter M. Brown: -- Beland (talk) 22:50, 12 January 2023 (UTC)

Section heads: BRD

user:7e8y made a bold edit and has twice been reverted by different editors. The WP:BRD process exists to tease out misunderstandings and reach consensus. Revert wars do no credit to any of the participants. So let's use this talk page to resolve the question.

In yet another counter-revert, 7e8y argues that

• WP:TERSE says “be concise” and MOS:HEADINGS/MOS:AT: use “Early life” not “In early life”, or worst 'Uses/Usages/Events in early life', ...

That is a very selective reading. MOS:AT has nothing to say on this topic, MOS:HEADINGS says

• Not redundantly refer back to the subject of the article, e.g., Early life, not Smith's early life or His early life.

which is an entirely different point and not obviously relevant to this discussion. The MOS is referring to cases where the section is about his early life, that it is Smith's life we are talking about may be taken as read. In this case, the essential question we have to answer is, in the phrase Usage in Computing, which is the key word? To me, in this context, it is "usage" and not "computing" because the section is about how a hyphen is used; it is not about computing.

By the way, "use" and "usage" are not synonyms, although so confused in modern usage ("utilization" [yuck]) as to have become used as such. 𝕁𝕄𝔽 (talk) 10:11, 17 April 2023 (UTC)

Hi John Maynard Friedman, please consider that I had never read Wikipedia:Edit warring (i.e. I was not aware about the 'three-revert rule', Wikipedia meaning of 'editor war', etc.).

Use in English/computing vs. English/computing (alone). I justified my last revert (version 1150285860) with: WP:TERSE says "be concise" and MOS:HEADINGS/MOS:AT: use "Early life" not "In early life", or worst 'Uses/Usages/Events in early life', we understand like 'Unicode' not 'Unicode code-points'; you are just claiming a ‘personal preference’ and refusing to comply with; fine by me, no need for an editor war; I just remove 'origin' as ridiculously redundant and useless, harmonise term: ‘use’/‘usage’; I hope we are on the same page now).

I think you agree with 'WP:TERSE says "be concise"'. But you disagree with: 'MOS:HEADINGS/MOS:AT: use “Early life” not “In early life”, or worst 'Uses/Usages/Events in early life', we understand like "Unicode" not "Unicode code-points"'. Unfortunately you picked the wrong advice/sentence (above) in the Wikipedia guidelines, i.e. which is in the section that MOS:HEADINGS links to. Actually, I made a synthesis of MOS:HEADINGS/MOS:AT; MOS:HEADINGS says "Section headings should generally follow the guidance for article titles (above)" – i.e. MOS:AT; MOS:AT says "Normally use nouns or noun phrases: Early life, not In early life". Nonetheless, at the end of this sentence there is a note in a {{efn}} template saying such construct is acceptable rather in titles or in possibly confusing headings. So looks like 'Computing' as heading seems better that 'Use in Computing'. Besides in scientific writing Lindsay (2011) says that 'specificity' prevails over 'clarity'; thus 'Use in computing' seems a better choice. But headings are exceptions, and 'clarity' prevails over 'specificity'; thus again 'Computing' (alone) becomes a better choice. Maybe the best illustration of this exception is what Heard (2016) calls the "IMRaD [Introduction, Methods, Results and Discussion] canon". Here 'clarity' extremely prevails over 'specificity'; we have headings with single and standard/generic words, and readers have a rough idea of what they will find inside each section. In fact Wikipedia guidelines seems complying with the advice of experienced scientists.

So 'English/Computing' or 'Unicode' (example in my edit summary above) seems better than 'Use in English/computing' or 'Unicode code-points' (example in my edit summary above). Note that, my last edit was a partial revert in which I did accept what I believed to be 'personal preference' (though I did not really agree with your justification, i.e. 'The words "Use of" are critical'); I let the "Use of" – see last revert/version 1150285860... So I am not sure that investing more energy on this already agreed/closed issue is wholesome... What do you think?7e8y (talk) 16:23, 17 April 2023 (UTC)

I'm happy to let the article stand as it is now and consider the discussion closed. Honour is preserved on all sides. --𝕁𝕄𝔽 (talk) 15:15, 18 April 2023 (UTC)

Yes, of course; you take good care of this Wikipedia's entry/article, so you have to be comfortable with its content. Besides, I had already guessed your feeling/affect. Thus I have reintroduced the "Use in", and I (too) briefly wrote "fine by me" in the edit summary;-). The main problem was that you legitimately thought I was cheating on you (since you picked a wrong sentence in the Wikipedia guidelines). Cheating on people is unacceptable. Fortunately, we know now this was just a misunderstanding; case closed!-) 7e8y (talk) 10:06, 19 April 2023 (UTC)

Usage vs. use.

I do not really understand your proposition/statement... First, there is no heading: 'Usage in computing' before or after my edits – see 1149985970 and 1150285860. Secondly, there was a heading: 'Usage in date notation' before my edits – see 1149985970 that I replaced by 'Use in date notation' – see 1150285860. Unfortunately the paragraphs in the section 'Usage/Use in date notation' did/do not use a single time the term 'usage' but did/do use 7 times the term 'use'. The first paragraph even started/starts with "Use of hyphens to delineate"... So once again, for the sake of clarity, I just harmonised the heading with the most appropriate term (which seemed to be 'use' for me). In scientific writing, you learn to always use the same term for not confusing the readers. Finally Cambridge University Press (2023)'s defines usage as: "the way a particular word in a language, or a language in general, is used", and use as: "one of the meanings of a word, or the way that a particular word is used". Therefore, I am not sure that discussing too much the difference between 'usage' and 'use' is wholesome... However, I think that the heading should use one single/unique term. So, what do you intend to do?7e8y (talk) 16:23, 17 April 2023 (UTC)

Look up use or usage in Wiktionary, the free dictionary.

As I'm on mobile now, I'll answer the easy one first and respond to the main issue later, when I have a big screen. My reference to the use/usage question is more an off-topic remark that the distinction has been lost. In this context, I consider that "usage" is the appropriate word but I suspect that most (US?) readers would see it as archaic, less so in the UK. So I don't propose to pursue the point. I agree that consistency is more important. But I draw the line at "utilize" --𝕁𝕄𝔽 (talk) 17:40, 17 April 2023 (UTC)

I Have This to Ask About Justification and Line-Wrapping

Regarding what is stated on the "Justification and Line-Wrapping" section of this article: What about the words whose first, or last, syllables are literally just a single letter (like, for example, vowels or something)? How are they split between two lines? Do we wait until those words' second syllables? Has there ever been any evidence of this situation? Jim856796 (talk) 04:50, 26 November 2023 (UTC)

As the article says, :Rules (or guidelines) for correct hyphenation vary between languages, and may be complex, and they can interact with other orthographic and typesetting practices. Hyphenation algorithms, when employed in concert with dictionaries, are sufficient for all but the most formal texts. So you will need to find a specialist text to answer edge condition questions like yours. WP:NOTMANUAL applies, I'm afraid. 𝕁𝕄𝔽 (talk) 09:50, 26 November 2023 (UTC)

but if you take a word like associate, I have never seen it hyphenated as a-ssociate. It just looks horrible.

I don't know if he covers this detail but I recommend Bringhurst, Robert (2004). The elements of typographic style (third ed.). Hartley & Marks. ISBN 978-0-88179-206-5.. You can borrow it from the open library at archive.org. He will also advise you not to Capitalise Every Word In Headings. 𝕁𝕄𝔽 (talk) 10:11, 26 November 2023 (UTC)

The article also uses rather conditional language on purpose – "it is sometimes preferable to break a word into two", "The word may be divided at the nearest break point between syllables", "Rules ... can interact with other orthographic and typesetting practices." (emphasis added) – because actual practice is going to vary. There is no "official rules of English usage" authority. There are various works that advise against a "hanging" single character either at the end or the beginning of a line (like this one and the aforementioned The Elements of Typographic Style), and various hyphenation algorithms in software will or will not account for this. We don't have any reliably sourced information on the prevalence of this, or which ones do or don't, so Wikipedia doesn't have anything to say on the matter. Wikipedia (including its article talk pages) is not a forum for asking English-language usage advice.  — SMcCandlish ☏ ¢ 😼  04:44, 27 November 2023 (UTC)

"Unicode hyphen"

I have copyedited the lead to de-emphasise (deemphasise? deëmphasise?) the WP:UNDUE prominence of the "Unicode hyphen". Most visitors to this article are interested in orthography, hyphenation rules (like what to do about de-emphaise ) and word-splitting at line endings. The fact that Unicode has encoded an explicit hyphen and an explicit minus as optional alternatives to the hypen-minus is really on the margins, of interest only to computer people. Likewise, the infobox should say "Hyphen" because that is the subject of the article; the article is not about the Unicode hyphen – indeed it was barely mentioned it until I added a very brief sub-section (subsection?) for it.

Which codepoint to use in the infobox is again a detail: if someone desperately wants to change the mark= to a hyphen-minus, go ahead as far as I am concerned – 99.99% of readers will not notice, still less care. But a purist will change it back. 𝕁𝕄𝔽 (talk) 13:56, 7 March 2024 (UTC)