#F Custom locales #788
Merged
#F Custom locales #788
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There were a couple of errors in naming and in the strings, so I updated them. MOB-2507
The changes in this file were done partially. This is because there are some strings that are using parameters in the string which are replaces on runtime. These need to be evaluated to see if a backwards compatibility layer is needed for them or not, which is out of the scope of this task at the moment. MOB-2538
A couple of strings have been left untouched because they don't use secure conversations specific strings. They use chat strings. So these will be done in a future PR to avoid making the PR too big. MOB-2538
This time, strings in screen sharing, alert, call, and survey mocks were changed. Also a string that was previously missing was added. MOB-2538
Also some strings have been changed as part of several discussions, so they have been updated here. MOB-2538
All remaining strings that have a direct translation in the new Localization enum are now removed. The only strings remaining are the ones that need a translation layer, because they use variables. MOB-2538
There was a small amount of strings that I incorrectly identified as needing additional work to change, but it was just a matter of replacing because they are all internal and not exposed to the integrators. MOB-2507
Instead of creating a layer that verifies if a string has a template or not,
the templates (for example, `{operatorImage}`) have been captured in an
internal extension of the `Localization` struct. That way integrators have a
deprecation that they shouldn't use our strings anymore in case they do, but
also the minimum amount of changes is done to the workings on the SDK. So we can
still use templated strings as right now without going and changing a bunch of
SDK functionality.
MOB-2507
The proposal is that the Core SDK will return to us a dictionary with the keys and values just as they come from the backend. This is also exactly how the strings are saved in the `Localizable.strings` file, accessed through the `Localization` enum. When the Core SDK is configured and is able to provide the dictionary, we save it to a StringProviding struct. When a string is accessed through the use of `Localization`, then `Localization` knows what is the key of the string, and also specifies a fallback in case reading from the file fails. So with this same key, we can go to the StringProviding, consult the dictionary, and if the string is not there, use the file fallback, and if not use the string fallback. This means that with this simple PR, once the Core SDK provides the dictionary, we support custom locales for the whole Widgets SDK with minimal effort. The alternative is to create a model which we need to keep in sync between Core and Widgets, which seems like a big mess. MOB-2282
StringProviding is set when configuration is done. Then this StringProviding will be used to retrieve remote string if exists, otherwise localized value is taken from local file.
In this commit, support for adding a company name from custom locales is added. However, if the integrator has set this name through the theme, that one is used instead of the custom locales. Also, in case the custom locale doesn't have a string for the company name, but the integrator has specified a company name through the configuration of the SDK, then that is used. Finally, if neither of the previous possibilies have been used, then the local fallbacks are used. Together, the first and the last point mean that there are no backwards compatibility issues, as if the integrator hasn't set any name, still the local fallback will be displayed, which is "CompanyName". If they have, then that is used immediately without caring about configuration or custom locales. MOB-2686
Local key/value pairs were updated to align localization between platforms and remote default locale MOB-2719
yurii-glia
approved these changes
Oct 4, 2023
rasmustautsglia
approved these changes
Oct 4, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Custom locales feature PR