💡 Multilingual Market Experience with Spanish-First Localization

[github-actions[bot]]

Summary

Full internationalization (i18n) of the Markets app starting with Spanish, covering all three role flows (customer discovery, vendor check-in/status, manager dashboard). Includes culturally adapted onboarding, product category names in multiple languages, and bilingual push notifications. Designed to serve the significant Spanish-speaking vendor and customer population at US farmers markets.

Market Signal

Massachusetts MDAR contracted Spanish language training for market managers in 2024-2025, proving institutional recognition of the language barrier at farmers markets. 42% of market vendor operations are women-owned with growing immigrant farmer participation. No competing farmers market app — Localize (200K monthly downloads), Farmish (40K+ farms), MarketWurks, Seen Markets — offers a multilingual mobile experience. The USDA FMPP ($13.84M FY2026) explicitly prioritizes programs serving underserved communities, making multilingual support a grant-alignment advantage.

User Signal

The PRD's target user "Brad" represents multi-market vendors — many real-world equivalents are Spanish-speaking farmers who struggle with English-only apps. The "app-averse vendor" concern cited in the project context is amplified by language barriers. Product categories (produce names like "chayote," "tomatillo," "nopales") need culturally aware localization beyond simple UI translation. The USDA's emphasis on underserved community access creates both a moral and strategic imperative.

Technical Opportunity

React Native/Expo supports i18n via expo-localization + i18next. NativeWind and Gluestack UI v3 components support RTL layouts. The GraphQL schema can serve localized strings via an Accept-Language header, with the Go backend resolving translations from a PostgreSQL locale table. Starting i18n architecture now avoids costly retrofitting — string extraction is far easier before the codebase grows. The greenfield status of the project makes this the ideal moment to bake in i18n from day one.

Assessment

Dimension	Score	Rationale
Feasibility	med	i18n framework setup is well-understood; ongoing translation is the recurring cost
Impact	high	Unlocks underserved vendor/customer segment; FMPP grant alignment; competitive differentiation
Urgency	med	Architectural decision — easier now than retrofitting; demographic trends accelerating

Adversarial Review

Strongest objection: At pilot scale (5 markets, 40 vendors), the Spanish-speaking segment may be too small to justify the engineering investment in full localization.

Rebuttal: i18n is an architectural decision, not a feature toggle — it gets exponentially harder to retrofit as the codebase grows. The proposal is: establish the i18n framework now (string extraction, locale detection, translation pipeline) and ship Spanish content market-by-market based on demographic data. The incremental cost of adding Spanish once the framework exists is translation, not engineering. FMPP grants favor apps serving underserved communities, creating a grant-alignment incentive.

Suggested Next Step

Add expo-localization + i18next to the frontend tech stack decision in the architecture doc. Define a string extraction convention for all UI text. Identify the first 3 pilot markets with >20% Spanish-speaking vendor/customer populations.