8000 [DX][3.0] Fix inconsistent use of translation parameters · Issue #11948 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content
8000

[DX][3.0] Fix inconsistent use of translation parameters #11948

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
wouterj opened this issue Sep 18, 2014 · 7 comments
Closed

[DX][3.0] Fix inconsistent use of translation parameters #11948

wouterj opened this issue Sep 18, 2014 · 7 comments
Labels
DX DX = Developer eXperience (anything that improves the experience of using Symfony) Translation Validator

Comments

@wouterj
Copy link
Member
wouterj commented Sep 18, 2014

The translator document uses the %...% convention for translation parameters:

I have %number% apples.

However, the Validation component uses the {{ ... }} (twig-like) syntax for translation parameters:

This value should at least be {{ minValue }} characters long.

This has confused some people already, especially when creating their own constraints:

  • Should they follow the translation or validation conventions?
  • The documentation follows the translation conventions, that seems inconsistent

I would suggest to have one standard for translation parameters and use that everywhere in the core framework.
@stof
Copy link
Member
stof commented Sep 18, 2014

to be exact, the Translator component allows you to use what you want (you don't even need to have delimiters, even if not using delimiters will be a pain for your translation team).
the only place where the % convention is enforced is when using the {% trans %} and {% transchoice %} tags in Twig (the filters don't enforce it as they call the translator directly, even though |transchoice will use %count% for the automatic parameter added for the count).
Note that this is why the validator can use {{ ... }} for its parameters.

The issue is that changing placeholders used in the validator component would be a BC break, so it cannot happen until 3.0.

Btw, the reason for this is historical. Early Symfony preview releases were using {{ ... }} for placeholders everywhere, and the convention changed when integrating Twig as it caused issues to implement the tags (as variables would be displayed by Twig in the translation source rather than letting the translator perform replacements after translating)

@wouterj
Copy link
Member Author
wouterj commented Sep 18, 2014

@stof that's why I tagged the title with "[3.0]". And I didn't talk about enforcements or strict standards, just about conventions. I think we should have one convention and use that everywhere in core 8000 , now we're using a mix of 2 conventions.

@javiereguiluz
Copy link
Member

In my opinion, using the {{ ... }} syntax out of the Twig context is confusing and we should avoid it.

@linaori
Copy link
Contributor
linaori commented Sep 18, 2014

The only reason I see which makes {{ ... }} useful, is if you were to have access to twig filters/functions in there, but I don't think that's available.

@stof
Copy link
Member
stof commented Sep 18, 2014

@iltar it is not available, because it has strictly nothing to do with a Twig syntax actually. Translation parameters are just replaced using strtr (which is also why you could technically avoid any delimiter if you don't care about your translation team becoming crazy)

@stof stof added Validator Translation DX DX = Developer eXperience (anything that improves the experience of using Symfony) labels Sep 20, 2014
@hason
Copy link
Contributor
hason commented Sep 22, 2014

We should use {...} syntax that is compatible with the MessageFormatter. See #6009

@hason hason mentioned this issue Sep 26, 2014
Merged
@guilhermeblanco guilhermeblanco mentioned this issue Sep 27, 2014
Closed
@aitboudad aitboudad mentioned this issue Jun 22, 2015
Closed
@wouterj
Copy link
Member Author
wouterj commented Jan 26, 2016

Closing, it's inconsistent but you can't change it in a BC matter.

@wouterj wouterj closed this as completed Jan 26, 2016
@aitboudad aitboudad mentioned this issue Mar 25, 2016
Merged
xabbuh added a commit that referenced this issue Sep 12, 2017
@xabbuh
feature #18314 [Translation] added support for adding custom message …
ade060e 
…formatter (aitboudad)

This PR was merged into the 3.4 branch.

Discussion
----------

[Translation] added support for adding custom message formatter

| Q | A |
| --- | --- |
| Branch? | master |
| Bug fix? | no |
| New feature? | yes |
| BC breaks? | no |
| Deprecations? | yes |
| Tests pass? | yes |
| Fixed tickets | #6009, #10152, one item in #11742, #11948 |
| License | MIT |
| Doc PR | ~ |

Commits
-------

42183b0 [Translation] Support adding custom message formatter
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
DX DX = Developer eXperience (anything that improves the experience of using Symfony) Translation Validator
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@javiereguiluz @hason @stof @wouterj @linaori
0