Make WordPress Core

Opened 12 years ago

Closed 11 years ago

#7095 closed defect (bug) (fixed)

Japanese Tag Slugs

Reported by: kiwizz Owned by:
Milestone: 2.7 Priority: high
Severity: major Version: 2.5.1
Component: I18N Keywords: japanese slug localization reporter-feedback
Focuses: Cc:


I know when you type in Japanese Wordpress will change the slug to some encoded link similar to "%e3%83%86%e3%82%b9%e3%83%88" My issue is that the link brings up a page not found error - but not always. the tag テスト has this slug http://blogger-off.com/tag/%e3%83%86%e3%82%b9%e3%83%88/ and that works.

However if I use this tag 天戸中学校 the slug becomes http://blogger-off.com/tag/%e5%a4%a9%e6%88%b8%e4%b8%ad%e5%ad%a6%e6%a0%a1/ and I get a 404 not found error. Also, if I manually change the tag slug to an English link they work, but when I tag a new post Wordpress creates a copy of the tag and uses the original http://blogger-off.com/tag/%e5%a4%a9%e6%88%b8%e4%b8%ad%e5%ad%a6%e6%a0%a1/

Hope this is comprehendable. Maybe an example will help.

  1. I create a new post and tag it with 天戸中学校 - Wordpress then creates a slug of http://blogger-off.com/tag/%e5%a4%a9%e6%88%b8%e4%b8%ad%e5%ad%a6%e6%a0%a1/ which is a 404 page not found link.
  2. I then go into the tag management and change the slug to http://blogger-off.com/tag/amadochuugakkou/ and all is well.
  3. I have a new post and tag it with the same tag 天戸中学校 - Wordpress doesn't recognize that the tag already exists and then creates another tag, with the original slug (the 404 link)
  4. I end up with two tags with different slugs. The first post has a working tag/slug while the second post does not

cannot tag more than one post with Japanese unless I leave the tag slug unchanged until I have tagged all the posts, then change the slug to English. This is fine unless I tag a new post - I have to go back and remove all the tags and then retag them with the broken slug tag, then rename the slug.

Very confusing.

Oh, and there is one other thing. I'm not sure if its a browser issue or a server issue or a Wordpress issue, but if you look at the page title (top of browser window) when viewing a Japanese tag, its also borked. Strange thing is all the Japanese post titles and slugs work perfect - its just the tags that are all crazy.


Change History (9)

#1 @jacobsantos
12 years ago

  • Component changed from General to i18n
  • Keywords japanese slug localization added; Japanese Slug Tag Broken removed

#2 @ryan
11 years ago

We've fixed several such bugs recently. Can you reproduce this in 2.6.2 or 2.7?

#3 follow-up: @ryan
11 years ago

  • Resolution set to fixed
  • Status changed from new to closed

Resolving as fixed. Reopen if the problem still occurs.

#4 in reply to: ↑ 3 @janbrasna
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to ryan:

Can you reproduce this in 2.6.2 or 2.7?

Replying to ryan:

Reopen if the problem still occurs.

Yes, 2.7-beta3-9858 behaves as kiwizz reported.

#5 @janbrasna
11 years ago

I'm not sure if it really is an i18n problem even though it is demonstrated by a non–english case — it seems more like a general advanced–UTF problem either in the taxonomy component or somewhere in the permalink processing.

#6 @nbachiyski
11 years ago

/tag/天戸中学校/ works well for me both on Firefox and Safari.

#7 @nbachiyski
11 years ago

I meant /tag/%e5%a4%a9%e6%88%b8%e4%b8%ad%e5%ad%a6%e6%a0%a1.

#8 @janbrasna
11 years ago

Even though the issue appeared at the time I reopened the ticked (vanilla SVN installs r9858 and r9922) and was clearly reproduced, after a little bit of working with the tags (removing, adding new, renaming) and posts (adding more, adding new with the same problematic tag etc.) I'm no longer able to reproduce the incorrect behavior. Seems that the erroneous behavior is present only under certain circumstances. Let me check if I can reproduce it again on a fresh install.

#9 @janbrasna
11 years ago

  • Keywords reporter-feedback added
  • Resolution set to fixed
  • Status changed from reopened to closed

I can't seem to find the conditions under which I was able to reproduce the bug even on vanilla installs. If anyone happens to encounter this bug, feel free to reopen the ticket. Closing now as fixed.

Note: See TracTickets for help on using tickets.