Skip to content

Conversation

ghost
Copy link

@ghost ghost commented Feb 19, 2018

The issue was, that an auto added translation with options like this:

{{ "Next date is #date# "|trans({'#date#':dateItem.format('d.m.Y')}) }}

resulted in

<unit id="AtArHZK">
      <segment>
        <source>Next date is #date#</source>
        <target>Next date is 2018-02-19</target>
      </segment>
    </unit>

@Nyholm Nyholm self-requested a review February 19, 2018 15:26
Copy link
Member

@Nyholm Nyholm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that this makes sense in your use case. But what if one uses keys like "foo.bar.paragraph0" instead of the English message as you are doing?

I think it would make sense to remove the last parameter and let the Message to be created without a translation.

@flolivaud
Copy link

@Nyholm i have the same issue. What's the problem if you pass the key ? I think it's better to have the key instead of nothing ?

@ghost
Copy link
Author

ghost commented May 16, 2018

We speak about autogeneration. This is the moment when I create a trans tag in template and expect the bundle to create a new entry in my translation file. Then I would go to translation file and add the translated text.
If someone would use a key like you suggest "foo.bar.paragraph0", then it would be something like this:
{{ "foo.bar.paragraph0"|trans }}
and then the autogeneration would add this:
<unit id="AtArHZK"> <segment> <source>foo.bar.paragraph0</source> <target>foo.bar.paragraph0</target> </segment> </unit>
In both cases (save id or message while autogenerating) the solution would be ok. But in case if I have parameters in translation, the autogeneration would make the described error.

In case when we use keys in template we always need to go to translation file and add the translated mesage.
In case when we use messages as keys in template it is not required to edit translation files when the autogeneration uses the key and not the message with translated parameters.

I think my fix would match every use case.

@Nyholm
Copy link
Member

Nyholm commented Jun 26, 2018

The problem with doing it like this is that there is no way of telling if this is just a placeholder or the actual translation.

@ghost
Copy link
Author

ghost commented Jun 26, 2018

I give it up.

@Nyholm
Copy link
Member

Nyholm commented Jul 3, 2018

Sorry @rawburner, I do not mean to discourage you.

I just seen that Symfony add translation by default. As I said, I think that is wrong but we should make it an opt-in feature.

Could you update this PR, that adds some bundle config to enable this feature? Possible also add the prefix feature.

@bocharsky-bw
Copy link
Member

Any progress here?

@rvanlaak rvanlaak requested review from rvanlaak and removed request for rvanlaak July 25, 2019 07:57
@welcoMattic
Copy link
Member

There's no activity here for months, and it seems to be fixed here. I close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants