Problem/Motivation

The Drupal user interface should use a UTF-8 ellipsis character instead of "..." strings to signify the omission from speech or writing of a word or words that are superfluous or able to be understood from contextual clues, or a set of dots indicating such an omission.

It has also been noted in discussion that parts of the user interface would benefit from improved legibility and aesthetics by removing many existing "..." instances and replacing with a single "."

Proposed resolution

Remove superfluous "..." instances. Update relevant policies to reflect the decision to introduce ellipsis characters formally then roll a patch.

Remaining tasks

Need a command to search for the instances that should be changed.

Done

User interface changes

All "..." strings in the user interface that could appropriately be replaces with an ellipsis character will be replaced.

API changes

None

Original report by @m3avrck

Just as the title suggests, this patch replaces all '...' in core with their proper ellipse character. This is used sporadically in core (for example in pager.inc) and this patch just fixes the rest of core to be consistent. Plus the ellipse character looks more sexy than 3 periods in a row ;-)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ixis.dylan’s picture

I'm seeing "â€" in your patch. Shouldn't that be "…" or "…", or is this some unicode weirdness?

ixis.dylan’s picture

Err. I meant:

…
…
…
m3avrck’s picture

No, that weird character is actually correct :-) And no, we shouldn't use HTML entities as explained by Steven (the UTF guru) here: http://drupal.org/node/44498#comment-65823

If you apply the patch and then load up Drupal in your browser everything will look great. Reason you see weird characters is that depending on your editor, you may or may not be in UTF mode.

Morbus Iff’s picture

I disagree with this patch, but it's hard for me to say why. i see the "proper ellipses character" as equivalent to asking Drupal to support curly quotes on all it's output that contains quote (a lot). Or a proper emdash. And so on. -1.

Gerhard Killesreiter’s picture

I am all for nice typography, so I +1 this patch. However, I also believe that all output should be themable. That is, we need a theme_ellipsis function which should default to a proper ellipsis.

m3avrck’s picture

Why not? Already some of these in core (like pager.inc) and it just makes things look better, not to mention it improves semantics. It doesn't *interfere* with anything. Something wrong with more aesthetically pleasing and better semantic output? Note this only fixing things that are hardcoded, obviously user input is another case and different scope.

As for the curly quotes, that is another issue, that is purely aesthetic, quote verse another style quote. The ellipses issue is for semantics, 3 periods != an ellipse, different characters used, although they might look the same. As screen readers and other accessbility tools become more powerful, I'm quite sure they'll be able to make this distinction, if they don't already. 3 periods could come up as 3 empty sentences, while an actual ellipse character that comes up has meaning. Sure you could program it either way, but why not just be semantically correct from the start?

Just trying to make core more semantically correct, feel free to set to 'wont fix' or whatever you like.

m3avrck’s picture

@killes, do we really need a theme_ellipses()? It seems like overkill to me, why would you want to override this or what would you set it to? Seems like we might need theme_quotes() or theme_em_dash() to? Hmm... interesting, themable typography functions....

Gerhard Killesreiter’s picture

Maybe a theme function is wrong. Maybe it should be wrapped in t()? I have no idea if ellipsis is used say in Chinese.

m3avrck’s picture

Hmmm, perhaps t() would work, although as a UTF8 character, I don't see it as being a problem. Maybe our resident UTF8 can chime in, *cough* Steven *cough* ;-)

m3avrck’s picture

FileSize
9.44 KB

Hmm ok after talking with killes on IRC I misunderstood. Yes, I do see the benefits of using t() so any occurces of elllipses can be taken out if that country's language doesn't understand the meaning of the ellipse. As such, that character should be in the a t() string if it isn't already. This patch fixes that situation.

However, I can still see the case for the original patch and *no* t() ... but here are both for debate, hopefully one goes in :-)

ixis.dylan’s picture

