[wp-trac] [WordPress Trac] #33864: Cannot add accented tag if non-accented look-alike exists (eg. szel, szél)

[WordPress Trac]

#33864: Cannot add accented tag if non-accented look-alike exists (eg. szel, szél)
------------------------------------+-----------------------
 Reporter:  geza.miklo              |       Owner:
     Type:  defect (bug)            |      Status:  reopened
 Priority:  normal                  |   Milestone:  4.4
Component:  Taxonomy                |     Version:  4.3
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+-----------------------

Comment (by boonebgorges):

 Thanks for the feedback, pento. Whatever happens here, we'll be sure to
 preserve the proper use of the index.

 I agree with geza.miklo that the current state of affairs is unacceptable.
 Having 'resume' match 'résumé' (etc) is a minor convenience in English,
 but it's debilitating in other languages.

 It's worth noting that the particular issue in this ticket has to do only
 with the 'name' field for terms. There are fairly few places in the
 interface where this value is queried based on user input. I'm thinking
 that the best solution might be something like this: allow `get_term_by(
 'name' )` (and maybe `term_exists()`) to do strict vs loose lookups. When
 checking for the uniqueness of a term - as happens in `wp_insert_term()` -
 the lookup should be strict, so that you can have terms 'szél' and 'szel'.
 But in cases where a person is trying to match a name from the interface -
 namely, the tags autocomplete field - we can do a loose match; typing
 'szel' will return both 'szel' and 'szél'. This would mean something like
 the following:

 {{{
 function get_term_by( $field, $value, $taxonomy, $output, $filter, $match
 = 'loose' ) {
     // ...
     if ( 'strict' === $match && 'name' === $field ) {
         $matches = $wpdb->get_results( 'SELECT ...' );
         foreach ( $matches as $match ) {
             if ( mb_strtolower( $match->name ) === mb_strtolower( $value )
 ) {
                 $term = $match;
                 break;
             }
         }
     }
 }
 }}}

 We'd then identify which uses of `get_term_by()` should be 'strict'
 (probably just the ones used for uniqueness in `wp_insert_term()` and
 `wp_update_term()`, at least for now). All existing uses would remain
 loose, maintaining backward compatibility.

 The only change from current behavior for languages like English will be a
 term with the name 'resume' will not prevent the creation of a term with
 the name 'résumé' on the post edit page. But this seems minor, especially
 since the tag suggest box would return 'résumé' if typed ''sans accent''.

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