I think you need to bump the nls.localize key (i.e. 'ok' to 'ok1'), otherwise the string will not get relocalized? @TylerLeonhardt to confirm

I'm also interested as I think we may not need to do this anymore (is the key actually a hash of the key+contents? What's the key used for exactly?)

Yes you have to bump the key in order for the pipeline to recognize the change... however, I think this change is still fine because the intent is that it's just changing the "English translation". It's very unlikely that Ok translates differently than OK in another language... so the existing translations are still valid.

@Tyriar you may be thinking of extension localization which doesn't use a key... the key in core gets passed all the way to the translators and they use it for context in translating the string. In a lot of cases, this context isn't needed and if so, it should be in a comment and not the key... so we could move to a keyless function (I have a issue for this already).

@TylerLeonhardt moving to keyless as the default would be great. I've called this sort of thing out before in PRs, if the plan is to still keep the key, should the content just be an implicit part of the key so we don't need to think about it and any changes to the English content trigger re-translation? I never saw the key as a way to provide particularly useful context. If context is needed I'd go for ILocalizeInfo.