Does Your Code Pass the Turkey Test? (2008)

Original Article ↗ Hacker News Discussion ↗

Software that only assumes U.S. conventions for text, dates, numbers, and casing often breaks in surprising ways when run under other locales, with Turkey/Türkiye providing many classic failure cases such as the “Turkish i” problem. Commenters trade examples of how locale-sensitive APIs, date formats (MDY vs DMY vs ISO 8601), numeric separators, calendars, and transliteration rules can subtly corrupt data or logic if developers don’t explicitly handle internationalization. Many argue that systems should default to locale-agnostic formats (like ISO 8601 and UTC, or raw timestamps plus explicit intent) and treat human-facing formatting as a separate, carefully designed layer.

Date and time formats

  • Strong advocacy for ISO 8601 (YYYY‑MM‑DD, big‑endian) because it sorts correctly and avoids ambiguity between US MDY and EU DMY.
  • Debate over whether DMY “makes sense”:
    • Pro: aligns with how many languages naturally say dates, and people think in day → month → year importance.
    • Con: inconsistent with how numbers and times are normally ordered; some argue only big‑endian or little‑endian systems are coherent.
  • MDY defended as matching spoken American English (“September 11, 2001”), but others note this is not universal even among English dialects.
  • Time notation: 24‑hour and y‑m‑d h:m:s praised as unambiguous; 12‑hour UTC displays described as particularly confusing.
  • Several examples of locale-specific date parsing bugs, including region‑dependent month abbreviations (“Sep” vs “Sept”) breaking parsing on certain servers.

Turkey/Türkiye naming and exonyms

  • Many note the original “Turkey test” now fails itself since the country prefers “Türkiye”.
  • Disagreement over whether this request is “heavy‑handed” or normal, with comparisons to other country name changes (e.g., Côte d’Ivoire) and long‑standing exonyms (Germany, Japan, Mexico, etc.).
  • Some argue each language can keep its own names; others say it’s reasonable to honor a country’s preferred self‑designation, at least in formal contexts.
  • Practical issues: diacritics and ASCII, transliteration of ü/ö and Turkish characters, and confusion between the country and the bird mainly in English.

Localization pitfalls and case/locale issues

  • Repeated horror stories about locale‑dependent APIs:
    • Java Calendar returning Buddhist calendar in Thai locales.
    • Case conversion (tolower) and Turkish dotted/dotless “i” breaking file/module loading.
    • Command‑line argument case handling differing between Unix tools and Windows.
  • Criticism that many libraries are locale‑sensitive by default, causing subtle bugs if locales aren’t explicitly fixed.

Broader internationalization edge cases

  • Mention of decimal separators, thousands separators, localized month names, non‑Latin scripts, and very long personal names.
  • Address and name order conventions (surname‑first cultures, street‑first addresses) highlighted as frequent oversights.
  • Several commenters see the “Turkey test” as one instance of a broader “not‑America” test: software often assumes US formats and fails elsewhere.

Meta

  • The article is from 2008; some feel the insights are now obvious, others say similar bugs remain widespread.