[wp-trac] [WordPress Trac] #36843: Wrong Taxonomy Term orderby 'name' in Cyrillic

[WordPress Trac]

#36843: Wrong Taxonomy Term orderby 'name' in Cyrillic
--------------------------+----------------------
 Reporter:  esemlabel     |       Owner:
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Taxonomy      |     Version:  4.5.2
 Severity:  normal        |  Resolution:  invalid
 Keywords:                |     Focuses:
--------------------------+----------------------
Changes (by boonebgorges):

 * status:  new => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


Comment:

 @esemlabel I wasn't trying to say that Ukrainian is the same as Russian,
 or that it's not important for WordPress to get this right :)

 What I'm saying is: WordPress term 'orderby=name' queries tell MySQL to
 `ORDER BY name`. It's up to MySQL to provide data in the right order. It
 makes this decision based on the collation of the `name` column. See
 http://dev.mysql.com/doc/refman/5.7/en/charset-general.html. In your case,
 `utf8_general_ci` is not sufficient to sort Ukrainian (though, as I
 hypothesized, it gets Russian correct, which is why your sort order is
 incorrect in the way that it is). See http://stackoverflow.com/a/766996.

 As noted by @knutsp, the fix in your case is to change the collation for
 the `name` column in your `wp_terms` table, along with any other relevant
 columns in your database. I believe that `utf8_unicode_ci` is the correct
 collation for Ukrainian when using a UTF8 charset.

 > Should WordPress offer to set the correct collation for these DB
 columns?

 WP tries to use sensible defaults (`utf8mb4` and `utf8mb4_unicode_ci`,
 where supported) for the database tables that it creates at installation.
 WordPress 4.3 introduced a routine that upgraded existing tables to
 `utf8mb4`/`utf8mb4_unicode_ci` on sites that support that combination.
 When WP can't do this migration, I don't know that there's enough
 information available to assume that it knows what the "correct" collation
 is for a given installation - it depends on a combination of the current
 charset, what the installation of MySQL supports, and the language(s) that
 need to be supported by the database. So @knutsp, I think the answer is
 "no". But if you think there's a feasible way for WP to do this without
 breaking stuff, let's discuss it in an enhancement ticket.

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