Closed basine closed 2 years ago
Thank you for the enhancement suggestion @basine!
Regarding the fallback update behaviour: This is correct, in the current implementation the fallback is the translation delivered by iOS from the translation shipped with the project. But I understand your point.
@theSoenke Is this something that we can handle in the Backend?
@winkelsdorf You're right. That is something we would have to handle in the backend
@basine Right now there is only a fallback to the default locale or locale without a region if it exists. For example when de-CH
does not exist de
would be the fallback locale.
But if de-CH
exists it would not use any fallback translations from de
. So this is not not something we currently support. But this totally makes sense and we will discuss this in the team
Moved this comment over from #16:
We have a similar problem at the moment: When setting only the language instead of language and region, we won‘t get the expected OTA translations, but Phrase is returning the translation from the fallback.
Example: Phrase project is configured with these languages:
de_DE
en_US
nl_NL
When changing the language on the phone (or simulator) but keeping the region, we often get combinations like
nl_DE
nl_US
In those cases Phrase returns the fallback (en_US
) instead of looking for a match with only the language code.
We would expect that asking the SDK for a translation with the nl_DE
locale would return the translations for nl_NL
. Is there any way we can achieve this without creating the duplication of languages in Phrase which @basine already mentioned?
We're also facing this issue. Would be nice to get some feedback on that. I do find this to be a quite common scenario, this should be covered.
Thanks a lot for your feedback. From what I can tell there are two issues:
First, there is no fallback from translations as @basine mentioned e.g. missing translations in de-CH will not be filled from de. We've also discussed this in the team and agree that this is an important feature. Unfortunately, we most likely won't have the time to release it this year but likely will tackle it early next year.
Secondly, a fallback to a different locale does not work e.g. from nl_DE to nl_NL. This case could be solved by changing the locale code nl_NL to nl. This way all non-existing locales starting with nl- would use nl as a fallback. Would changing the locale code like that a possibility? @ffittschen @ChristianSteffens
I am closing this topic due to inactivity. If there is still this question with a current SDK version, please feel free to reopen it. However, as a backend feature request, it will be followed up elsewhere if necessary.
We are trying to localise our app for the German and Swiss market and have noticed a behaviour that could be improved:
We already have a German translation "de" and have recently added "de-CH". In an ideal world (TM) we wouldn't need to duplicate all translations in the sub-localisation. Instead we should be able to only include those that we want to explicitly override.
Your SDK already handles the case of missing translations by defaulting to the default language, which is English in our case. However, it would be nicer if it would look for the translation for the primary language code "de" first before defaulting to the default language.
I also noticed that you are only updating the file for the current locale (or its override) but you are not updating the fallback.