LF-5318 (2) Address 'null' user.language_preference for newly invited users

[kathyavini]

Description

Unfortunately I came to the wrong conclusion on #4186 this morning! The fact that there is no 'null' language_preference records on beta or prod was because the ability to create them came from the LF-5318 change. After that change, 100% of invited new accounts will show that pattern, so it needs to be fixed before patch.

There were a lot of errors in this invite account creation flow, but the closest proximate cause was the failure of this line:

// containers/Callback/index.jsx
patchUserFarmStatus({
  invite_token: params.get('invite_token'),
  language: params.get('language'), // <-- always returns null
 }),

It looks like that params.get() fails because of how the &language is escaped, but I don't know if that is a change that happened since this logic was first written, or if it has never worked.

When language can't be taken from the URL like this, the saga payload language is also null, and litefarm_lang gets set as 'null' in patchUserFarmStatusSaga():

// containers/Callback/saga.js
const { invite_token, language } = payload;

// ...
localStorage.setItem('litefarm_lang', language); // <-- local storage value now string 'null'
i18n.changeLanguage(language) // <-- original code; overwrites value to 'en'

When i18n.changeLanguage was changed to be called conditionally, that changeLanguage was skipped and the local storage value was never overwritten, exposing this bug.

One side effect of this is that what looks like the intended language setting (= matching the language selected for the invite email, in the case of a new account) was never applied. After accepting an invite, no matter the language of the invite email, the LiteFarm UI is rendered in English.

This PR will repair that, so now LiteFarm show the accept invitation UI in the same language as the accept invitation email.

Summary of Changes

• removes the failing language param (no longer appends it, and no longer reads it)
• updates the language_preference already passed in the invite token to the one that matches the inviting language
• removes a misleading destructure and no no-op patch in userFarmController.js to make the actual behaviour of the flow more transparent

Jira link: https://lite-farm.atlassian.net/browse/LF-5318

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Passes test case
• UI components visually reviewed on desktop view
• UI components visually reviewed on mobile view
• Other (please explain)

Tested SSO + password account creation via invites to trace language in this flow.

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The precommit and linting ran successfully
• I have added or updated language tags for text that's part of the UI
• I have ordered translation keys alphabetically (optional: run pnpm i18n to help with this)
• I have added the GNU General Public License to all new files

[kathyavini]

Not to be confused with userController.acceptInvitationAndPostPassword (the controller downstream of filling out the InvitedUserCreateAccount form), the language_preference here is non-existent; both acceptInvitation() and acceptInvitationWithAccessToken() are called from the frontend without a req.body, so the patch below was always a no-op.

Not related to the bug (since it did nothing), but removed only because it's misleading.

[kathyavini]

user.language_preference is the sender's selected language in the case of a new account, and the actual user.language_preference for an existing account.

In the existing account case there is no difference between this and the userFarm value, but for a new account userFarm.language_preference is always 'en' and was over-writing the invitation language here.

[kathyavini]

@SayakaOno I'm going to go ahead and give this a direct merge now so that Denis can start QA as soon as he starts work, but that isn't to say it doesn't need review -- it does!! Please do review it!! 🙏🙏🙏

If either you or Denis find any blockers we can hold off on patch, but I was hoping the simulataneous code review + QA during your earlier shifts could set us up for still getting the patch out tomorrow morning if everything checks out 🤞

Sorry I didn't get a chance to set up the patch branch yet though...