Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Or_other choice label is - in multi language form #683

Closed
lognaturel opened this issue Jan 15, 2024 · 4 comments · Fixed by #687
Closed

Or_other choice label is - in multi language form #683

lognaturel opened this issue Jan 15, 2024 · 4 comments · Fixed by #687

Comments

@lognaturel
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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 lognaturel reopened this Jan 16, 2024
@lognaturel
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants