Localization proxy language hack in Storyline 360: what can break?

Hi Eric, 

Thanks so much for the thoughtful reply — I really appreciate that you understood the technical core of the issue, and thank you for sharing the feedback with the product team. Support for custom languages (with correct language tagging and accessibility behavior) would be extremely valuable.

In the meantime, since this may take some time, I’d love to learn what other users typically do today in this situation, which seems fairly common.

I understand the risks around language metadata and screen readers. For context, our rollout is a closed audience (~60 learners) in a controlled platform, and we can assume screen readers won’t be used for this project.

Given that:

• Have you seen any practical workaround that’s worked reliably in the field?
• Even if “proxy language” isn’t supported, is there any way to make the language selector display the real language name (e.g., “Papiamento”) rather than the proxy label?
• If you’d avoid the proxy approach entirely, what’s the best alternative from the end-user perspective, so we don’t lose the multi-language menu and force learners into a separate, isolated version?
  
  

We’re dealing with <100 Storyline courses, 5 languages each, including the non-listed one — so advice that scales would be greatly appreciated.