Jolitypo Bundle Laravel Package

Product Decisions This Supports

• Typography as a shippable quality bar, not a nicety. JoliTypo automates typographic correctness (non-breaking spaces before : ; ! ?, French quotes, ellipses, dashes, hyphenation) so rendered content reads as professionally edited without manual proofreading. A PM can now treat "typographic polish" as a spec line item with a known-cost implementation behind it.
• Build vs. buy for text post-processing — re-opened. A stable 1.0 bundle changes the calculus: instead of "write our own normalizer or use the bare library and wire it ourselves," there is now a versioned integration layer with a stability commitment. For French-first editorial products (CMS, publishing, e-commerce descriptions, transactional emails) this is a deterministic rules engine, orders of magnitude cheaper and more predictable than an LLM rewrite step.
• Where in the pipeline typography gets fixed. The bundle's existence answers the integration question (Symfony service + Twig filter), not the architecture question: fix at render time, at write time (persist normalized HTML), or in a queue. That choice has real product consequences — idempotency, search indexing, diff noise in editorial history — and should be decided explicitly, not inherited from whatever the bundle makes easiest.
• Roadmap signal — this is the material change. The previous read was "archived, deprecated, do not adopt." A 1.0 release explicitly aligned to upstream JoliTypo reaching stability reverses that signal: the project is being maintained again, and the integration layer is now a supported artifact rather than dead code. The decision it supports flips from removal to evaluate for adoption.
• Locale/SEO/content-integrity use cases. Correct non-breaking spaces and quotation marks affect line breaking and perceived quality in SERP snippets, PDF exports, and email clients — useful for sizing content-rendering debt in localization-heavy products.

When to Consider This Package

Consider it if:

• You run a Symfony application (verify the supported version range in composer.json before committing — the 1.0 notes state stability, not a support matrix) and want typography normalization as configuration rather than custom code.
• Your content is French-language or French-typography-sensitive and you want a rules-based, offline, zero-latency normalizer instead of an external API call on the render path.
• You were previously blocked only by maintenance risk. A tagged stable release with an actively stabilized upstream is exactly the objection this release answers — re-run the evaluation you skipped.
• You want a bounded spike: days, not weeks, to prove out quality on real content before deciding whether to persist normalized HTML or normalize at render.

Look elsewhere if:

• You are not on Symfony, or you are on a Symfony/PHP combination outside the bundle's declared support range. Use JoliTypo directly — the value remains in the library; the bundle is convenience wiring.
• Your typography needs are broad multi-locale (German, English, CJK) or require structural HTML editing. A rule-substitution engine will not fix markup, and an editor-side/WYSIWYG solution may be the better product bet.
• You need typography applied to user-generated content at scale. Validate escaping, DOM handling, and malformed-HTML behavior yourself; a 1.0 tag is not a security audit.
• Your procurement process requires a long track record or a large maintainer base. 1.0 is a credible restart, not a decade of history — treat maintainer capacity and release cadence as open questions.

Verification checklist before adoption: supported Symfony/PHP versions; whether the repository is still flagged archived; whether the 1.0 API is compatible with any 0.x wiring already in the codebase (breaking changes are implied by a major bump but are not documented in the release notes); idempotency on already-normalized content; MIT license unchanged; no transitive dependency on a stale integration.

How to Pitch It (Stakeholders)

For executives (one paragraph): JoliTypo is a small, MIT-licensed rules engine that fixes French typographic details — non-breaking spaces, quote marks, ellipses — automatically in rendered content: a real quality improvement at near-zero runtime cost. The relevant news is that the Symfony integration bundle has shipped a 1.0 stable release, explicitly tied to the upstream library reaching stability, which retires the "abandoned, do not touch" verdict we carried previously. Recommendation: re-open the decision rather than adopting on the release note alone — approve a short, timeboxed spike (days, not weeks) to confirm the supported Symfony/PHP versions and measure output quality on our actual content. If it holds up, adopt the bundle for French-typography-sensitive surfaces (localized content, publishing, email); if it doesn't, we've spent days to close a question that has been open for years. Either way, we exit with a documented position instead of an inherited one.

For engineering (the same, concretely): The 1.0 note is a single line — "first stable release of the bundle, as JoliTypo is also stable now." It signals renewed maintenance and implies a major-version break from the 0.x line, but it documents no changelog, no support matrix, and no migration path. Concretely: (1) read composer.json for the Symfony/PHP constraint and check the repo's archived status; (2) diff the 1.0 service definition and Twig extension against any existing 0.x wiring and against the maintained bridge, so we know whether the bundle now adds anything beyond convenience; (3) decide the integration point deliberately — persist-time normalization is generally better than render-time for search indexing and editorial diffs; (4) test idempotency on already-normalized HTML and behavior on malformed markup; (5) confirm no transitive dependency on the old abandoned artifact. Treat the library as the durable asset and the bundle as replaceable glue — if the bundle regresses, we can drop to direct library usage without changing product behavior.