#32875 closed defect (bug) (fixed)
Ellipses instead of ... in UI #2
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.4 | Priority: | normal |
Severity: | minor | Version: | 4.3 |
Component: | Text Changes | Keywords: | has-patch |
Focuses: | Cc: |
Description
We should use ellipses …
/ …
instead of three dots/periods ...
e.g Loading…
not Loading...
This was originally updated in #8714 though since then a few have snuck into the codebase
Getting started with grep: grep -in "\.\.\." src/ -r
This patch isn't 100% accurate based on feedback from @Ocean90 here on Slack:
Looks like
…
works in placeholders too, but not when using $.text(), see http://jsfiddle.net/u241cuy1/1/
Attachments (3)
Change History (34)
This ticket was mentioned in Slack in #polyglots by zodiac1978. View the logs.
9 years ago
#5
@
9 years ago
- Owner set to wonderboymusic
- Resolution set to fixed
- Status changed from new to closed
In 33970:
#6
@
9 years ago
I'm seeing here literal Unicode characters encoded as UTF-8 being committed to the source:
'saving' => __( 'Saving…' ),
When I saw this I was concerned for when another encoding is used for a blog (e.g. Latin1).
Given this test case:
<html> <meta charset="latin1"> <?php $l10n = array( 'updating' => __( 'Updating…' ), ); ?> <p><?php echo $l10n['updating']; ?></p> <script> var l10n = <?php echo wp_json_encode( $l10n ) ?>; document.write( l10n.updating ); </script> </html>
When viewed in my browser, I see the PHP-rendered text being corrupted, whereas the text which was encoded to JSON and written out by JS, succeeded:
Updating… Updating…
This is because json_encode()
does the right thing (by default) to encode characters as Unicode escape sequences, so in the the example above, an ellipsis gets encoded as \u2026
:
var l10n = {"updating":"Updating\u2026"};
So that is why it works. However if wp_json_encode()
gets called with the JSON_UNESCAPED_UNICODE
flag, then this JS example will also come out as mojibake. It looks like the patch is accounting for this by only using UTF-8 encoded characters in strings that will be serialized to JSON, but it's something to be mindful of.
Also, committers will have to be careful to make sure that their editors are configured to use the UTF-8 text encoding, (which should be the default now anyway), or else accidentally re-encode characters in UTF-8 into another encoding.
#7
@
9 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
I thought we had a rule (or at least a habit) of not committing non-ASCII characters, for this reason. It's okay to assume that core committers have their editor encoding set to UTF-8, but we can't really assume that everyone does.
I'm inclined to swap the UTF-8 characters for their \u2026
escape sequence, instead, as @westonruter noted.
#9
in reply to:
↑ 8
@
9 years ago
Replying to wonderboymusic:
netweb is fired
Bwahahaha... Wait a min... I didn'... It was... Meh, I'll take the #blame for the greater good ;P
#11
follow-up:
↓ 14
@
9 years ago
Do we need both strings?
Saving\u2026
Saving…
I am not sure that it is the best solution for translators...
Also see attached screenshot, does not seem good...
#14
in reply to:
↑ 11
@
9 years ago
Replying to pavelevap:
Do we need both strings?
Saving\u2026
Saving…
I am not sure that it is the best solution for translators...
Which is preferred?
#15
@
9 years ago
How will GlotPress handle \u2026
?
And one more hellip input placeholder problem with "Search themes" string...
#16
@
9 years ago
- Owner changed from wonderboymusic to ocean90
- Status changed from reopened to assigned
#17
@
9 years ago
Which is preferred?
I have no preference, but seems unnecessarily to me to have both.
#18
@
9 years ago
Now there will be also other strings:
Search installed themes…
(imput placeholder)
Search installed themes...
(screen reader text)
#20
in reply to:
↑ 19
@
9 years ago
Replying to Viper007Bond:
I'm seeing
\u2026
in some places now. See incoming screenshot.
I see the same for every plugin update.
#21
in reply to:
↑ 13
@
9 years ago
Replying to ocean90:
Replying to wonderboymusic:
In 34013:
Ugh, not sure if this needs some explanation for translators.
Let's please use …
where we can instead of \u2026
, for consistency with the rest of translatable strings.
#23
@
9 years ago
What about adding placeholder with translators comment? Something like Search installed themes%s
? We have also special …
string which can be translated so strings could be also without placeholder (I am not sure about RTL consequences) and …
or …
outside of translatable strings?
#24
@
9 years ago
We are seeing \u2026
in some places because it gets escaped by json_encode()
:
$a = []; $a['save'] = 'Saving\u2026'; $a['save2'] = 'Saving…'; var_dump( json_encode( $a ) ); // string(47) "{"save":"Saving\\u2026","save2":"Saving\u2026"}"
#27
@
9 years ago
How about to add the same inline comment (it was there for a good reason I guess) to all the reverted lines? :)
// (no ellipsis)
32875.diff uses the
…
char for strings used in JS.