Hi @BinaryCCS, thanks for using our SDK.
The approach mentioned in the post you’ve linked to would be the correct way of localizing for unsupported languages. What is not mentioned is the number of string resources you would need to create in order to support this. It may not be immediately apparent, but there are a lot of unique values which would need to be translated. In addition to this, we don’t have public documentation of all of the String resources or a good way of conveying any changes with each new release, so maintaining it in the long term would probably not be the easiest task.
If you were to implement a custom meeting UI, this could solve many of the issues you’d run into trying to maintain this in the long term. You would have absolute control over the UI, so that would eliminate the need to translate every single String used by the SDK.
Let me know if you’d like to proceed with adding support for a custom language and we can provide some additional information.