Add CookBook documentation about Field Label Translations

[smoya]

No description provided.

[wouterj]

You should remove the space between ...Extension and </...

[wouterj]

I have added some comments and some general tips:

• Change uses of we in you;
• Break a line after the first word that crosses the 72 character.

[wouterj]

You should add one =

[smoya]

I think it's all right now. Thanks!

[wouterj]

This is still not aligned correctly.

[wouterj]

@smoya it should be:

* @param FormView $view * @param FormInterface $form * @param array $options 

how it is now:

* @param FormView $view * @param FormInterface $form * @param array $options 

[smoya]

I can't find the error of alignment

[smoya]

Sorry, I've had a bad day... :)

[smoya]

And now, what is the next step?

[wouterj]

Now you wait until @weaverryan (the co-author of the symfony docs) will review and merge this PR, as this is a voluntary it will take one or two weeks (usually on friday).

[smoya]

Ok! really thanks @wouterj !

[weaverryan]

Hi Sergio!

I think this is an interesting entry - thanks for putting it together! But I do have one strategy question. Doesn't this strategy result in duplicate translations? For example, if you have a "Name" field on 2 different forms (e.g. a task form and a product form), then you would result in 2 keys (task.name and product.name) that would both have the same translation. I'm not saying this is the worst thing, I was just curious what you thought about this :).

Thanks!

[weaverryan]

Ping @smoya!

[smoya]

Sorry for not answering at the time.
It is true that there may be duplication of translations, but according to this portal can be beneficial. For example, in two different forms, which contain fields with the same name, you may need these labels are different.
I'm not trying to justify this duplication, but I mean this is sometimes useful.
By the way, it is true that it may be the case of duplication of translations, but that may be the small (depending on project) cost to pay if you want to automatically generate unique labels.

[peterrehm]

I was considering the same but I was going a different route. I wanted to provide the possibility of defining a label prefix which can be set in the form type class to still give some flexibility to the developer. The prefix is not being
applied if you set an explizit one.

So the only difference is that you can set the prefix rather than generating one automatically. I am still working on
how to handle the data prototype translation but others than that issue you can see the code there: https://groups.google.com/forum/#!topic/symfony2/b163TtHVWhE

In any case I think suche cookbook entry will be helpful because this is a common issue.

[wouterj]

I'm going to close this. @weaverryan and I decided almost 1 year ago that we should close this one, so let's do it now.

This articles explains something that is actually already implemented into the component. All strings can already be translated by using the label name. If you want to use the dot notation instead of the message notation, you should set the labels (like you see here: http://www.elao.com/blog/non-classe/a-nice-way-of-handing-form-label-translation.html ) or create an extension, like you did here. But this extension introduces more problems than it solves. For instance, it can't work with duplicate field names.

All in all, we found this a bit of a "hacky" way to do this. And the docs shouldn't be hacky, they should explain only best practises.

If someone disagrees, please comment on this issue. :)