[wp-trac] [WordPress Trac] #32875: Ellipses instead of ... in UI #2

Wed Sep 9 05:06:59 UTC 2015

#32875: Ellipses instead of ... in UI #2
--------------------------------------+-----------------------------
 Reporter:  netweb                    |       Owner:  wonderboymusic
     Type:  defect (bug)              |      Status:  closed
 Priority:  normal                    |   Milestone:  4.4
Component:  Text Changes              |     Version:  4.3
 Severity:  minor                     |  Resolution:  fixed
 Keywords:  good-first-bug has-patch  |     Focuses:
--------------------------------------+-----------------------------

Comment (by westonruter):

 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:

 {{{#!php
 <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`:

 {{{#!js
 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32875#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform