Language Bundle Laravel Package

Getting Started

• Install with Composer: composer require elcodi/language-bundle. Because the project is archived and last released in February 2016, pin an explicit constraint (e.g. the last stable tag) rather than relying on dev-master.
• Register the bundle using the Symfony 2/3-era kernel convention, since that is the generation this package targets:

  // app/AppKernel.php
  $bundles = [
      // ...
      new Elcodi\Bundle\LanguageBundle\ElcodiLanguageBundle(),
  ];
  

  No routing import is normally needed — this bundle is primarily Doctrine mappings, entities, factories, repositories, and services, not HTTP endpoints.
• Look first at:
  • DependencyInjection/Configuration.php — the config tree and defaults for the bundle.
  • Resources/config/services.yml (and any doctrine/*.yml) — the actual service IDs and entity mappings.
  • The companion component elcodi/language — the Language entity, its factory, and repository interface live there, not in the bundle.
• Discover the real service IDs instead of guessing:

  bin/console debug:container | grep -i language
  bin/console debug:container --tag=doctrine.repository_service | grep -i language
  

  (app/console on Symfony 2.x.)
• First use case: a storefront language selector. Inject the language repository/manager, fetch enabled languages, and render them in Twig. The typical shape is:

  $languages = $this->get('elcodi.repository.language')
      ->findBy(['enabled' => true]);
  

  Confirm the exact ID with debug:container; Elcodi convention is elcodi.repository.language, elcodi.factory.language, and a manager service, but verify against services.yml.

Implementation Patterns

• Read path (storefront selector). Pull the repository from the container, filter on enabled, and pass a plain array to the template. Cache the result if it is requested on every page; language lists change rarely.
• Write path (admin CRUD). Use the factory to instantiate a Language, set ISO code and name, then persist via the manager/repository rather than constructing the entity with new. This keeps you compatible with the component's invariants and any future entity overrides.
• Active-language handling. Keep the bundle's entity as the source of truth for which language is enabled, and implement a small request listener/subscriber that reads a session value or route parameter and calls $request->setLocale(...). Do not expect the bundle to set the Symfony locale for you — it models the domain object, not the request lifecycle.
• Integration with locale. Map the Language ISO code to a Symfony locale string in your own service. This is where a thin adapter pays off if ISO codes and locale strings diverge (e.g. en vs en_US).
• Entity overrides. If Elcodi's resolve_target_entities convention is used in the component's configuration, override the concrete Language class in config.yml and have your class extend the base entity. This is the cleanest extension point and avoids editing vendor code.
• Forms and admin. If a form type ships with the bundle, reuse it; otherwise build a minimal one against the entity. Do not assume validation constraints are bundled.
• Testing. Write a functional test that boots the kernel and asserts the repository returns only enabled rows. Given the abandoned state, your test suite becomes the de facto specification.

Gotchas and Tips

• It is end-of-life and read-only. No pull requests are accepted in this repository — issues and PRs belong in the main elcodi/elcodi package. Treat any bug you find as yours to patch locally or fork.
• Security and dependency drift. A 2016 release pins old Symfony/Doctrine ranges. Installing it in a modern app is likely to require dependency juggling or is simply incompatible; do not put this on a new project.
• Unstable alias. The README advertises dev-master as "last commit" — that is exactly what you do not want in production. Always pin a tagged version or a commit hash.
• Language vs Locale confusion. The entity represents a selectable catalog/UI language. Symfony's locale is a formatting concern. Conflating them causes subtle bugs (number/date formatting changing when a user switches UI language).
• Forgetting the enabled filter. The repository will happily return disabled languages; filter explicitly everywhere you render a selector or validate a submitted code.
• Doctrine metadata cache. After changing entity overrides or the config tree, clear the cache (bin/console cache:clear) and, if needed, regenerate proxies. Mapping problems show up as "class not found" or missing-table errors at runtime, not at container compile time.
• Config quirks. Inspect Configuration.php before writing YAML — undocumented defaults and required nodes are common in this generation of bundles. A wrong config key can be silently ignored or throw an opaque InvalidConfigurationException.
• Service IDs are the API. There is little public documentation that survives; the container is your documentation. debug:container --show-private and debug:container <id> are more useful than the stale docs.
• Extension point priority. Prefer (1) config-based entity override, then (2) decorating the manager/repository service, and only then (3) forking. The first two survive Composer updates better than editing vendor files.
• Don't expect long-term support. Budget for eventual replacement of the language model with your own entity if the project outlives the archived dependency.