Iso 639 Laravel Package

Product Decisions This Supports

• Localization and language-selector UX. Any surface where a user picks or is shown a language — onboarding, profile settings, notification preferences, content submission forms — needs a stable two-letter code stored in the database and a human-readable label rendered in the UI. A code-to-name map is the minimal dependency for that split between storage and presentation.
• Content metadata and discovery. Tagging articles, posts, videos, or listings with a language enables filtering, "available in your language" badges, and feed ranking. The lookup table is what turns a raw en/pt-BR column into something a catalogue or search facet can display.
• Analytics and internal reporting. Product, support, and growth teams routinely ask for "users by language" or "tickets by content language." A canonical name mapping keeps dashboards and CSV exports readable without each analyst hardcoding their own dictionary.
• Admin, moderation, and support tooling. Trust-and-safety and support agents work from queues that surface user and content attributes; language is one of them, and it must render as a name, not a code.
• API and webhook payload enrichment. If partners or internal services consume your API, returning both language_code and language_name reduces integration friction and cuts a class of support tickets.
• Build-vs-buy signal for i18n scope. Evaluating this package is really a question about how deep your localization roadmap goes. If the answer is "we only need names for a handful of codes," the decision is a data-constant decision, not a platform decision — and should not be allowed to expand into an i18n programme.

The opportunity score here is low and the adoption signals are effectively nil (no stars, no dependents). Treat this as a reference implementation and dataset, not as infrastructure. The product decision it most cleanly supports is: do we vendor a small static language map, or do we standardise on an ICU/CLDR-backed library? That is a decision worth making deliberately once, because it determines whether you can later show language names in the user's own locale (e.g. "German" vs "Deutsch" vs "Allemand"), which is a genuinely different product capability from a single-locale label.

When to Consider This Package

Consider it when all of the following hold:

• You need only ISO-639-1 (two-letter) codes mapped to English language names.
• Your stack is plain PHP/Laravel with no ext-intl and no symfony/intl already pulled in — in which case this adds a small amount of value rather than duplicating it.
• The list is used for display only; no validation, no negotiation, no locale-aware sorting or collation.
• You are willing to pin the version and treat the data file as your own, or vendor the array directly into your codebase.

Look elsewhere — or build in-house — when any of these apply:

• You need more than names. ISO-639-2/3 codes, macrolanguages, scripts, regions, or BCP-47 tags (pt-BR, zh-Hant) are out of scope; reach for symfony/intl, ICU/CLDR data, or a maintained language-list package.
• You need localized language names. Showing "Deutsch" to a German user requires CLDR translation data, which a single Wikipedia-derived English map cannot provide.
• Supplier risk matters. Zero stars and zero dependents means no community review, no downstream bug reports, and no signal that security or data-accuracy issues would be caught. For a map of ~180 static strings the risk is small, but so is the benefit — copying the data removes the dependency entirely.
• You already have Intl. \Locale::getDisplayLanguage() or Languages::getName() covers this and far more, with a maintenance story you already pay for.
• You need validation. This is a presentation helper; do not let it become your authority for rejecting user input.

Net recommendation: do not adopt as a runtime dependency. Either vendor the dataset behind your own small interface (so the source can be swapped later), or standardise on symfony/intl if localized names are anywhere on the roadmap. If you do adopt, wrap it — never call it from views or controllers directly.

How to Pitch It (Stakeholders)

For executives: This is a ~180-entry lookup table that turns a two-letter language code into a readable name. It is not a platform or a strategic bet. The package itself has no meaningful adoption or maintenance signal, so I do not recommend taking it on as a dependency. The underlying need — showing "French" instead of "fr" in settings, filters, and dashboards — is real but small, and we can meet it in an afternoon with a vendored data file. The one decision worth your attention is whether language names eventually need to appear in the user's own language; if international expansion is on the roadmap, we should adopt a CLDR-backed library now rather than accrue a series of one-off tables we later have to unpick.

For engineering: The ask is a code-to-name map with no behaviour beyond lookup. Two viable paths: (1) vendor the dataset behind a LanguageNameResolver interface with a single name(string $code): ?string method, keeping the third-party source an implementation detail we can replace; or (2) add symfony/intl if we want localized display names, script and region data, and a maintained data pipeline. Please do not call the package directly from Blade templates or controllers, and do not use it for input validation — validation belongs to a whitelist we control. Whatever we choose, keep the interface narrow so the choice stays reversible.