683: select or_other label is "-" in multilanguage form not "Other"

[lindsay-stevens]

Prior to using secondary instances for all selects, the default label for the or_other shortcut was "Other" in all languages. Despite the various warnings, users wanted the old behaviour to be retained. The exception is that if a user has defined an "other" choice for the or_other choices, then any blank translations labels ("-") will not be replaced with "Other".

Closes #683

Why is this the best possible solution? Were any other approaches considered?

I tried to find a way to offload the logic to survey.py because that is where translations and missing defaults are done, but it became quite messy. Basically the OR_OTHER choice had an extra attribute "_or_other": True and this was used to trigger special processing when setting up translations and overriding the default missing translation -.

This PR is similar to #684. It seems like builder.py is the best place to add this code because it's where the or_other input item is injected, and where the regular or_other choice is added. Differences from #648:

• In _add_other_option_to_multiple_choice_question, the choice name should match other exactly instead of other being anywhere in the choice name (e.g. smothers).
• Changed new method name to _get_or_other_choice since it might not be translated.
• In _get_or_other_choice:
  • check all choices (not just the first, which has been a topic of previous bugs) to see if the choice list should be considered multi-language.
  • handle the possibility that the choice has no label i.e. for a choice with a missing translation
  • replace usages of map with set/dict comprehensions
• The error about using choice filters with or_other is not removed, because part of why that is there is because users have no way to apply filtering for the other choice since it doesn't exist in the form. This is still true with pyxform v2. Maybe should be discussed further for a separate PR.
• The or_other related tests are put into a new TestCase class, to help visually separate them from others. This is preferable to the proposed use of region comments because region doesn't seem to work for Intellij (which I use), and grouping tests by TestCase class (which can be folded in Intellij) or test_...py module file is a more standard way to organise tests.

What are the regression risks?

The only one that comes to mind is that as mentioned above, if a user has defined an "other" choice for the or_other choices, then any blank translations labels ("-") will not be replaced with "Other".

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No

Before submitting this PR, please make sure you have:

• [x] included test cases for core behavior and edge cases in tests
• [x] run nosetests and verified all tests pass
• [x] run black pyxform tests to format code
• [x] verified that any code or assets from external sources are properly credited in comments

[lognaturel]

users have no way to apply filtering for the other choice since it doesn't exist in the form.

I imagine "Other" would generally be desirable for any filtered list. But we also shouldn't expand the capabilities of functionality we want to discourage so I agree with taking it out.

The or_other related tests are put into a new TestCase class, to help visually separate them from others.

Yes, great.