Extracting choices not keys from forms

[ScherlOMatic]

Q	A
Bundle version	dev-master
Symfony version	3.0.3
PHP version	7.0.3

Expected behavior

The FormExtractor.php file might have an issue with handling of choicetype fields. Especially with 'choices'. It seems like the extractor is trying to translate the values instead of the keys.
The case is described in here https://github.com/symfony/symfony/blob/master/UPGRADE-3.0.md #choices_as_values

Actual behavior

After reexecuting the translation:extract command I get this message:

[JMS\TranslationBundle\Exception\RuntimeException]
You can only merge messages with the same id. Expected id "0", but got "0".

The id "0" but got "0" sounds confusing but I'm positive that this is the key of the choice field. After deleting the "0" item, i got the next one of my choices.

Steps to reproduce

Create a form with one ChoiceType field, set some values and try to extract messages twice.
I think the parseItem() function needs to be changed.

[Nyholm]

Since Symfony 2.7 (I think) Symfony changed meaning of the keys and values. This is something we really need to look into.

[ScherlOMatic]

Let me know if i can help you any further.

[Nyholm]

Yes, please. Do you have any suggestions how to solve it?
If you are using Symfony 2.8 you probably have forms in both the new format and the old format. How can we figure out what format to use? Should we use a new annotation?

[ScherlOMatic]

I narrowed it down to Line 123 within FormExtractor.php.
The $sitem has the 'wrong' key value fields. But that's more a symfony specific problem rather than a jms/translation-bundle one.
I'm trying to switch the key with the value field now, but idk how. $sitem is of type PhpParser\Node\Expr\ArrayItem

We could also achieve it by passing a 3rd parameter to parseItem() But I think that's unnecessary unless you wanna make the bundle running for both versions. And chaning more lines within the parseItem function.

Using annotations would confuse most ppl.

My solution would be:

1. a global parameter for retrieving the symf version
2. looking for specific options like 'choices_as_values' and so on
3. switching the 'key' and 'value' with each other.

For a symfony 3.0 solution we only need 3)

thx

[Koalabaerchen]

Stumpled upon the same problem (I think) in a project with lots of forms with lots of choices in 2.7.11 with choices_as_values = true.

it doesn't add them to the translation files and sometimes exits with the above mentioned error. Since this project will be moved to 3.1 soon, I cannot switch back to the old behaviour.

Error only happens if the file already exists. If I delete the file it will get created without an error (but of course without the choice-translations)

[benjamin-hubert]

Hi @ScherlOMatic and thank for reporting this issue.
It seems a good idea to me to look for the choices_as_values. If false we should switch, the key and the value.

This problem affects every version >= 2.7 if we try to avoid depreciations message so i'd suggest to release a small patch for this one before the symfony 3 version.

I'm also looking into this right now.

[benjamin-hubert]

Submitted a PR, could @gnat42 or @Nyholm review it ?

[Nyholm]

Closed by #334