👌

👍 looks good, but for 2.8

PR updated with the addition of transChoice (capture image updated in the main post).

It look like I must close this PR and re-open on 2.8?

@damienalexandre we can rebase it on top of 2.8 at merging time with our merging tool (assuming there is no conflict), so it is not necessary. This would mark the PR as closed rather than merged though because of the rebase

How does it behave when the same key is translated several times but with different parameter values (and potentially even different parameters) and a different pluralization count ?

This code:

<p>{{ 'demo.homepage.introduction'|trans({'%username%': 'Damien'}) }}</p>
<p>{{ 'demo.homepage.introduction'|trans({'%username%': 'Toto'}) }}</p>

produce this output:

Only the first call is kept (see TranslationDataCollector::sanitizeCollectedMessages), so we only have the parameters used in the first one. For this reason I'm not sure about using =, because it's more like "could be this value"... Two solutions:

• I improve sanitizeCollectedMessages to keep all the parameters and I display them all
• I change the = in the view to reflect the fact this is only an extract, any idea how to do that?

What do you think?

@damienalexandre I'm actually wondering whether the value of the parameter should really be kept here (same for the pluralization count). What we really care about IMO is which parameters are available, and whether it is pluralized or no.

keeping all parameters values would also look confusing IMO

Instead of adding a new column I would propose grouping parameters like we did in doctrine which can fix the confusion

Having the parameters values proved to be really helpful on the project I'm working on.
For example you could need to check that a date is properly formatted before the translation actually use the key:

So I'm in favor of @aitboudad idea, specially because the folding table allow to display lots of information's without breaking the display to much.

Here is what I've just pushed. For this code:

<p>{{ 'demo.homepage.hello'|trans }}</p>
<p>{{ 'demo.homepage.user_friends'|transchoice(5, {'%name%': 'Fabien'}) }}</p>
<p>{{ 'demo.homepage.user_friends'|transchoice(0, {'%name%': 'Fabien'}) }}</p>
<p>{{ 'demo.homepage.time'|trans({'%datetime%': 'now'|date}) }}</p>
<p>{{ 'demo.homepage.introduction'|trans({'%username%': 'Damien'}) }}</p>
<p>{{ 'demo.homepage.introduction'|trans({'%username%': 'Toto', '%foo%': 'bar'}) }}</p>

It produce this in the translation panel:

Expended it looks like this:

As you can see I use the dump function,
not sure this is accepted but the colors and the display are very very good, I wish more panels use this function to display data.

Let my know what you think,
cheers 🤘

@damienalexandre Using dump() everywhere in the profiler would be a huge win! That would also allow to deprecate and then remove a bunch of code. I like that! Can you work on that?

using dump() everywhere should be done in another PR.

Ok so I replaced my dump by profiler_dump, and another PR will take care of replacing all the profiler_dump and remove the code needed for it.

Here is what is looks like now:

ping @symfony/deciders

👍

Should we really include the parameters part if there were no parameters passed to trans()? Imho it is confusing to then see null there.

I agree with @xabbuh: displaying null when there are no parameters looks like an error (made by Symfony or our application).

Ok, I mentioned before why I made it this way,
I need to find a way to make sure all the calls for a specific message don't have any parameters. Thanks for the feedbacks!

Maybe it's sufficient to just show a message telling "no parameters" or something similar.

Here we go; I've change the way I store the parameters in the DataCollector to allow a better display.

Here is an example where the first call does not have parameters, so we do not display the expend link, and where the last translation is called 3 times but only have parameters 2 times:

Looks better 👍 Good feedback 😉

Thank you @damienalexandre.