Typograph Bundle Laravel Package

Product Decisions This Supports

• Setting a typographic quality bar for rendered content. The package exposes one capability — automatic Russian typography correction (smart quotes «», em/en dashes, ellipses, non-breaking spaces, hanging punctuation) — behind a single filter: {{ content | typograph }}. That forces an explicit product decision: is typographic correctness a first-class quality signal for customer-facing copy, or a cosmetic nice-to-have we defer? For Russian-language editorial surfaces, the answer is usually the former.

• Build vs. buy for a non-differentiating utility. This is a thin Symfony adapter around E. Muravjev's Typograph algorithm (mdash.ru), not an original implementation. The real decision is whether to depend on a third-party algorithmic text transformer or own ~a few hundred lines of regex rules in-house. Since typography is not a competitive moat, buying (or vendoring) is the defensible default.

• Where the work lands on the roadmap. Best fit is editorial/CMS surfaces: article bodies, comments and reviews, product descriptions, marketing email templates, and generated PDFs/invoices. This is a "polish sprint" item, not a platform initiative — scope it accordingly.

• Localization depth beyond translation strings. Typography rules are locale-specific. Adopting a rule-based typographer is a visible, low-cost lever for perceived quality in Russian-speaking markets and a concrete signal that localization investment goes past string tables.

• Dependency posture for a low-stakes component. 0 stars, 0 dependents, last release December 2021, and a Symfony 4-era AppKernel.php registration model. That combination makes this a vendor-or-fork candidate, not a long-term platform dependency — which is itself a product decision about acceptable supply-chain risk for a utility we could replace in a day.

• Cheap-to-reverse trialing. The feature is a pure, stateless string transformation with no schema, no migration, and no persistent state. It isolates cleanly behind an interface, so the cost of adopting and abandoning it is near zero. That is an argument for a short spike rather than a long debate.

• Caching and storage architecture. Because typographing is regex-heavy, the decision to format at read time versus precomputing a body_formatted column (filled by a queued backfill) is a product-visible performance trade-off — typically the difference between a ~40 ms and a ~4 ms list-page render. Worth an explicit decision before launch, not after.

When to Consider This Package

Consider it when:

• Your content is Russian-language (or follows similar Eastern European conventions) and you need rule-based correction — quotes, dashes, non-breaking spaces, hanging punctuation — rather than a hand-rolled find-and-replace.
• The blast radius is purely cosmetic. If the typographer no-ops or fails, the article still renders, just less elegantly. That failure mode is acceptable for marketing and editorial surfaces; it is not for anything contractual or legal.
• You are willing to fork or vendor. Given zero dependents, a 2021 release, and the it-blaster → meniam rename, pin the exact version, commit the lockfile, and plan for the upstream to vanish.
• You have UTF-8 end-to-end and can lock locale/charset explicitly. Silent no-ops from mismatched encoding are the most common failure and look like a typography bug.

Look elsewhere — or use the underlying library directly — when:

• You are on Laravel. This is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no auto-discovery. Copy-pasting the README's {{ content | typograph }} into Blade produces a syntax error, not a typography fix. In Laravel, take meniam/typograph (the underlying library) and bind it behind a singleton plus a helper or Blade directive — roughly 30 minutes of reading vendor/.
• Your content is English-only. Marginal benefit, occasional weirdness. Not worth the dependency.
• You need it to run over HTML. Typograph works on plain text; run it before Markdown conversion or on plain-text nodes only. It will mangle attributes, alt text, and code blocks — and it will happily rewrite --> and straight quotes inside code samples.
• You expect platform features. There is no middleware, no queue integration, no caching, no event hooks. Everything operational is yours to build.
• You need active maintenance or vendor support. You will not get it.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a small, MIT-licensed utility that automatically applies correct Russian typography — proper quotation marks, em dashes, non-breaking spaces — to rendered content. It is a quality-polish feature for editorial and marketing surfaces in our Russian-language markets, reversible in a day, and costs nothing to license. The caveat is that the open-source project is effectively unmaintained, so I recommend we vendor a copy rather than take it as a live dependency. Expected effort: small, contained to rendering.

To engineering (the ask): This is a Symfony bundle, not a Laravel package — treat it as a reference implementation, not a drop-in. Two paths: (a) vendor the bundle and adapt its Twig extension and DependencyInjection/Configuration.php into a config/typograph.php plus a TypographService singleton and a @typograph() Blade directive, or (b) skip the bundle entirely and depend on meniam/typograph directly behind that same service. Path (b) is my recommendation — fewer moving parts, one less abandoned wrapper.

Non-negotiables before we ship:

• Pin the exact version, commit composer.lock, and assume we may need to maintain a fork.
• Explicitly set locale and charset; encoding must be UTF-8 across MySQL, request, and typographer.
• Format on read (accessor) or into a separate _formatted column via a queued backfill — do not mutate the stored source. Typography is presentation, not storage; editors need their raw text back.
• Whitelist the fields/rich-text nodes that get typographed. Never run it over code, URLs, emails, or JSON.
• Assert on a known fixture ('"Привет" - мир' → '«Привет» — мир') in a unit test. These libraries tend to return input unchanged on internal error rather than throwing — "no exception" does not mean "it worked."
• Capture 20–30 real content samples before and after, and diff them. Non-breaking spaces are invisible; regressions ship unnoticed otherwise.

What success looks like: a visible lift in editorial polish on Russian-language surfaces, zero change to stored data, and a component we could rip out in an afternoon if it disappoints.