Locale Requirements Template

What This Template Is For

Every locale has its own rules for dates, numbers, addresses, names, and more. These rules are not optional preferences. Displaying a date as MM/DD/YYYY to a German user or putting the postal code after the city in a Japanese address form signals that you do not take their market seriously. Worse, getting currency formatting or tax display wrong can create legal liability.

This template helps product managers document the specific requirements for each locale their product supports. It covers formatting conventions, cultural UX considerations, legal requirements, and content adaptation needs. One copy is completed per locale (not per language, since the same language can have different conventions in different countries).

Use this alongside your localization strategy template to ensure locale requirements feed into the broader market entry plan. When requirements are documented, hand them to engineering with the i18n readiness template for implementation assessment.

How to Use This Template

1. Copy the template and create one instance per target locale (e.g., de-DE, ja-JP, pt-BR).
2. Research each section using the CLDR (Unicode Common Locale Data Repository) as your primary reference.
3. Validate with a native user or in-market contact. CLDR covers formatting; it does not cover cultural UX preferences.
4. Share completed requirements with engineering, design, and QA.
5. Use these requirements as the acceptance criteria for locale implementation.
6. Update when locale rules change (e.g., new tax requirements, format standard updates).

The Template

Locale Identification

• ☐ Locale code (BCP 47 format): _____ (e.g., de-DE, ja-JP, pt-BR)
• ☐ Language: _____
• ☐ Country/Region: _____
• ☐ Script (if non-Latin): _____ (e.g., Japanese: Kanji + Hiragana + Katakana)
• ☐ Text direction: LTR / RTL
• ☐ Character set requirements: Latin / CJK / Arabic / Cyrillic / Other: _____

Date and Time Conventions

• ☐ Date picker component must support this locale's format
• ☐ Date input fields must parse this locale's format correctly
• ☐ Relative date strings ("yesterday", "2 days ago") must be localized

Number and Currency Conventions

• ☐ Number input fields must accept this locale's decimal separator
• ☐ Currency display must follow locale rules in all contexts (UI, emails, invoices, PDFs)
• ☐ Rounding rules documented for this currency

Address Format

• ☐ Address field order matches local convention
• ☐ Postal code validation regex defined
• ☐ State/province dropdown populated with locale-correct values
• ☐ Address autocomplete configured for this locale

Address format example:

[Locale-specific address format here]

Name Conventions

• ☐ Name input fields support this locale's conventions
• ☐ Display name format follows locale rules (e.g., "Tanaka Taro" not "Taro Tanaka" in ja-JP)
• ☐ Email greeting uses correct salutation format

Measurement Units

• ☐ Product displays measurements in locale-appropriate units
• ☐ Unit conversion available if product stores data in a different unit system
• ☐ PDF/print output uses locale-appropriate paper size

Legal and Regulatory Requirements

• ☐ Privacy regulation: ___ (GDPR, LGPD, PIPA, PDPA, CCPA, etc.)
• ☐ Cookie consent requirements and format
• ☐ Data residency requirements (must data be stored in-country?)
• ☐ Age of consent for data collection: ___
• ☐ Accessibility regulation: ___ (ADA, EAA, JIS X 8341, etc.)
• ☐ Invoice requirements (fields, format, language, retention period)
• ☐ Tax display requirements (inclusive vs. exclusive, tax type labels)
• ☐ Digital services tax applicability
• ☐ Consumer protection requirements (return policy display, contract terms)

Review the regional compliance template for a full regulatory breakdown. For EU-specific privacy requirements, see the GDPR compliance template.

Cultural UX Considerations

• ☐ Design team briefed on cultural considerations for this locale
• ☐ Marketing copy adapted (not just translated) for cultural fit
• ☐ Imagery reviewed for cultural appropriateness

Content Adaptation

Technical Requirements

• ☐ Fonts support all characters in this locale's script
• ☐ Text rendering handles this locale's script correctly (ligatures, combining characters)
• ☐ Line breaking follows locale rules (CJK: break anywhere; Thai: no spaces between words)
• ☐ Sorting and collation use locale-appropriate rules
• ☐ Search handles locale-specific characters (accents, umlauts, special characters)
• ☐ Input method editor (IME) compatibility tested (for CJK locales)
• ☐ Text expansion handled (German text is 30% longer than English on average)

Filled Example: ja-JP (Japanese, Japan)

Locale Identification

• Locale code: ja-JP
• Language: Japanese
• Script: Kanji + Hiragana + Katakana (mixed)
• Text direction: LTR (horizontal), top-to-bottom (vertical, rare in software)

Date and Time

Address Format

〒100-0001
東京都千代田区千代田1-1
山田太郎 様

Order: Postal code, Prefecture, City, Street, Name. Reverse of Western convention.

Name Conventions

Family name first: 山田 太郎 (Yamada Taro). In formal contexts, add 様 (sama) as honorific. Never use first name alone in business contexts.

Key Takeaways

• One locale requirements doc per locale (not per language). de-DE and de-AT are different
• Use CLDR as the source of truth for formatting rules, then validate with a native user
• Document every format with a concrete example. "Localized date format" is not testable; "DD.MM.YYYY" is
• Cultural UX considerations go beyond formatting. Colors, formality, information density, and trust signals differ by market
• These requirements become acceptance criteria for engineering. Keep them precise and testable

About This Template

Created by: Tim Adair

Last Updated: 3/5/2026

Version: 1.0.0

License: Free for personal and commercial use