feat: update language setting code to prioritize session language when available

[jpagh]

As discussed with @nonprofittechy , this commit (9c6a08c) checks the session_local special variable for a language value before checking the interview-wide al_user_language.

This commit (73d3eae) updates the event that the language dropdown calls so that the user's chosen language is stored in the session_local.

These together allows individual users to have a language selection that is unique to their session and doesn't change the interview-wide al_user_language.

If an interview is sent via URL then that still changes the interview-wide al_user_language.

[BryceStevenWilley]

These together allows individual users to have a language selection that is unique to their session and doesn't change the interview-wide al_user_language.

I think I need some more explanation of why a user would want this behavior, and why it should be the default. Is it when a user and an advocate are sharing a session, both filling out answers back and forth?

Assuming @nonprofittechy knows more about this use case.

[jpagh]

@BryceStevenWilley You're right, this was based on a discussion with @nonprofittechy and the desire to upstream this change into AL which would keep our initial blocks cleaner.

The use case is particularly multi-user interviews where the users need different languages at the same time, as this ensures that each user's preferred language is applied to only the screens that they see, even when the users are simultaneously using the interview.

[nonprofittechy]

I think I need some more explanation of why a user would want this behavior, and why it should be the default. Is it when a user and an advocate are sharing a session, both filling out answers back and forth?

@BryceStevenWilley yes, I suggested Jack make this change upstream for code we'll probably share back to AL core to handle multiple signers in an arbitrary order.

Each signer might have their own unique language, and if they're both operating on the interview at the same time, without this, you get a situation where the language changes for the opposing user.

This fits best upstream because language changes need to happen in an initial block. Docassemble doesn't handle multiple initial blocks setting the same variables cleanly. I think to get this to work right now in the interview Jack is developing, he had to add the initial block twice--at the top of the YAML and then again after the imports.

The other option would be to turn off the existing AL initial block altogether and maintain our own for this interview, but I think this could be helpful for any multiuser interview, whether just advocate/client or multiple signers.

[nonprofittechy]

@BryceStevenWilley this looks good to me but I figure one more set of eyes is good if I'm the one suggesting @jpagh make the PR

[BryceStevenWilley]

I tested a bit, and I see the use case, but it does directly put that described usecase against users revisiting their interview after logging out (or more likely being logged out by their browser) and having their language revert to the default language of the interview. Having the initial URL param be "sticky" there is good IMO.

Would be nice if we used / added some interview metadata that "this interview is a multi-user interview" and do this behavior then, instead of doing it for all interviews. But whatever y'all think is best

[nonprofittechy]

I tested a bit, and I see the use case, but it does directly put that described usecase against users revisiting their interview after logging out (or more likely being logged out by their browser) and having their language revert to the default language of the interview. Having the initial URL param be "sticky" there is good IMO.

I think we can fix this by having the in-line version of the language switcher talk to a different event, which tends to appear on the first screen of multi-lingual interviews and reflects the primary user's language. We can also encourage authors to have an interview question to choose language and have that directly set the al_user_language.

This is already fine if the user visits the interview with a lang=es URL param set though, I believe?

[jpagh]

This is already fine if the user visits the interview with a lang=es URL param set though, I believe?

Yes, I left that part the way it was:

code: |
  if enable_al_language:
    if url_args.get("lang"):
      al_user_language = url_args.get("lang")
    else:
      al_user_language = al_user_default_language

In my multi-user interview that uses an action url to bring users in, I set the session_local.al_user_language in the action if want.

[nonprofittechy]

This is already fine if the user visits the interview with a lang=es URL param set though, I believe?

Yes, I left that part the way it was:

code: |
  if enable_al_language:
    if url_args.get("lang"):
      al_user_language = url_args.get("lang")
    else:
      al_user_language = al_user_default_language

In my multi-user interview that uses an action url to bring users in, I set the session_local.al_user_language in the action if want.

I think the primary way that monolingual users will reach the interview should be from a landing page with their language pre-selected. To be fair, we don't have that setup on courtformsonline.org, but it's true on other language-specific landing pages I've worked on.

[BryceStevenWilley]

I think we can fix this by having the in-line version of the language switcher talk to a different event, which tends to appear on the first screen of multi-lingual interviews and reflects the primary user's language

That would alleviate most of my fears here. The URL param is good, but, like you mention, depends on the author having set up the ability to have language choice all the way up the 'referral stack'.

[BryceStevenWilley]

Looks good to me!