Forum Discussion

Favio_Trasi's avatar
Favio_Trasi
Community Member
4 days ago

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

Hi everyone,

I’m using the Articulate Localization Add-on in Storyline 360 and I ran into a limitation: the target language I need (Papiamento) isn’t available in the Localization language list.

So I’m considering a “proxy language” workaround and I’d love to sanity-check it with the community.

What I’m trying to do

  • In Localization, I add a supported language as a placeholder/proxy (e.g., English or Dutch — same script, LTR).
  • I don’t rely on AI translations. Instead, I replace all translated strings manually with my own Papiamento translations (copy/paste).
  • The goal is that the multilingual interface (language selector + localized content) shows Papiamento content everywhere, even if the internal language entry is technically a proxy.

In other words: the course would display Papiamento text everywhere (content + questions/answers + feedback), but the language slot is a listed language.

Main question

Is there anything that could go wrong with this approach?

I’m trying to identify pitfalls beyond “it’s not officially supported”.

Questions / possible pitfalls (please confirm/deny)

  • Metadata / language tagging: does the published output get tagged as the proxy language (e.g., HTML lang attributes, player language settings, LMS reporting)?
  • Player UI strings / system messages: are those fully editable via Localization, or could some UI strings remain tied to the proxy language?
  • Layout / text expansion: do you see UI/layout regressions when the real strings differ in length from the expected proxy language patterns?
  • Accessibility: could screen readers behave incorrectly if lang metadata remains the proxy language?
  • Maintenance: any gotchas when updating the source course later (re-sync overwriting manual edits, harder diffs, etc.)?

What I’m looking for

If anyone has tried something similar (using a listed language as a container for a non-listed language), I’d appreciate:

  • What actually breaks (if anything)
  • Best practices to minimize risk
  • Whether you’d recommend a different workflow 

Context: I’ll publish to [SCORM 1.2 / SCORM 2004 / xAPI / Review / Web].

 

Thanks in advance!

accessibility
advice
community
e-learning development
localization
storyline 360

2 Replies

  • Favio_Trasi's avatar
    Favio_Trasi
    Community Member
    1 day ago

    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.

  • EricSantos's avatar
    EricSantos
    Staff
    1 day ago

    Hello Favio_Trasi,

    Thanks for laying this out so clearly. You’re asking all the right questions, and you’re right to pause before relying on a proxy-language approach.

    While it’s technically possible to use a supported language as a container and manually replace the strings, that method isn’t officially supported and does carry some real risks, especially around language metadata, accessibility, and long-term maintenance. In particular, published output and screen readers may still treat the course as the proxy language rather than the actual one you’re displaying.

    The underlying need here is the ability to define and use additional or custom languages in the Localization Add-on, including correct language tagging and accessibility behavior, without relying on workarounds. I’ve shared your feedback with our product team so they can see how important this is for real-world localization and compliance needs.

    We really appreciate you taking the time to outline both the use case and the potential pitfalls so thoughtfully.