I understand the UTF8 situation now, so no arguments about that. However, there seem to be a lot of cases where ellipsis are used without a good reason (unless I don't understand where they should be used, of course).

"Starting updates..."
"more help..."

Do phrases like this deserve an ellipsis? English-speaking people will probably understand what the dots mean, but I think the "standard" usage of ellipsis is to indicate an ommision in a sentence or an incomplete statement. It's a minor point, but if we're taking them seriously enough to replace them with the correct symbols, then perhaps we should ensure that they're necessary in the first place?

Shortening a long URL to "www.domain.com...something.html" or ommiting words from a quote are valid uses, but using ellipsis to indicate a pause at the end of a sentence? I think we should check this first, or we may be making the text less structurally valid.

m3avrck’s picture

@leafish_dylan those are very valid comments.

That is why I introduced the last patch using t() instead. By doing this, countries that don't use ellipses can replace that character with an empty space or a different character and it'll be substituted in. I think this would solve all cases this way.

Morbus Iff’s picture

Quite frankly, "..." (three dots) is wrong, and so is the single character representation. Prenctice Hall's Handbook for Writers Eleventh Edition states that an ellipsis mark is "three spaced periods . . ." and that "for an omission within a sentence, use three spaced periods, leaving a space before and after each period. When the omission comes at the end, use four periods." Likewise, most explanations of what an ellipses is for indicate that it replaces missing words, not that it should be used as "trailing off a thought", which most of our in-core examples of it are implying (as such, I'm for removing ellipses from core as opposed to replacing them with a single character that doesn't visually indicate the space between the periods as required, or supports the spaces before an after the character). Likewise, the Chicago Manual of Style addresses ellipses thusly (while also indicating the correct form of an ellipses): "For manuscripts, inserting an ellipsis character is a workable method, but it is not the preferred method. It is easy enough for a publisher to search for this unique character and replace it with the recommended three periods plus two nonbreaking spaces (. . .)."

I also worry, in a totally unsubstantiated way, that developers who use text editors set to a different, non-utf8 character set, or which doesn't support utf-8 at all, will improperly try to transcode the utf8 mark into something else, which will show up in patches and perhaps accidentally be committed.

killes@www.drop.org’s picture

Now it gets hilarious, where did you get those recommendations from? Style manuals for type writers :-?

Morbus Iff’s picture

ixis.dylan’s picture

I've seen style guidelines that recommend placing the ellipsis in brackets, which makes sense. It's quite common when they're used to strip irrelevant crap out of a quote or shorten a long URL/word. I don't recall ever seeing them spaced out, but Morbus is right (IMO) about removing them. Three dots at the end of a sentence isn't an ellipsis, it's an indication that the reader should either pause or expect more to come.

m3avrck’s picture

Morbus, interesting points, but those apply aptly to the print world, what about the web world? How about this for the print world:

An ellipsis that works perfectly well on your computer may “break” when your text is transferred to another if it comes at the end of a line, with one or more of the dots wrapping around to the next line. To avoid this, learn how to type “non-breaking spaces” between the dots of ellipses: in Word for Windows it’s Control-Shift-Spacebar; on a Mac, it’s Option-Spacebar.

Obviously, this is impossible with HTML, hence the creation of the ellipsis entity, it won't break as a single character.

So where does that leave us? Looks like we have a print verse web issue here. But not only that, take a look at how often ellipses appear in software, from installing various products and such.

Perhaps, what is "literary correct" is not "well accepted" nor "well honored" in the tech world. Maybe that is the real debate here :-)

(ps - you gotta admit Drupal has attracted such a great bunch of developers that we can have an indepth debate about the use of 'ellipses' in core ;-))

Morbus Iff’s picture

