Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Translator is required for form_widget even when tranlsation is disabled. #27589

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
QuentinCurtet opened this issue Jun 13, 2018 · 2 comments
Closed

Comments

@QuentinCurtet
Copy link
Contributor

Symfony version(s) affected: 4.1 and prior (since 6 years i think)

Description
When the translation is disabled (and the translator component not even install) and use a ChoiceType input in your form, we get the following exception :
Uncaught PHP Exception InvalidArgumentException: "The helper "translator" is not defined."

How to reproduce

  • Unistall translator component
  • Disable translation in the framework.yaml
  • Create a form with ChoiceType input
  • Set the choice_translation_domain to false

Possible Solution
In the file choice_widget_options.html.php on line 3, it would be nice to add a test on the existence of the translator component. Or check if the enable translator option in conf is set to false.

@xabbuh
Copy link
Member

xabbuh commented Sep 15, 2018

For anyone interested in working on this: We can register a kind of dummy translator if the Translation component is not enabled. You can take a look at #24358 where we implemented a similar approach for Twig-based form themes.

@yceruto
Copy link
Member

yceruto commented Sep 19, 2018

See #28523

symfony-splitter pushed a commit to symfony/framework-bundle that referenced this issue Sep 21, 2018
…allback (yceruto)

This PR was merged into the 4.2-dev branch.

Discussion
----------

[FrameworkBundle] Register an identity translator as fallback

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #27589
| License       | MIT
| Doc PR        | -

The same approach as symfony/symfony#24358, suggested by @xabbuh here symfony/symfony#27589 (comment)

**Templating Engine Context**

The Form component can be used without the Translation component.
However, to be able to use the default form themes provided by the
`FrameworkBundle` you need to have the `translator` helper to be available.

This change ensure that there will always be a `translator` helper which
as a fallback will just return the message key if no translator is present.

Commits
-------

5330f2d017 [FrameworkBundle] Register an identity translator as fallback
nicolas-grekas added a commit that referenced this issue Sep 21, 2018
…allback (yceruto)

This PR was merged into the 4.2-dev branch.

Discussion
----------

[FrameworkBundle] Register an identity translator as fallback

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #27589
| License       | MIT
| Doc PR        | -

The same approach as #24358, suggested by @xabbuh here #27589 (comment)

**Templating Engine Context**

The Form component can be used without the Translation component.
However, to be able to use the default form themes provided by the
`FrameworkBundle` you need to have the `translator` helper to be available.

This change ensure that there will always be a `translator` helper which
as a fallback will just return the message key if no translator is present.

Commits
-------

5330f2d [FrameworkBundle] Register an identity translator as fallback
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants