Text Language Detect Bundle Laravel Package

Product Decisions This Supports

• Feature validation, not production delivery. The only defensible use is a spike: confirming that n-gram/frequency-based language detection is accurate enough on your corpus before committing roadmap scope to a "detect language on ingest" or "auto-route content to translators" feature.
• Build vs. buy framing. This package demonstrates the buy path in its cheapest form — a thin DI wrapper over the PEAR Text_LanguageDetect library. It's useful as a cost baseline ("wrapping an existing detector is a day of integration work") against the build alternative of training/hosting a detector. It does not justify a multi-week internal build on its own.
• Use cases it can scope: short-text language tagging for CMS/UGC, routing support tickets to the right locale queue, pre-filtering spam or abuse reports by language, deciding whether to show a machine-translation fallback, or gating search analyzers by detected locale.
• Roadmap input on i18n maturity. Evaluating this surfaces a real product question: language detection on short strings (tweets, product titles, chat) is unreliable, and the quality bar differs sharply from paragraph-level detection. That distinction should land in the roadmap as either an accepted limitation or a spike of its own.
• Explicitly not a build-vs-buy vote for adoption. With 3 stars, zero dependents, and a Symfony2-only wrapper, this package is a historical artifact rather than a vendor decision. Treat it as one data point in a comparison, not the shortlist.

When to Consider This Package

Consider it only if all of the following hold:

• You are maintaining an existing Symfony 2.x application (EOL since November 2019) and need language detection wired into its service container with minimal new code.
• You accept an unmaintained wrapper over an unmaintained PEAR library, and you are comfortable vendoring or forking it.
• Your detection input is paragraph-length text, where frequency-based detection is reasonably accurate; short strings will disappoint.
• You need a zero-dependency, offline, CPU-only detector with no external API calls — e.g., an air-gapped or data-residency-constrained deployment.

Look elsewhere when:

• You're on Laravel or any modern PHP stack. The package literally cannot be installed usefully there — it's a Symfony bundle with no Laravel service provider. The premise of "Laravel/PHP package" is a mismatch; the closest equivalent is using pear/Text_LanguageDetect (or a maintained fork) directly, bypassing the bundle entirely.
• You need maintained code. Zero dependents and three stars mean no security patching, no PHP 8.x guarantees, and no community to ask. Budget for owning it.
• Accuracy matters on short text or mixed-language content. Modern alternatives — CLD3/CLD2 bindings, lingua ports, fastText's lid.176, or a hosted detection API — materially outperform N-gram frequency counting on short strings and code-switched text. For most product surfaces this is the correct technical choice regardless of language.
• You need more than ~80 languages, confidence scores you can threshold on, or per-script handling. Verify the underlying library's language list and score semantics before you promise anything to design.

Practical guidance: if language detection is a genuine roadmap item, run a two-day bake-off on your real sample text between the underlying PEAR library and one modern alternative, and let accuracy on your data pick the winner. Do not let a Symfony2 bundle constrain a Laravel product decision.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed wrapper that lets a PHP app guess what language a block of text is written in. It's not a strategic dependency — it's an old Symfony2 plug-in around an older library, with negligible community traction. The value of looking at it is narrow: it shows us the cheapest possible version of "auto-detect language on ingest," which helps us price the feature and decide whether to build, buy, or defer. Recommendation: fund a short evaluation of detection quality on our actual content, and select a maintained library rather than this bundle.

To engineering: Treat webmil/text-language-detect-bundle as a reference implementation, not a dependency. It's a DI wrapper over Text_LanguageDetect (PEAR, frequency/N-gram based) and assumes Symfony 2 — there is no Laravel integration, and the ecosystem around it is dormant. If we want this capability, the decision is between calling the underlying library directly behind our own small interface, or adopting a maintained detector (CLD3, fastText lid.176, or a hosted API). Please surface: accuracy on short strings, language coverage, latency, and whether detection runs inline or async. We should wrap whichever we choose behind our own service contract so the library is replaceable — the one durable lesson this package teaches is that these wrappers churn.