Pluralize Bundle Laravel Package

Getting Started

This is a Symfony bundle (not a Laravel package) that wires Illuminate's Pluralizer into Symfony's service container and exposes it to Twig. If you're coming from Laravel, the underlying engine is the same Illuminate\Support\Pluralizer you already know from str_plural()/Str::plural(), so the word rules will feel familiar — only the integration layer is different.

1. Install it

   composer require mrgoodbytes8667/pluralize-bundle
   

   As of v2.2.0, the bundle officially supports Symfony 7 (previously it topped out below that). Check composer.json in the repo for the full supported Symfony/PHP matrix before committing — the Symfony 7 constraint may come with an elevated PHP requirement.

2. Register the bundle in config/bundles.php (Symfony Flex projects):

   return [
       // ...
       Mrgoodbytes8667\PluralizeBundle\PluralizeBundle::class => ['all' => true],
   ];
   

   The exact class name follows the bundle namespace; confirm from the repo's src/ directory if autoloading doesn't resolve it.

3. Confirm the Twig filters are available. The whole point of the bundle is template-side pluralization, so the fastest first check is a throwaway template:

   {{ 'category'|pluralize }}   {# categories #}
   {{ 'categories'|singularize }} {# category #}
   

4. Where to look first: the bundle's Twig extension class (usually src/Twig/...Extension.php) and its services.yaml. That tells you the exact filter names, whether the service is public/autowirable, and what class name to inject if you want the pluralizer in PHP instead of Twig.

First real use case: labels and headings in admin templates — "3 Categories", "Edit Category", filter dropdowns — where you currently hardcode both singular and plural strings. Replacing those with |pluralize/|singularize is the lowest-risk win.

Implementation Patterns

Template-side (the intended path).

<h1>{{ count }} {{ count == 1 ? 'item'|singularize : 'item'|pluralize }}</h1>
{# or, if the bundle exposes a count-aware filter #}
<h1>{{ count }} {{ 'item'|pluralize(count) }}</h1>

Use it for menu labels, breadcrumb fragments, empty-state text ("No results", "No products"), and tabs. Keep the noun in one canonical form (singular) in the template and derive the plural, so there's a single source of truth.

PHP-side injection. If the bundle registers the pluralizer as a service, autowire it into controllers, form types, or console commands:

public function __construct(private Pluralizer $pluralizer) {}

$label = $this->pluralizer->pluralize('person');   // people
$table = $this->pluralizer->singularize('users');  // user

Prefer this over calling the static Illuminate\Support\Pluralizer::plural() directly — going through the container keeps it mockable in tests and consistent with the bundle's configuration.

Form and validation messages. Symfony form labels and constraint messages often need the noun to agree with a count. A small Twig macro that takes (count, singularNoun) and returns the full phrase keeps this logic in one place and avoids sprinkling conditionals across templates.

Entity/table-name derivation. For quick admin scaffolding or generic CRUD generators, deriving a human-readable plural label from a class basename (User → users → Users) is a clean use, but only for internal tooling — don't let it leak into user-facing copy where a human should choose the wording.

Batch/array use. Illuminate's pluralizer is per-string; if you're pluralizing many labels, loop rather than expect a bulk API. Results are deterministic and cheap, so do it in the template and let Twig's cache absorb the cost.

Fallback if the bundle misbehaves. Because the value is thin, you can drop the bundle and register your own Twig filter over Illuminate\Support\Pluralizer in ~15 lines of services.yaml + a TwigFilter. Keep that exit ramp in mind before wiring the bundle deeply into your app — it's also the cheapest way to get Symfony 7 support on an older pinned version, and vice versa.

Gotchas and Tips

• English-only. The Illuminate pluralizer is rule-based English. It will produce wrong results for other locales, irregular loanwords, and domain jargon ("feedback", "series", "data"). Never use it as the sole mechanism for translated UI — use Symfony's ICU/trans with plural-aware translation for localized strings, and reserve this bundle for internal/English-only surfaces.
• Uncountables and irregulars are limited. Words like "equipment", "information", "sheep" are handled, but your product's special nouns probably aren't. If you need custom mappings, check whether the bundle exposes Pluralizer::setUncountable()/setIrregular() (Illuminate does) — if not, you'll have to configure it yourself around the service.
• Case and casing rules. Input casing is generally preserved ("Category" → "Categories"), but compound words ("user_profile", "UserProfile") vary. Test with the exact strings your app produces, not just simple lowercase nouns.
• Filter name collisions. If you already have a pluralize Twig filter (from a custom extension or another bundle), Symfony will throw a "filter already registered" error at container build. Resolve by removing one or namespacing yours.
• Template cache. After adding/removing the bundle or editing its config, run bin/console cache:clear; Twig caches the compiled extension list.
• Composer conflicts. The bundle pulls in illuminate/support, which can collide with Laravel-flavored packages (e.g. older illuminate/* versions, illuminate/collections). If you're mixing Laravel libraries in a Symfony app, resolve the illuminate/support version constraint explicitly in your root composer.json. The Symfony 7 line in v2.2.0 may have pushed the illuminate/support requirement forward — re-run composer why-not if you're upgrading from 2.1.x.
• Upgrading 2.1.1 → 2.2.0 is low risk but not zero. It's a minor bump whose only changelog entry is Symfony 7 support, so no documented BC breaks for the Twig filters or service definitions. Still, pin the version and run your template smoke test after the bump; a dependency-constraint change is the likely thing to bite you, not the API.
• Maintenance risk. Small, low-visibility package, few releases, NOASSERTION license. The v2.2.0 release shows the maintainer is tracking Symfony majors, which is reassuring — but release cadence is still sparse. Treat it as a convenience shim, not infrastructure: vendor-pin the version, read the license file, and be prepared to fork or inline the Twig extension if it breaks on a future Symfony release.
• Debugging tip. If a filter silently renders nothing, check that the bundle is actually registered and that debug:twig lists the filter: bin/console debug:twig | grep -i plural. If the service isn't public, use debug:container to find its service ID before trying to inject it.
• Extension point. The cleanest customization is a compiler pass or a small decorator around the pluralizer service (adding setIrregular/setUncountable for your domain vocabulary), rather than editing vendor code — that's also your migration path if you replace the bundle with your own extension later.
• Testing. Add a template smoke test asserting a couple of |pluralize outputs, and run it as part of your Symfony 7 upgrade checklist. Given the thin maintenance and the fact that Symfony 7 support is the headline change of v2.2.0, that test is what catches the next breakage early.