Fix TypeError in LanguageDropdown when used in multiple mode

[akolson]

Summary

LanguageDropdown is used with multiple prop in SearchFilters.vue. In that mode, v-model holds an Array of selected language IDs. VAutocomplete's updateAutocomplete passes this.internalValue (the Array) to getValue, which eagerly evaluates getText(internalValue) as a JS argument before calling getPropertyFromItem — even though that fallback is never actually needed. getText in turn calls languageText(array). Arrays are objects in JS, so the primitive short-circuit guard in getPropertyFromItem does not apply, and languageText is invoked with the array directly. Since arrays have no native_name, item.native_name.split throws a TypeError.

Fix: guard languageText against item being null/undefined or lacking a native_name property (covers arrays, partial objects, and any future edge cases) by returning an empty string early.

Verification: ran the existing languageDropdown test suite and confirmed all tests pass, including two new cases covering the missing-native_name and array-input scenarios.

References

Fixes #5740
Recurrence of the issue addressed by #5465 (the null check was subsequently reverted without a documented reason).

Reviewer guidance

• LanguageDropdown.vue:120 — the new guard uses == null (not !item.native_name) deliberately, to avoid catching empty-string native_name values that the existing test exercises.
• SearchFilters.vue:68-71 — this is where multiple is used; reproduce the crash by opening Import from Channels, selecting a language filter, then blurring the dropdown.
• No risky areas: change is purely defensive, touches only languageText in the dropdown component.

AI usage

I used Claude Code to trace through the Vuetify VAutocomplete and VSelect source to identify why languageText was receiving an Array argument in multiple mode. After understanding the root cause (eager argument evaluation in getValue), I wrote the guard and two new test cases. I reviewed the generated code and confirmed the condition == null is correct for the intended behaviour.

[rtibblesbot]

Tight, well-reasoned hotfix for the Sentry crash — guard and tests are exactly right.

CI passing. Phase 3: no dev server available; the template is entirely unchanged (only the languageText method was modified), so there is nothing visual to verify — the fix's correctness is established by the new unit tests and CI.

• praise: see inline (×2)

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Reviewed the pull request diff checking for:

• Correctness: bugs, edge cases, undocumented behavior, resource leaks, hardcoded values
• Design: unnecessary complexity, naming, readability, comment accuracy, redundant state
• Architecture: duplicated concerns, minimal interfaces, composition over inheritance
• Testing: behavior-based assertions, mocks only at hard boundaries, accurate coverage
• Completeness: missing dependencies, unupdated usages, i18n, accessibility, security
• Principles: DRY (same reason to change), SRP, Rule of Three (no premature abstraction)
• Checked CI status and linked issue acceptance criteria
• For UI changes: inspected screenshots for layout, visual completeness, and consistency

[rtibblesbot]

praise: The comment explaining Vuetify's eager getText(internalValue) argument evaluation is exactly the right thing to document here — this is non-obvious framework internals and would otherwise pull future maintainers into a VAutocomplete/VSelect source dive to understand why the guard exists.

[rtibblesbot]

praise: == null (rather than !item.native_name) is the precisely correct check. It catches null, undefined, and array inputs (where .native_name is undefined) while deliberately allowing native_name: '' through so existing behaviour for empty-string entries is preserved. The companion test at line 82 of the spec explicitly pins this distinction — good defensive coding.