Add support for new localizations.

[mat1th]

Describe the feature The SDK only supports 2 localizations for now the nl and en localization. We would like to support more languages in our app. For now this is only possible with manually adding translations because it is always searching in the SDK bundle.

Screenshot NA

Possible solution A possible solution would be to add the localization strings to the Appearance objects. There are only two kinds of places where this is not possible.

• Views without an Appearance object (MessageImageViewController). To solve this a new Appearance object should be created.
• Non UI usage: Places where translations are used are Parley, Message+Accessibility and MediaUploadNotificationErrorKind. To solve this, the logic needs to be extracted and moved to the UI.

Is this a okay solution, or do you want separate objects for the translations?

[alexkok]

Hi @mat1th , thanks for reporting.

All keys are prefixed by parley_ already and we would allow overriding these when wanted (just like Android used to do). However, as you describe, it currently only searches in the module bundle, making it impossible to override.

While the suggested solution could work, we are thinking of a different approach:

• Adjusting the code in StringExtension
• Where we adjust it such that it first checks if the needed localization is in the main/other bundle, and if not, take it from the sdk bundle as fallback.
• Note that NSLocalizedString always returns the key if it cannot be found. So to do this we could check if we get the key returned as result, and if so, take string from the sdk bundle instead.
• Benefit of this is that it saves much code, and we don't need to introduce additional properties/classes to support this. Also allows to override any string used by Parley.
• About stability, in case new strings are introduced or renamed (this doesn't happen much) we need to mention these in the CHANGELOG.md

How does this sound to you?

[mat1th]

We do also have the option in our app to overwrite the system locale. So for example a user does has his system language to en while the app will use nl while the app does also support en.

With you supposed solution this will not work for us.

[alexkok]

You are right on that one, in that case that won't work. Agreed, need to add handling texts in a different manner then.

As for the MessageImageViewController, maybe we could set these with a key like "general" or so (there's the parley_close for example which just should be Close in EN for example.

Although separate text classes (like we do with appearance) might be too verbose for the goal of localizing the texts. I think an enum and a protocol would be a nice way, similar to how offline messaging and the network is separated with protocols.

Where:

• Parley defines the set of localization keys that could occur (via the enum).
• In the library we provide a Protocol for retrieving the keys
• In the library we provide a default Parley localization handler (which adheres to the protocol, is the default, and does basically the same as what is done now).
• Developers can implement their own localization handler by providing their own class that adheres to the protocol.
• Maybe something like Parley.setLocalizationManager(manager)
• We should consider new features: somehow the protocol must have a fallback, or leave it up to the developer, in case we need to add a minor text (we could do a switch on the enum, but adding a new text will break compile-time for developers). We could maybe make the default still take the implementation of Parley, or make the default based on whatever the protocol defines. (The developer could, in the protocol, implement it the same by looking at Parley's module strings of course)
• We should leave the choice to the developer whether adding a case could break compile-time I think. Since texts can always be added in a minor or patch version.

Just a first idea concept to think through, names/terms could change. How does this sound?

[mat1th]

Hi @alexkok,

I've made a implementation on and opened a pr https://github.com/parley-messaging/ios-library/pull/113.