Filament Thailand Location Picker Laravel Package

Product Decisions This Supports

• Thailand market entry / localization roadmap. The package ships the full Thai administrative hierarchy (Region → Province → District → Subdistrict → Zip Code) as cascading Filament selects, so address capture for Thai users is a configuration decision rather than a multi-sprint build. That directly shortens the critical path for launching a TH-facing product.

• Build vs. buy for reference data. Maintaining ~77 provinces, ~928 districts and ~7,400 subdistricts — plus the Thai/English name pairs and postcode mappings — is undifferentiated work with real upkeep cost when administrative boundaries change. Adopting the package is effectively buying a maintained dataset plus the drill-down UX; the roadmap trade-off is vendor coupling in exchange for zero data-ops headcount.

• Address-capture UX and funnel measurement. v1.1.0's enable_geo toggle (config('thailand-plugin.enable_geo') globally, or ->geoEnabled(false) per field) is a genuine A/B lever. Forcing Region first adds one interaction before the user reaches Province; if analytics show drop-off at that step — or if users commonly don't know their region — you can flatten the flow without touching code, and ProvinceSelect falls back to listing all provinces unfiltered. Treat this as a testable variant, not a permanent setting.

• Bilingual product scope. v1.1.0 decouples two things that were previously conflated, and this is the most strategically useful change:

  • thailand-plugin.locale controls which data column (name_th / name_en) is displayed.
  • Built-in UI labels/placeholders now come from Laravel JSON translation files keyed off App::getLocale(), for en and th, and are publishable via php artisan vendor:publish --tag="thailand-plugin-translations".

  Practically, this means you can serve a Thai-label UI while keeping English place names for back-office reconciliation — or the reverse — and you can override copy (e.g. "Zip Code" → "Postal Code", or a friendlier "Tambon") without forking. It also unlocks a bilingual ops console where the admin's locale and the stored data locale are independent decisions.

• Compliance, logistics and reporting readiness. Structured subdistrict + postcode capture (rather than a free-text address line) is the input that shipping-rate tables, tax/VAT address rules, KYC and territory-based sales reporting all depend on. Choosing structured capture now avoids a painful backfill later.

When to Consider This Package

Adopt when:

• The stack is Filament + Laravel and the address form lives in an admin panel, resource, or Filament-based internal tool. This is a hard prerequisite — the field components are Filament form fields, not a generic Blade/API solution.
• Thailand is a primary or sole market, and Province/District/Subdistrict granularity is actually required by a downstream process (delivery pricing, territory assignment, compliance).
• You want the dataset maintained for you and are comfortable with the vendor's release cadence for boundary changes.
• You need Thai/English naming and bilingual labels with minimal effort — now stronger than in v1.0.0 given the translation files and publish/override path.

Look elsewhere when:

• You need multi-country address handling, or Thailand is one of several markets — a single-country picker becomes a special case you'll wrap in conditional logic.
• You need storefront / public-facing forms outside Filament, or an API-only address service. You'd be re-implementing the component layer.
• You require address validation, normalization, or rooftop geocoding — this supplies reference data and cascade behavior, not verification against reality. Pair it with a geocoding/validation vendor or expect dirty data at the subdistrict level.
• You need a contractual data-freshness SLA or must support subdistrict boundary redistricting with legal sign-off; then a commercial address vendor is the safer buy.
• Your team already standardizes on a broader address platform, and introducing a second source of truth for Thai geography creates reconciliation debt.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk dependency that removes a known Thailand-launch blocker. It gives us correct, structured Thai addresses — province, district, subdistrict, postcode — with Thai and English labels, without us building or maintaining a geographic dataset. The v1.1.0 update adds two things that matter commercially: a switch to simplify the address step if it costs us conversions, and proper bilingual labelling so one codebase serves Thai users and English-speaking staff. Cost is integration effort, not licence or headcount; the main risk is vendor dependency for data updates, which we can mitigate by keeping an export path.

To engineering: Filament form components plus a bundled Thai geography dataset. v1.1.0 adds enable_geo (global config or per-field ->geoEnabled(false)) with an unfiltered province fallback, and JSON translations for en/th driven by App::getLocale() — deliberately separate from thailand-plugin.locale, which selects the name_th/name_en data column. Translations are publishable and overridable. Integration surface is narrow (composer install, config publish, add fields to resources); no migrations or schema changes implied. Verify our Filament major version compatibility and decide up front whether enable_geo is a global default or a per-form choice, since it affects form definitions.