Vokativ Laravel Package

Product Decisions This Supports

• Personalized greeting as a locale-specific feature. In Czech, addressing a user as "Dobrý den, Jan" instead of "Dobrý den, Jane" reads as machine-generated or careless. This package turns a name field into a grammatically correct 5th-case (vokativ) greeting token for email, push, SMS, in-app banners, and chatbot openers — a small feature with an outsized perceived-quality effect in the CZ market.
• CZ market entry / localization tiering. Deciding whether Czech is a "tier 1" locale (full copy + name inflection + support) or "tier 2" (translated copy, neutral greetings) is a roadmap call. This package makes tier 1 cheap enough to be defensible for a PHP/Laravel product.
• Build vs. buy vs. skip for morphology. Czech inflection is irregular (Jan → Jane, Petr → Petře, Ondřej → Ondřeji, Novák → Nováku; many female surnames and foreign names are unchanged or ambiguous). Hand-rolled suffix rules rot quickly. Adopting a small library — or explicitly deciding not to — is a decision worth recording rather than leaving to an engineer's afternoon hack.
• Template and design-system decisions. Whether greeting tokens ({{ first_name_vocative }}) exist in the notification/CRM layer, and whether the UI captures first name separately from full legal name. Without a dedicated first-name field, inflection quality collapses.
• Fallback policy as a product requirement. A wrong vocative is worse than no vocative. The decision to degrade gracefully ("Dobrý den," + nominative, or no name at all) is a product call, not an engineering one.
• Support and trust metrics. Tracking greeting-related complaints, reply rates, and unsubscribe rates in CZ campaigns gives a measurable read on whether the feature earns its maintenance cost.

When to Consider This Package

Consider it when:

• Your stack is PHP/Laravel and the library drops in without a service hop.
• Czech is a meaningful share of your user base and you send personalized, high-volume transactional or lifecycle messaging.
• You want a fast, low-cost proof of concept before committing to an NLP dependency.
• You can wrap it behind your own interface, pin the version, and own a fork if needed.
• The cost of an imperfect greeting is annoyance, not legal, financial, or brand-critical harm.

Look elsewhere when:

• You are not on PHP — running a PHP sidecar just for inflection is not worth it; use a Czech NLP service (e.g., morphological analyzers from the academic NLP ecosystem) or a neutral greeting.
• You need full inflection (all seven cases, addresses, salutations, formal/informal registers) rather than the vocative alone.
• You need multiple Slavic locales — this solves one language, and building per-language one-offs is a maintenance trap.
• Your dependency policy requires active maintenance, security review, or an SLA. A single-author library with no visible adoption is a supply-chain and bus-factor risk; treat it as vendored source you own, not as a vendor.
• Names are high-stakes (banking, healthcare, legal notices) — prefer conservative neutral greetings and human review over algorithmic inflection.

How to Pitch It (Stakeholders)

To executives: This is a small, cheap capability that removes a specific and visible localization failure — addressing Czech customers by the wrong form of their name in every email and notification. It is not infrastructure; it is a contained feature behind a flag, with a safe fallback to neutral greetings if it fails. Recommend a scoped pilot in the CZ lifecycle messaging flow, measured against reply, open, and complaint rates, with a two-week time box and no platform commitment. If the numbers do not move, we switch the flag off and lose almost nothing.

To engineering: Treat it as vendored source, not a dependency. Isolate it behind a NameInflector interface, pin the version, add a test corpus of real customer first names (including foreign and ambiguous ones), and default to the nominative form or a nameless greeting on any uncertainty. Budget a half-day to read the source — you will likely own the fork. Do not let it leak into templates directly; token resolution belongs in one place so we can swap implementations without touching copy.