Laravel Lang Country Laravel Package

Product Decisions This Supports

• Build vs. buy (localization defaults layer): This is a small, MIT-licensed data + convenience wrapper, not infrastructure. The decision it settles is "do we hand-maintain a country→language→date-format table, or take a dependency?" Buying costs an afternoon; building costs a sprint you'd rather spend on the feature. Adopt it, but behind a thin internal adapter so the data is swappable.
• Market sequencing on the roadmap: The package makes the per-country language surface explicit. If Canada, Switzerland, Belgium, India, or South Africa are on the roadmap, "one market = one language" is a planning error. This lets you price translation and QA effort per target market with real language sets instead of guesses.
• Modelling decision — country and locale are separate fields: The core insight ("setting the locale is not enough") is a product/schema argument, not just a technical one. A French-speaking user in Canada and a French-speaking user in France share a language but not a date format. This package is the concrete justification for keeping country and language as independent attributes in the data model, with country supplying defaults and the user supplying truth.
• Country-aware defaults at signup/checkout: Populate language and date format from detected/selected country, with a visible override. This raises first-session relevance without a language-picker wall — the difference between a form that feels local and one that feels translated.
• Defect class elimination (date ambiguity): DD/MM vs. MM/DD misinterpretation is an expensive, quiet bug — it shows up as wrong invoice dates, missed deadlines, and support tickets, not as a stack trace. Per-country date notation is a cheap, measurable reduction in a whole bug category.
• Compliance and document credibility: Invoices, receipts, contracts, and statements issued in a market with the wrong date notation read as sloppy or non-compliant to local finance teams and auditors. This is a checklist item, not a delight item.
• Localization budget defence: Being able to say "market A needs 1 language, market B needs 3" is a stronger funding argument than "we should localize more."
• Scope boundary to state up front: This is not a translation solution. It does not translate strings, and the README's pitch can be misread as broader i18n coverage than it delivers. Position it as the formatting and defaults layer underneath your translation layer (lang files, Crowdin/Lokalise/Phrase) and alongside your timezone and currency handling.

When to Consider This Package

Consider it when:

• You're on a supported Laravel/PHP version and already have (or plan to have) a country attribute on users, accounts, orders, or sessions.
• Your roadmap includes ≥2 markets where language or date notation diverges — or one market where date format matters contractually.
• You want per-country Carbon locale and date formatting without maintaining the mapping table yourself.
• You have geo-IP or a country selector and want country to seed sensible defaults.
• You're a small team without dedicated i18n infrastructure and want the 80% case handled.

Look elsewhere when:

• Single-locale, single-market product. No country field, no divergence, no problem — this is pure dependency weight.
• Your product concept is "user picks a language," not "user is in a country." Country→language is a guess, and a wrong guess is worse than no guess. If you won't offer an override, don't use the inference.
• You need more than languages and dates. Timezones, currencies, address formats, name/phone formatting, and plural rules live in other packages (commerceguys/intl, commerceguys/addressing, money, full CLDR/ICU). Don't stretch this one past its scope.
• You already have CLDR data in the stack — e.g. Intl.DateTimeFormat in a rich frontend, or an existing locale service. Adding a second source of truth for date formats creates drift; pick one.
• You need translation workflow, not formatting. TMS platforms and laravel-lang/* language files solve a different problem.
• Governance requires vendor support or an SLA. At ~300 stars and effectively single-maintainer stewardship, treat it as community code: pin the version, wrap the facade, and be prepared to vendor the data files. Mitigable — but not invisible to a procurement or security review.
• You're on an unsupported Laravel/PHP combination or maintain a policy against thin wrapper packages. In that case, copy the data tables and write ~50 lines yourself; that's the honest fallback.

How to Pitch It (Stakeholders)

To executives: A small, free (MIT), low-risk package that removes a recurring class of localization bugs — wrong date formats and wrong default languages in each market — for roughly an afternoon of integration. It also gives us a defensible, per-market language count, which sharpens localization budgets and launch sequencing. It is a tactical layer, not a platform bet: no external services, no data lock-in, and it can be replaced or inlined if we ever need to.

To engineering: It ships per-country language sets and date-format notation, plus Laravel-native conveniences — config-driven supported-country/language lists, a locale-setting middleware, a facade and Blade directives for formatting, and validation support. No runtime dependency, no network calls, no database. Integration pattern we recommend: wrap it in our own LocaleDefaults interface, keep country and locale as separate model attributes, always expose a user override, and add a small test asserting the country/language/date combinations for the markets we actually ship to. That bounds maintainer risk to a version bump and a test failure rather than a surprise in production.

To design/UX: It lets us pre-fill the right language and the right date notation on first visit and in outbound documents, without forcing a language modal. We still show an override — country is a guess, the user is the source of truth.