Copies/translations not fetched inside the completion block of CrowdinSDK.startWithConfig on a fresh install

[stevi-clue]

Hi there!

I successfully integrated the CrowdinSDK in my app using Swift Package Manager and I am using OTA content delivery. On the first app launch with internet enabled, when I enter the completion block of CrowdinSDK.startWithConfig, and fetch the copy for a specific key using NSLocalizedString(key, comment: ""), I am only getting the key and not the copy. If I kill and relaunch the app, the copy for the same key is fetched successfully.

Do you know what might be causing this and do you have any suggestion on its mitigation?

Many thanks!

[DimaYashchyshyn-zz]

Hi @stevi-clue
Checking this :)

[stevi-clue]

Thanks for the fast reply Dima! :)

I was playing a bit around with breakpoints in the SDK and my hunch is that it might be due to Localization.refreshLocalization() -> Localization.fetchRemoteLocalization() being first called when the localization is set in the LocalizationProvider(). The LocalizationProvider is initialized in the setRemoteStorage which does not call a completion block when it is done.

Maybe passing the completion handler from CrowdinSDK.startWithConfig all the way to Localization.fetchRemoteLocalization() might solve this?

[andrii-bodnar]

@serhii-londar could you please assist with this?

[serhii-londar]

Hi @stevi-clue, you need to add a download handler:

CrowdinSDK.addDownloadHandler {
            NSLocalizedString(key, comment: "")
}

[serhii-londar]

@stevi-clue Does it help?

[chrispomeroyhale]

My team had a similar question as well.

In my opinion, the completion parameter to startWithRemoteStorage is not well documented as to what receiving a completion callback means to us client apps. In our observation startWithRemoteStorage ultimately calls three different network endpoints. What if one of them fails? CrowdinSDK.addDownloadHandler has the same documentation issue -- is that called for each individual translation file or for when all of them are done?

I think the more communicative approach would have been to have a single callback that tells us what state the SDK is in.

From my comments here, here, and here, the emerging theme in my opinion is that edge cases surrounding the initialization of the SDK are not well defined and automated tests have room to grow.