Well, obviously, the way to duplicate it is with ". .&nbsp.", and in some of my research earlier today, I saw various documents (nothing official or authoratitive, however, which is why I didn't include them in my previous comment, but the nutshell was a discussion about the ellipsis and emdash, and how misused ellipses were taking the intent away from the emdash) suggesting just that approach. I've found no authoratitive documents suggesting that the single character entity is acceptable however.

Morbus Iff’s picture

Here was the non-authorative I was talking about in the previous message: "The real problem with ellipsis, though, is whether to use three periods (which risks breaking an ellipsis over a line break) or a single-character entity… like … at the end of the preceding phrase. All modern word processors support the latter, and it's also supported in Unicode and extended ASCII. However, that support is (to use the technical term) butt-ugly: it's invariably too narrow in commonly used typefaces. One solution is a "virtual entity," such as . . ., but this causes problems with some browsers (especially for those not using a US-ASCII default). Here's a plea for web-font designers to expand the three-dot ellipsis to a reasonable width, probably two ems (and at least 1.5 ems)." Here, the commenter is complaining that the single entity ellipsis is actually too small to facilitate recognition.

Morbus Iff’s picture

As for "literary correct" vs. the online world, that's an age-old (as old as it could be, at least) debate, ranging from chat rooms, to email, to emoticons and abbreviations. Largely, the opinion is that technology is ruining language and grammar. Hell, I wrote about this back in 1998 - it's certainly not a new argument, and the use of "txting" and cellphones and SMS have only made it worse.

m3avrck’s picture

Morbus, you are correct that the current ellipse entity is indeed to small across many fonts, in most cases it should be at least double or 1.5 it's width as you have mentioned. But, the use of  . .  that won't break across lines? I mean 'non-breaking space' but I never realized that, if that is indeed the case.

Regardless, thanks for the insightful information. This leaves us here:

1. The ellipsis entity is not inherently bad, it is just *too* narrow, correct?
2. Ellipses are wrongly used in my cases

So what to do? I think many places in core they could be removed, but a few they shouldn't. "Making updates..." seems like a valid place, albeit it is technically wrong, it is widely accepted and used on all installers, waiting-type scenarios.

The pager.inc uses ellipses and *correctly* uses them to indicate breaks, or so it seems.

Elsewhere? Perhaps best to just remove them? I wouldn't be against such a patch, as I'm really for *consistency* one way or the other.

Steven’s picture

How it looks is up to font designers, not us. It is semantically correct to use the proper character for it. But personally I've rarely seen spaced ellipses in full text.

As far as ellipsis usage goes, there is the common GUI convention that commands which require more information (and thus pop up a new dialog) end in an ellipsis, e.g. "Save", but "Save as…". This concept is fuzzy on the web though and I don't see how it could be applied to Drupal consistently.

There is also the common (ab)use of ellipsis for processes which take a while (like "Starting updates…", "Uploading file..."). I guess this last usage is wrong, and should be indicated with an animation / throbber / progressbar instead.

m3avrck’s picture

So perhaps we need a patch that fixes the ellipses in core as I have mentioned, take them out in places they aren't needed, and replace any with the possible throbber animation as needed as well?

Would that satisify all situations?

Steven’s picture

All the Ajax uses already have throbbers as far as I know.

Morbus Iff’s picture

Status: Reviewed & tested by the community » Needs work

I'm just not seeing the support and use of this in the wild:

Some further notes:

The two primary goals behind this Issue appear to be a) the single char entity is more semantic, and b) software doesn't know how to parse "..." correctly. Welp, if we change to single char ellipsis for that reason, we simply MUST do the same for quotes -- Unicode distinguishes between starting quotes and ending quotes, 201C: LEFT DOUBLE QUOTATION MARK (“), 201D: RIGHT DOUBLE QUOTATION MARK (”), LEFT SINGLE QUOTATION MARK (‘), 2019: RIGHT SINGLE QUOTATION MARK (’), which is far more semantic when compared to using the same character (") for both starting and ending.

Likewise, we also need to look at our use of dashes in core - in my investigation above, I saw FAR more sites using Unicode's 2014: EM DASH (—) then the ellipsis. As such, we should distinguish against that character, the 2013: EN DASH (–), and the innocent hyphen, and make sure emdashes are properly formatted (per the Chicago Manual of Style, there should be no spaces to the left or right of an emdash)

m3avrck’s picture

Morbus, good examples. So none of them use the ellipse entity, interesting.

