Jolitypo Laravel Package

Product Decisions This Supports

• Content quality feature — typographic polish. Ship an automatic "professional typography" pass across CMS pages, blog posts, marketing landing copy, and transactional emails, removing a recurring manual editing chore (curly quotes, em dashes, ellipses, non-breaking spaces). This is a low-risk, high-visibility quality win rather than a new capability.
• Localization roadmap. The locale-aware rule set is the strongest product hook: French typography (non-breaking space before : ; ! ?, « » guillemets), English conventions, and others. If the product roadmap includes FR/EN/EU expansion, this supports a "locale-correct publishing" story and reduces locale-specific editorial QA before launch.
• Generated-document surfaces. Invoices, quotes, contracts, PDF exports, and notification emails are all rendered from templates where typography is otherwise neglected. This package is a cheap polish layer that improves perceived product quality in documents customers forward to their customers.
• Build vs. buy: buy. Typographic correction is deceptively fiddly — quote pairing, context-sensitive apostrophes, HTML tag/attribute safety, and per-locale spacing rules are a long tail of edge cases. A maintained MIT library with an extensible fixer system is cheaper than owning that tail in-house, and the license removes lock-in concerns.
• Architecture decision: apply at render or on save. Decide deliberately. Render-time (Blade directive / response middleware) keeps source content pristine and lets rules evolve; save-time keeps storage canonical but bakes in current rules and complicates re-processing. Recommend render-time for user-authored HTML, save-time only for controlled template copy.
• Scope guardrail. This is a presentation fixer, not a translation, grammar, or sanitization tool. Product decision to make explicit: it must never run over code blocks, <pre>, attributes, or stored user data used in non-display contexts (search indexing, diffs, exports to third parties that expect verbatim input).

When to Consider This Package

Adopt when:

• The product displays human-authored prose in HTML or plain text and typography quality is part of the brand (publishing, e-commerce content, SaaS marketing surfaces, email templates, generated PDFs).
• You are shipping or already support multiple locales, particularly French, where incorrect spacing before punctuation is immediately noticeable to native readers.
• You want a single, tested rules engine rather than a growing pile of regexes scattered across Blade templates and formatters — and you value the extensible fixer model for house style rules (e.g., mandatory non-breaking spaces in product names, brand-specific dash usage).
• You generate documents from template strings inside Laravel, where a one-line transform before rendering is trivially cheap.
• Your PHP/Laravel stack is modern enough to consume a standalone Composer package without a first-party service provider — expect to write a small wrapper (service provider binding, Blade directive or cast) as glue.

Look elsewhere or defer when:

• Content is not prose. Dashboards, numeric tables, logs, JSON APIs, or machine-consumed payloads gain nothing and risk corruption.
• You need translation, grammar correction, or spell-check. Different problem class — evaluate a localization platform or grammar API instead.
• The pipeline is not PHP. If content is rendered by a Node/Go service, Python report generator, or a headless CMS edge worker, adopting this creates a second typography implementation and divergent output.
• Your HTML is hostile. Heavily malformed or script-laden user HTML should be sanitized first; layering typographic transforms on unsanitized input is the wrong order of operations.
• Verbatim fidelity is contractual. Legal text, user-generated content that users may compare byte-for-byte, or content round-tripped through an editor must not be silently mutated.
• Maintenance risk tolerance is very low. ~350 stars is a modest community; MIT licensing caps the downside (you can fork), but pin the version, add characterization tests over your own content corpus, and avoid depending on undocumented fixer behavior.

How to Pitch It (Stakeholders)

To executives (30 seconds). We can raise the perceived quality of everything customers read — website copy, emails, invoices, PDFs — for roughly a day of engineering, using a free, permissively licensed PHP library. It fixes the typographic errors that make polished products look amateur: straight quotes, double hyphens instead of em dashes, missing spaces before French punctuation. No new vendor, no new infrastructure, no user-facing workflow change. The business case is brand consistency and reduced editorial cleanup, especially as we expand into French-language markets where these details are conspicuous.

To engineering (the actual ask). jolicode/jolitypo is a standalone, MIT-licensed text transformer with locale-aware fixers and HTML-aware processing that skips tags and attributes. We add a thin adapter — a service provider binding plus either a Blade directive or a response middleware — and apply it to designated prose surfaces only. Key constraints we will respect: never run it on <pre>/code, JSON, or machine-consumed payloads; run sanitization before typography; add fixture-based tests using our real content so rule changes are caught on upgrade; pin the version. It is not a localization framework and does not replace our translation pipeline — it makes the output of that pipeline typographically correct per locale.

Risk statement. Low. MIT license means no lock-in; the integration is a wrapper we could reimplement, and we isolate it behind a single facade so it can be swapped. Primary risk is misapplication (mutating content that must stay verbatim), which we mitigate by scoping to an explicit allowlist of surfaces rather than applying it globally.