1. What is the issue? Please be detailed.
When changing the form language, jr:choice-name() does not appeared to be re-evaluated.
Swiping backwards and forwards is enough to update calculations that are triggered by a variable, but calculations without implicit or explicit triggers are never updated.
When expressions are evaluated suggests a number of points when expression will be evaluated, but we've noticed when passing static values into jr:choice-name() sometimes a calculation could go through multiple form submissions without being re-evaluated.
2. What steps can we take to reproduce this issue?
Calculate a variable with jr:choice-name() and then change the language.
3. What have you tried to fix the issue?
We've tried adding a trigger value based on the last user-selected choice in the form. This mostly works, but still requires a user-initiated change (which doesn't work, for example, if the calculated value needs to be displayed on the first page in the form).
UPDATE: I added a v2 of the test form and screen recording that more clearly shows the two failure situations, specifically:
Notice how after changing the language, neither of the calculated values have been translated.
Notice after swiping backwards and forwards, the calculated value with an implicit trigger on ${veggie} is updated, but the one based on 'carrot' is not.
Just to note, this might not be entirely correct... I think it could also be explained by jr:choice-name() running with the default form language, before the last user-selected language is applied, when starting a new form.
Thanks for reporting the issue. It is weird indeed. I've tried wrapping that note along with the calculations into a group to force recalculating but to no avail. @LN what do you think about this issue?
Sorry about the radio silence. This is annoying, indeed. Your best bet in the short term is doing what you've figured out and including the choice name lookup in a bigger expression that will force recomputation.
The engine tries to be smart about when it recomputes dynamic labels because it can be expensive to go through all of them for long forms. Currently language change does not trigger recomputation. It likely should at some point but that's probably not a simple addition.
Hi @TobiasMcNulty, @LN, @Grzesiek2010
Hint; Interesting, that (at least) in Enketo both calculations will update to the new language if the previous select is deselected, incl. the more static one: jr:choice-name('carrot', '${veggie}'). See below.
In general, it might be better that a language change will be treated as a re-calculation event, at least on "finalisation". Or does it make sense to have/store multi-language case data? (This could even be solved by referencing extra choices look-up columns.)
Are there any plans to implement jr:itext as a true function also in Enketo?
Hi @LN, @Grzesiek2010,
Might a Github entry for further discussion/development be helpful?
I think, changing the language should activate an update (at least on save or finalisation) Or can someone explain a use case where storing labels in multiple languages in the same form makes sense?
Another solution might be that if a default_language for a form is set this will lead the choice-name function.
We recently found another issue in the language context: The weekday function format-date(.., "%a") seems not to depend on the form language, but on the device/browser environment.