As for the quotes and EM and EN dashes, I agree 100%. If we are to fix ellipses, we should fix those as well. Looks like we need a "literary patch" to be made, huh? That would be the best semantically, IMO.

Zen’s picture

FileSize
933 bytes

lol! This is a pretty off-the-beaten-track issue :)

More fuel for the fire: From an ALA discussion [google cache - site doesn't seem to load here]:

Chapped ellipsis

Finally, here are some fine points on the use of the ellipsis (…):

  1. An ellipsis is most often used to indicate one or more missing words in a quotation. It is also used to indicate when a thought or quotation trails off.
  2. When it occurs at the end of a sentence, it should be treated in one of three ways, depending on usage:
    1. If the ellipsis is being used to indicate one or missing words in the sentence, then it should be followed by a period.
    2. If it indicates one or more missing sentences, then it should appear after the period of the preceding sentence, and with a space on either side.
    3. But if it indicates that the thought or quote is just trailing off at the end of a sentence, then only the ellipsis is used, to clarify that no words from a quotation were omitted, as would be the case if the additional period were there.

-K

Zen’s picture

heh, a nice bug - the patch in the last post was an erroneous patch I'd uploaded in preview mode but not submitted over .. 8 hours ago! Please disregard.

Anyways, I'm all for a translatable ellipsis character. +1.

-K

m3avrck’s picture

Status: Needs work » Needs review
FileSize
7.17 KB

After much debate here is a new patch that replaces this with t() and also removes a few unneeded ellipses from core, where other indications should be used, such as "etc."

m3avrck’s picture

FileSize
6.45 KB

Better patch with a few more ellipses removed after talking with Steven.

joe-b’s picture

Since this is a discussion about semantics, might I highlight that an ellipse, which is what is being referred to throughout this facinating discussion, is a regular oval shape, traced by a point moving in a plane so that the sum of its distances from two other points (the foci) is constant, or resulting when a cone is cut by an oblique plane that does not intersect the base.

However, an ellipsis (pl. ellipses) is the omission from speech or writing of a word or words that are superfluous or able to be understood from contextual clues, or a set of dots indicating such an omission.

From one pedant to a bunch of others!

webchick’s picture

Title: Pretty output: replace '...' with proper ellipse character » Pretty output: replace '...' with proper ellipsis character

Good point. Fixing title.

And this is the second most hilarious issue I've ever read (second only to Eaton's trailing slash broadway musical), though I have to say I did learn a lot. ;)

drumm’s picture

Status: Needs review » Needs work

Needs to be updated to HEAD.

catch’s picture

Version: x.y.z » 7.x-dev

bumping version.

keith.smith’s picture

Where has this issue been all my life?

(and subscribe)

Freso’s picture

This is probably one of the most important things to get into D7. Subscribing.

Oh, and also. Just because other websites aren't using … doesn't mean that Drupal shouldn't either. Drupal has a history of being on the "bleeding edge", and while this edge may not be bleeding as much anymore, we'll obviously still be ahead of other sites and software. :p

Garrett Albright’s picture

+1 for proper ellipses in core… yes, and educated quotes. Subscribing.

alexanderpas’s picture

+1 and subscribing

Damien Tournoud’s picture

Title: Pretty output: replace '...' with proper ellipsis character » Pretty output: proper typography for ellipsis, quotes and dashes
Component: theme system » base system
Assigned: m3avrck » Unassigned
Priority: Minor » Normal

So broadening the scope. It is well known that very large scope issues that change everything in one time have a lot more chance to be committed in less than a million years.

sun’s picture

Awesome. subscribing

wretched sinner - saved by grace’s picture

David Latapie’s picture

+1 for a typography filter, a generalisation of this for depending on language (French requires a lot of non breaking spaces, for instance). Please tell if you know of some.

sun’s picture

Version: 7.x-dev » 8.x-dev
Component: base system » user interface text
sun’s picture

Component: user interface text » markup
jzacsh’s picture

+1

Anonymous’s picture

Following on from #39 and #42, how about configurable support for ligatures in the filter?

