8 questions from the RFI stage, free
These come from the module as sold. The workbook adds follow-ups, a response format, a weight and a score column to each.
1. List all languages in which your product's user interface is fully localized, and indicate for each whether translations are professionally human-translated, machine-translated with human review, or machine-translated only.
Why it matters. A language listed as supported may be machine-translated, and machine translation can get business terminology wrong. Distinguishing translation provenance lets buyers gauge real usability in target locales and forecast translation-related support burden.
- Provides a table of supported languages with translation method per language
- Distinguishes UI coverage from documentation/AI behavior coverage
- Names professional localization vendor or internal localization team
- Generic claim of 'supports 30+ languages' without per-language detail
- All translations machine-generated with no human review
- Cannot identify who performs translations
2. Describe how your product handles customer-supplied content (user inputs, documents, prompts, files) in non-English languages, including character encoding, tokenization, and storage.
Why it matters. AI tools can degrade silently on non-English input — truncating multi-byte characters, mis-tokenizing CJK text, or normalizing in lossy ways. Buyers need to know whether customer-language content is a first-class concern or an afterthought.
- Confirms UTF-8 end-to-end with no encoding loss
- Discloses tokenizer behavior for non-Latin scripts
- Addresses Unicode normalization (NFC/NFD) consistency
- Cannot confirm UTF-8 throughout pipeline
- Acknowledges character-set issues with specific languages
- Tokenization significantly inflates costs for non-English text without disclosure
3. List the locale-aware behaviors your product implements (date formatting, time formatting, time zones, number formatting, currency formatting, sort/collation order, plural rules) and confirm whether each follows CLDR or another standard.
Why it matters. Locale support can be partial: currency formatting works but date formatting is hardcoded MM/DD/YYYY. CLDR (the Unicode Common Locale Data Repository) is the locale data used by ICU and by the major operating systems and browsers. A vendor that hand-rolls formatting per locale maintains that data itself.
- References CLDR or ICU as the underlying data source
- Provides a matrix of locale-aware behaviors with implementation status
- Distinguishes user-locale from tenant-locale from data-locale
- Hardcoded US English formatting in some surfaces
- Cannot identify the data source for locale rules
- Currency formatting works but date or number formatting does not
4. List the languages in which you provide customer support, including support channels (email, chat, phone) and hours of coverage per language.
Why it matters. Localized UI is hollow if support is English-only or only available during US business hours. Buyers in EMEA and APAC need to know whether they will have native-language support in their operating timezone.
- Provides a table of language, channel, and hours coverage
- Confirms support hours overlap with buyer's operating timezone
- Distinguishes tier-1 from tier-2/engineering escalation languages
- Support only in English
- Support hours only cover US business hours
- Non-English support is via machine translation
5. Confirm whether all product surfaces (web UI, mobile apps, admin console, email notifications, system-generated content) share the same language coverage, and disclose any surfaces that remain English-only.
Why it matters. A vendor may translate the main web UI but leave admin consoles, email notifications, or system alerts in English, so non-English users work in two languages.
- Provides a matrix of surfaces × languages
- Confirms email notifications and system messages are localized
- Addresses both end-user and administrator surfaces
- Email notifications and system alerts only in English
- Admin console English-only despite translated end-user UI
- Mobile app coverage differs from web without disclosure
6. For AI-powered features, disclose any material differences in model behavior, quality, or available capabilities across the languages your product supports.
Why it matters. Frontier and open-weight models perform unevenly across languages, and capabilities (function calling, structured output, safety filters) may be tuned only for English.
- Provides language-tier classification (e.g. tier 1 fully supported, tier 2 partial)
- Discloses benchmarks or quality measurements per language
- Acknowledges specific feature gaps (e.g. safety filters only available in English)
- Claims identical behavior across all languages without evidence
- Cannot identify which languages the underlying model is best at
- No evaluations performed in non-English languages
7. Describe how time zones are handled across your product, including storage, display, user preferences, and any AI-generated timestamps or scheduling output.
Why it matters. Time zone errors include meetings scheduled in the wrong zone, logs displayed in UTC when users expect local, AI outputs referencing 'tomorrow' ambiguously. Multinational deployments require explicit, consistent behavior.
- Confirms timestamps stored in UTC
- Provides per-user time zone preferences
- Uses IANA time zone identifiers, not fixed offsets
- Uses fixed UTC offsets that break across DST transitions
- No per-user time zone preference
- AI generates relative dates ('next Tuesday') without zone context
8. List the languages in which your product documentation, knowledge base, and training materials are available, and indicate update lag between English and translated versions.
Why it matters. Translated UI paired with English-only documentation forces non-English users to context-switch. Lagging translations describe an outdated product.
- Documents available in same languages as UI
- Documents update lag explicitly (e.g. a committed number of days after English release)
- Includes API documentation and admin documentation, not just end-user docs
- Documentation English-only despite multi-language UI
- Translations months behind English
- Only end-user docs translated, not admin/API docs
What the audit changed
A language model drafted these questions and a second model critiqued them. Three audit passes followed and made 121 changes. Three examples:
Wrong or outdated citation
Draft: Negative number conventions per locale (e.g. parentheses, leading minus)
Now: Negative number conventions per locale (e.g. minus sign form and position, parentheses in CLDR accounting currency formats)
In CLDR, parentheses for negatives come from the accounting currency format (en_US '¤#,##0.00;(¤#,##0.00)'); standard number formats use the locale's minus sign. UTS #35 Part 3, Numbers (https://unicode.org/reports/tr35/tr35-numbers.html).
Wrong or outdated citation
Draft: Validation library (e.g. libpostal, libphonenumber) referenced
Now: Address parsing library (e.g. libpostal) and phone validation library (e.g. libphonenumber) referenced
libpostal parses and normalizes addresses; it does not validate them (https://github.com/openvenues/libpostal). libphonenumber parses, formats and validates phone numbers (https://github.com/google/libphonenumber).
Wrong or outdated citation
Draft: Swedish 'å' comes after 'z'
Now: Swedish orders 'å', 'ä', 'ö' after 'z' but code-point order puts 'ä' before 'å'
Code-point order also puts 'å' (U+00E5) after 'z', so the example did not show a failure. Swedish collation is z < å < ä < ö; code points are ä U+00E4, å U+00E5, ö U+00F6. CLDR Swedish collation tailoring (https://github.com/unicode-org/cldr/blob/main/common/collation/sv.xml); UTS #10 (https://www.unicode.org/reports/tr10/).
