- How do I install matriphe/iso-639 in a Laravel application?
- Run composer require matriphe/iso-639 and you are essentially done. The package ships a Laravel service provider and facade, so on current Laravel versions package discovery registers them automatically; on older releases you add the provider and facade alias to config/app.php. There are no config files to publish, no migrations, and no runtime prerequisites, so the whole setup takes a few minutes.
- How do I convert an ISO 639-1 code such as en into a language name?
- Pass the two-letter code to the library's lookup call, either through the facade or a directly instantiated class, and it returns the matching language name from its bundled table, for example English for en. A companion lookup gives you the native name, such as Deutsch for de, from the same data set. Method names and return shapes are documented in the README, so check there for the exact signature in your installed version.
- Does this package support ISO 639-2 and ISO 639-3 three-letter codes?
- The package documentation describes conversion between ISO 639-1, ISO 639-2, and ISO 639-3 codes, while its core table is the roughly 184 two-letter ISO 639-1 entries from Wikipedia's List of ISO 639-1 codes. If your product depends on three-letter, bibliographic (639-2B), or terminological codes, verify the specific entries you need against your own reference list before shipping.
- Can I use matriphe/iso-639 outside Laravel, in a plain PHP project?
- Yes. It is a framework-agnostic Composer package; the service provider and facade are optional conveniences, not requirements. In plain PHP you install it with Composer, instantiate the class, and call the lookup method directly. There are no framework helpers, database connections, or HTTP calls involved.
- What happens if I pass an invalid or unknown language code?
- The library includes code validation, so the safest pattern is to validate a code before looking it up rather than relying on lookup failure behaviour. Confirm in the source or test suite whether an unknown code returns null, an empty string, or throws, because that decides how much defensive code your call sites need. When codes come from user input or an external API, normalise case and validate first.
- How does it handle deprecated codes like iw, in and mo, or regional variants like en-US and pt-BR?
- The mapping is keyed by two-letter ISO 639-1 codes, so legacy or deprecated codes such as iw (Hebrew), in (Indonesian) and mo (Moldavian) are not resolved for you. Regional subtags like en-US or pt-BR must also be split and normalised, and you should lowercase codes such as EN before lookup. Doing that normalisation in one place, ideally behind a small internal resolver, keeps the rest of your code clean.
- Are the language names localised, or English only?
- Names come from Wikipedia's English-language List of ISO 639-1 codes, so the primary output is English, giving German rather than Deutsch or Allemand. The package also exposes native names, which covers endonyms in the language itself but is not a full localisation system. If your UI must display language names in the user's own locale, plan to supply your own translation layer on top.
- Which PHP and Laravel versions does matriphe/iso-639 support?
- Because it is a leaf dependency with no database, network, or extension requirements, it drops into any modern PHP application and Laravel project. The exact constraints are declared in the package's composer.json, which is the authoritative source for the minimum PHP version and any Laravel version bounds. Check that file, and ideally the CI matrix, before installing into a legacy codebase pinned to an older PHP release.
- Is matriphe/iso-639 actively maintained enough to use in production?
- Breakage risk is low because the ISO 639-1 table is static and effectively frozen, so there is very little in the library that can fail on its own. Stewardship risk is the real concern: it is a single-maintainer package with modest adoption and few known dependents, so abandonment is more likely than a sudden breaking change. A recent release date is reassuring on currency but does not prove ongoing maintenance, so treat it as an unowned data dependency and plan accordingly.
- How do I replace or vendor matriphe/iso-639 if I want to drop the dependency?
- The package's entire value is a static associative array of roughly 184 entries, so you can copy that map into a first-party class or a config/languages.php file and remove the dependency in an afternoon, tests included. That makes vendoring a legitimate first choice for teams with dependency-governance rules, not just an emergency exit. If you do adopt the package, wrap it behind a thin interface such as LanguageNameResolver so the switch later is a one-file swap with no call-site churn.