Not very difficult to implement, would have big "wow" factor for typography geeks, and would impart an subliminal air of subtle sophistication to all Drupal sites.

smscotten’s picture

I like this too, but I'm wondering whether an output filter is the best way to make it happen. I guess that an output filter allows typographic treatments to be translated for different audiences, but the sort of thing I'd like to see is an input filter: when I submit quote marks in text, it gets translated into <q></q> tags and saved into the database, then styled with CSS.

Though as an output filter, this shouldn't be too hard to write as a module outside of core, should it?

Side note: for ligatures, how do alternate ligature characters affect SEO? If I have a site about "waffles" will search engines match that when people search for batter-based cakes cooked on a patterned iron? (Not mentioning the word spelled without ligatures so that I can search and see if I find this page.)

smscotten’s picture

Forget that I suggested an input filter: http://drupal.org/node/263002

If there were a truly compelling argument for an input filter, I might want to poke that hornets' nest, but it's not worth rehashing an old argument for. Sorry.

mikl’s picture

catch’s picture

Title: Pretty output: proper typography for ellipsis, quotes and dashes » Pretty output: proper typography for quotes and dashes
mgifford’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
12.19 KB

This seems like it should be an easy fix … rather than ...

Most folks won't notice, but those who do will notice a lot.

Status: Needs review » Needs work

The last submitted patch, 51: drupal_48-44987-51.patch, failed testing.

mgifford’s picture

Status: Needs work » Needs review
FileSize
11.19 KB

Somehow left SystemMenuBlock.php in there. Removed it in this patch as it was a leftover.

Status: Needs review » Needs work

The last submitted patch, 53: drupal_48-44987-53.patch, failed testing.

mgifford’s picture

Status: Needs work » Needs review
FileSize
14.55 KB

Hopefully this fixes the test.

thedavidmeister’s picture

Title: Pretty output: proper typography for quotes and dashes » Policy then patch: Use the UTF-8 ellipsis character instead of "..." in the user interface
Component: markup » user interface text
Issue summary: View changes
Status: Needs review » Needs work
Issue tags: +policy

Awesome to see that there's a push to improve typography in Drupal, but this thread from 2006 can't be all things to all people.

There's so much going on here:

- Converting triple periods to ellipsis characters
- Discussing an auto-typography function or extending t() somehow
- Dealing with em dashes
- Dealing with left/right quotes
- Removing triple periods from some places in the UI

The scope here is ludicrous and it's sad to see something valuable like typography treated like a second-class discussion. In Drupal core issues that we take seriously, we try to get things done, which means sticking to one goal and if someone has a new great idea, we create a new issue for that. If there are lots of related great ideas, we create a meta issue (a typography meta, anyone?).

Let's bring this right back to what it says in the issue summary (that nobody has updated in 8 years), dealing with ellipsis characters. I wholeheartedly encourage someone to open new issues for each of the points I summarised above.

Since the latest patch touches comments as well as markup, we're looking at a change to policy for both our coding standards and our user interface style guide standards before we try to roll patches or we're just going to make things muddy and inconsistent for ourselves.

I don't see a discussion explaining that replacing periods with ellipses is "correct" in any of these places:

- https://drupal.org/node/604342
- https://drupal.org/style-guide/content
- https://drupal.org/coding-standards
- https://drupal.org/coding-standards/docs
- https://drupal.org/style-guide/typography

I can only presume there is no policy and any patch we commit here without one will be undone by other patches that come after it within 6 months. FWIW, the patch from #55 misses a lot of instances of "..." in the codebase :(

In the interest of reducing the scope, and also DX, and also avoiding inconsistent formatting of comments between 3rd party code and Drupa, I'd suggest we DON'T try to introduce ellipses into code comments and instead focus on interface changes only for this issue.

mgifford’s picture

I can confirm that there are certainly missing "..." that the patch misses when you grep it. Quite a few actually, but mostly in the comments and 3rd party code. I agree we shouldn't bother with changing that.

I'm in favour of moving the policy discussion to a new issue, although having some guidance would be useful for the patch.

