Production database should use a better default collation

[jennifer-richards]

The production database uses the "C" collation, which does not handle accented characters well; en-US-x-icu was suggested in #11234 and is reasonable. This is an operational change rather than a code change, but once the collation moves, the explicit Collation() calls added in #11234 should be removed.

Task

• Move the production database off the C collation and drop the explicit Collation() calls added in fix: Use Django Collate() when listing all ADs #11234

---

Agent-assisted triage

• Suggested size: S
• Suggested priority: minor
• Suggested lane: standard
• Updated with agent assistance on 2026-08-18

---

Original report

Description

The production database is using the "C" collation. This does not handle accented characters well and we should change to a different collation. In #11234, en-US-x-icu was suggested and it seems reasonable to me.

This is really a task rather than a code change, but if/when we do change the collation, we should remove the explicit Collation() calls added in #11234.

Code of Conduct

• I agree to follow the IETF's Code of Conduct

[rjsparks]

Two other open issues depend on what the production collation is, so whoever picks this up should
look at them together:

• CICharField is deprecated and will be removed #5660 — replace CICharField for case-insensitive Email.address with a collation-based
  approach. Which approaches are available there depends on the database's default collation.
• Some dropdown SELECT inputs for ADs do not sort by I18N #11167 — sort the AD dropdown by I18N collation. Ordering of accented names is one of the
  things the C collation gets wrong.

Neither is blocked by this issue, but moving off C changes what the right fix looks like in both.

Noted during agent-assisted issue consolidation, 2026-08-18.