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

Skip to content

[2.1][TwigBridge] trans_default_domain fails in blocks #6747

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.

Sign up for GitHub

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

Jump to bottom
Closed
havvg opened this issue Jan 15, 2013 · 9 comments
Closed

[2.1][TwigBridge] trans_default_domain fails in blocks #6747

havvg opened this issue Jan 15, 2013 · 9 comments
Labels
TwigBundle

Comments

@havvg
Copy link
Contributor

havvg commented Jan 15, 2013

When using {% trans_default_domain %} in a block, it beaks if there are other blocks defined afterwards. The error message reads

Variable "__internal_a63b4832003a5ba69db62eddb8e1cb11cc847ce6" does not exist in ..

This one breaks:

  • The parent template is not a problem, the issue occurs without a parent, too.
  • The domain names aren't a problem, changing those has no effect.
{% extends ... %} 

{% trans_default_domain "some_domain" %}

{% block content %}
    {{ block('progression') }}
{% endblock %}

{% block breadcrumb %}
    {% trans_default_domain "breadcrumb" %}

    {# Rendering breadcrumb .. #}
{% endblock %}

{% block progression %}
    {% set name = 'foo' %}

    {{ name|trans }} {# breaks #}
{% endblock %}

while this one is just fine:

{% extends ... %} 

{% block content %}
    {{ block('progression') }}
{% endblock %}

{% block progression %}
    {% set name = 'foo' %}

    {{ name|trans }} {# just fine #}
{% endblock %}

{% block breadcrumb %}
    {% trans_default_domain "breadcrumb" %}

    {# Rendering breadcrumb .. #}
{% endblock %}
@sstok
Copy link
Contributor

sstok commented Jan 15, 2013

From what I know the trans_default_domain applies to whole file not just one block.

@havvg
Copy link
Contributor Author

havvg commented Jan 17, 2013

No, it's working fine in other circumstances, it can be contained in a block.

@jfsimon jfsimon mentioned this issue Mar 6, 2013
Closed
fabpot added a commit that referenced this issue Mar 12, 2013
@fabpot
merged branch jfsimon/issue-6747 (PR #7281)
e508ecc 
This PR was squashed before being merged into the 2.1 branch (closes #7281).

Commits
-------

e3547c6 [TwigBridge] fixes

Discussion
----------

[TwigBridge] fixes `TranslationDefaultDomainNodeVisitor`

... by adding scope management.

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6747

---------------------------------------------------------------------------

by vicb at 2013-03-06T15:14:57Z

Are `open` and `close` good names ? I would prefer `addChild` and `getParent` as there is nothing that is really opened or closed ?

Edit: by looking at the code a second time, I think open & close make sense .

---------------------------------------------------------------------------

by jfsimon at 2013-03-07T13:46:13Z

@vicb I know this is not consistent with the rest of the framework.
I dont think @fabpot will like them.

---------------------------------------------------------------------------

by stof at 2013-03-07T13:53:14Z

what about enter and leave ? It would be consistent with the naming used for scopes in the DI component

---------------------------------------------------------------------------

by vicb at 2013-03-07T13:59:35Z

@stof I like your proposal. My main concern being "leave" (former "close"), @jfsimon could you throw when a scope is used after it has been left ?

---------------------------------------------------------------------------

by jfsimon at 2013-03-07T14:01:56Z

go for enter/leave, but why throwing an exception on using a leaved scope?

---------------------------------------------------------------------------

by vicb at 2013-03-07T14:05:22Z

because if you have a ref to a left scope, you can still use it which is bad
@fabpot fabpot closed this as completed Mar 12, 2013
@rdohms
Copy link
Contributor

rdohms commented Dec 10, 2013

This may be related, wondering if anyone has any clues on it

My template (which is included via include) has this statement (below) in it and this throws the same kind of internal var does not exist error.

Seems the trigger is trans_default_domain being inside the if.

{% if translation_domain is defined %}{% trans_default_domain translation_domain %}{% endif %}
{% if close is not defined %}{% set close = false %}{% endif %}

{% for flashMessage in app.session.flashbag.get('alert') %}
    <div class="alert alert-warning">
        {% if close %}<button type="button" class="close" data-dismiss="alert">&times;</button>{% endif %}
        {{ flashMessage|trans() }}
    </div>
{% endfor %}

@havvg any ideas as to why?

@stof
Copy link
Member

stof commented Dec 10, 2013

@rdohms the {% trans_default_domain %} is processed at compiled time. So wrapping it in an if will not help making it conditional, as condition are only evaluated at runtime

@rdohms
Copy link
Contributor

rdohms commented Dec 10, 2013

@stof that makes sense. Does this work as you woudl expect it to?

{% trans_default_domain translation_domain|default(null) %}

@stof
Copy link
Member

stof commented Dec 11, 2013

This would probably work, yes (except that null is not acceptable as translation domain IIRC)

@rdohms
Copy link
Contributor

rdohms commented Dec 11, 2013

@stof it seems to be the only value that triggers the desired behaviour, which is, ignore this tag if nothing is set. Empty string is a valid domain so its breaks, and setting to "messages" is a bit too hardcoded to be safe. So it seems at least to my tests that setting it to null will make the tag not have any effect. Thnks!

@stof
Copy link
Member

stof commented Dec 11, 2013

hmm, actually, null is valid: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Translation/Translator.php#L174

@rdohms
Copy link
Contributor

rdohms commented Dec 11, 2013

@stof, yes but it triggers the intended behaviour, which is "use the
default"

Rafael Machado Dohms

Developer, Evangelist, Gamer
http://doh.ms http://doh.ms

On Wed, Dec 11, 2013 at 11:05 AM, Christophe Coevoet <
[email protected]> wrote:

hmm, actually, null is valid:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Translation/Translator.php#L174

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6747#issuecomment-30307752
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
TwigBundle
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@fabpot @rdohms @havvg @stof @sstok