Blocks/feature shortcode problem with ellipsis

[chalin]

• For context, @LisaFC isn't sure why we have ellipsis after the "Read more" text in the first place.
• Some (most?) projects don't want the ellipsis

---

PR #1503, as it is written now, causes the url_text and the ui_read_more i18n parameter to be treated inconsistently. I'd rather it be consistent. Two solutions come immediately to mind:

1. Factor out the " …" from the shortcode and move it the value of ui_read_more in the i18n files.
   This has the advantage that it would allow any language to override the ui_read_more text completely, eliminating the ellipsis, if they so choose.
2. Introduce a new argument to the shortcode, say url_text_suffix, that has a default value of " …"

Any other ideas? At the moment I prefer (1).

WDYT @LisaFC @emckean @fekete-robert @deining?

---

Edit: PSC consensus is to drop the ellipsis altogether.

---

• Blocks/feature fix #1503
• CHANGELOG: clarify that blocks/feature no longer adds ellipsis #1848

[fekete-robert]

I think if someone needs the ellipsis it can be included explicitly in the url_text. Otherwise, (2) offers more flexibility IMO.
(Unless we want to combine the two, and have a new argument that defaults to the ui_read_more value from i18n, but that might be an overkill)

[chalin]

Using url_text to control the presence of ellipsis isn't a viable option for multilingual sites.

The more I think about this, the more I'm convinced that the use of ellipsis is locale specific. In that sense, even (2) isn't a good option.

[chalin]

PSC consensus is to drop the ellipsis altogether! \o/
Projects can add it back via i18n config if they so desire.

[chalin]

Closed by #1503