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.)?