There are some interesting comments in #25 when it comes to writing a policy about use of typography characters like this.

Looking for other policies like this, there are examples:
http://wiki.wesnoth.org/Typography_style_guide

Which should include how we deal with spaces http://english.stackexchange.com/questions/91653/space-before-three-dots

There are fun examples here http://www.smashingmagazine.com/2011/08/15/mind-your-en-and-em-dashes-ty...

I'd like to see this done consistently if we can. I do think it is a less important issue though.

I guess it's just part of a good style guide which should also include things like #2256367: Consistently use "website" instead of "web site" in Drupal Core docs and UI text & #950534: [policy] Consistently use "email" instead of "e-mail" in Drupal - both of which would benefit by having a policy document of some sort.

mgifford’s picture

Title: Policy then patch: Use the UTF-8 ellipsis character instead of "..." in the user interface » [policy] Use the UTF-8 ellipsis character instead of "..." in the user interface
thedavidmeister’s picture

I honestly think step 1 might be "write a patch that removes as many ellipsis as possible from the codebase, especially in comments". They're sort of awkward and don't add new meaning or extra information, and has been pointed out earlier they aren't friendly to other languages and so are a barrier to entry for ESL developers.

When we have fewer things to deal with, the policy might be easier to make and uphold.

mgifford’s picture

No problem with opening up a new issue. I thought this is what I'd done in #55 though. Just trying to take a look at removing some.

I'd really like to avoid the problem we've seen with e-mail -> email. This is a trivial change that's been open since 2006. Let's not try to get it perfect. Let's make small incremental moves in this direction and make it a policy so we can slowly eleminate all of them.

This isn't something that really has a huge impact on anything, but it's a simple annoying problem that can be solved.

thedavidmeister’s picture

No problem with opening up a new issue. I thought this is what I'd done in #55 though. Just trying to take a look at removing some.

I'm not saying what you did was wrong or bad. I'm just suggesting we give it a new home with smaller scope. I'm happy to reroll the relevant parts of what you did in #55 and post to the other issue.

I'd really like to avoid the problem we've seen with e-mail -> email. This is a trivial change that's been open since 2006. Let's not try to get it perfect. Let's make small incremental moves in this direction and make it a policy so we can slowly eleminate all of them.

Lol, too late! This issue is from 2006 >.< that's why I'd like to get patches committed by making the scope smaller and focus on things that people are less likely to disagree with philosophically or find other problems with the patch.

thedavidmeister’s picture

@mgifford - I put a patch up at the issue linked in #60 that removes a bunch of "..." (without replacing them with an ellipsis). Found a few more issues to open though.

thedavidmeister’s picture

Opened #2279617: _filter_url_trim() should use Unicode::truncate(), it's along the lines of part of #55.

thedavidmeister’s picture

Issue summary: View changes
thedavidmeister’s picture

thedavidmeister’s picture

thedavidmeister’s picture

mgifford’s picture

This seems like a great approach. Thanks @thedavidmeister!

mgifford’s picture

There's been a lot of progress on this in the last 10 months!

There's a patch that needs a bit of work here #2279105: Remove as many "..." and ellipsis characters from the codebase as possible without altering the meaning of text

We still don't have a good solution for #2279655: Add a way to truncate HTML strings without counting or damaging HTML elements (and use it in Views) - Html::truncate()

We need a policy about using ellipsis characters.

We need to find where else they are being used. But we're way closer than we were a year ago, largely thanks to @thedavidmeister.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Title: [policy] Use the UTF-8 ellipsis character instead of "..." in the user interface » [meta] Use the UTF-8 ellipsis character instead of "..." in the user interface
Category: Task » Plan
Issue summary: View changes
Status: Needs work » Active
Issue tags: -policy

I chatted with benjifisher about this in #ux. He suggested adding the use of the ellipsis to the User Interface text doc in the wiki. I have added a sentence in the Style section.

And I am updating the IS to show that that work is complete. Also, changing this to a Meta to organize the remaining work.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.