do not translate language options on post box

[e-five256]

pages that loaded the reply/comment/post box had 634 translation misses (and likely each time it was added to the page). this was because it attempted to translate the language labels, but languages should not be translated but spelled using their own language

I'm still not quite sure I fixed this properly, as I'm not sure what the ternary if was trying to accomplish

[e-five256]

I'm not quite understanding what choice_translation_domain is meant to represent in this file. I don't think it's being used from the controller, unless I'm looking in the wrong place which is possible. Maybe it was meant to be choice.translation_domain, on the iterator? As there are instances of translation_domain

edit: doesn't seem to exist on this particular iterator though so I guess that's not it, will have to investigate more

[e-five256]

ah it's coming from https://symfony.com/doc/current/reference/forms/types/language.html#choice-translation-domain which is what I was missing

[e-five256]

After a bunch of investigation, I think I understand what happened now.

First, choice_translation_domain always appears null on pages I can find this lang select form on (single entry, inline reply, profile, microblog). As null does not match false, it goes into the translate filter with the default language as described in the docs I linked above.

After trying to figure this out, I stumbled on the default twig form select layout, which this almost matches, which made me realize the comment at the top of this template is saying just that, it's a near copy of the twig select form.

So now I wasn't quite sure the best way to handle this: Removing this code strays further from the default template, but we should know the languages will never translate, which is all this component is for, so I'm not sure if that causes issues aside from making it more custom.

An alternative might be to see if the default twig component has fixed any issues to preferred choice this template mentions.

(On the same note, choice is never iterable so we could remove that check as well if we wanted, there were no instances I saw of the lang select having optgroup blocks. But that seemed less needed.)

[nobodyatroot]

I think this has been open for comment long enough, I don't see any reason to hold it back.