Exercise 2: Why SlugField Needed allow_unicode=True — Possible Solution
====================================================================

WHY THE ORIGINAL SlugField FAILS FOR KANJI
------------------------------
Per this chapter, Chapter 2's original slug = models.SlugField(max_length=100) only accepts ASCII letters, numbers, hyphens, and underscores by default. A literal kanji character like "水" is not an ASCII character, so it fails that default validation outright, immediately, before the row would ever be allowed to save - the field's own built-in validator would reject it as an invalid slug value.

WHAT allow_unicode=True ACTUALLY DOES
------------------------------
Per this chapter, allow_unicode=True is Django's own built-in parameter for exactly this scenario - it changes SlugField's validation to accept real, non-ASCII Unicode characters as valid slug content, rather than only tolerating them through some workaround. With it set, a slug value of "水" passes validation normally and can be saved and used as a real URL segment, without needing to romanize it into something like "sui" instead.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that SlugField's default validator is ASCII-only and would reject a literal kanji character, and correctly explains that allow_unicode=True is the specific, built-in Django parameter that makes real Unicode characters valid slug content instead.