Or_other choice label is - in multi language form

[lognaturel]

A user reports that they are seeing - instead of “Other” as the choice label when using or_other. Their form is multi-language.

I have not tried to reproduce yet and wanted to file immediately in case you have cycles before I get to it, @lindsay-stevens.

[lindsay-stevens]

It sounds like the expected behaviour:

The default language gets Other, and any other language gets - for choices, and a non-itext Specify other. for the input label. That should reliably be the case, since there's XPath assertions for this behaviour in the or_other tests in test_translations.TestTranslationsChoices.

There is a pyxform warning against using or_other with translations:

This form uses or_other and translations, which is not recommended. An untranslated input question label and choice label is generated for 'other'. Learn more: https://xlsform.org/en/#specify-other).

[lognaturel]

Ah, I forgot about all that, of course. But we changed the behavior, right? It used to be “Other” for all languages and now it’s - in languages other than the default one? Unless I’m misunderstanding something I think it would be more helpful to always output “Other”. It sounds like some projects were doing fine with that and now when they make unrelated changes to their forms this change crops up.

[lognaturel]

I apologize, it seems I wasn't careful enough with reviewing the or_other changes and didn't fully grasp the behavior change.

Prior to pyxform 2, or_other resulted in a choice with an untranslated label of Other being added in the context of a translated form and a select with no choice filter:

		<select1 ref="/data/fruit">
			<label ref="jr:itext('/data/fruit:label')"/>
			<item>
				<label ref="jr:itext('/data/fruit/apple:label')"/>
				<value>apple</value>
			</item>
			<item>
				<label ref="jr:itext('/data/fruit/banana:label')"/>
				<value>banana</value>
			</item>
			<item>
				<label>Other</label>
				<value>other</value>
			</item>
		</select1>

This is not great, but in a context where data collectors speak some English it was probably sufficient.

For a select with a choice filter, it just completely omitted the other choice.

In pyxform 2, a choice with label Other is generated for the unnamed language, whether or not that language exists already. All other languages get - as the label for the other choice.

I think the ideal behavior would be to add a choice with label Other for all existing languages and NOT introduce the unnamed language. That would be a natural upgrade from v1.x and means form edits would not further break existing usage of or_other in a multilingual form context.

[lognaturel]

@lindsay-stevens I'm taking a look at this now, do let me know if you have any concerns about the proposed behavior change.