Because the canTranslate() method is exactly what we marked as works as designed in the core issue, there's no need to have it and we actually double-map the languages. This is fine, no explanation necessary.
Hm, the only case that could happen is if mappings are configured to map local languages that exist as remote languages to other remote languages. E.g. if de is mapped to de-CH and a second mapping maps de-CH to en-CH. Which I'm not sure is going to work properly anyway and is a quite weird use case :)
I would expect that through a double mapping it possibly maps to e.g. nothing since the (wrongly mapped) source key doesn't exist. Am i completely wrong?
Comments
Comment #1
blueminds commentedOnly removing duplicate mapping was needed, then renamed one variable to be more specific.
Comment #2
miro_dietikerWhy remove canTranslate()?
At least i'm expecting an explanation here.
Comment #3
berdirBecause the canTranslate() method is exactly what we marked as works as designed in the core issue, there's no need to have it and we actually double-map the languages. This is fine, no explanation necessary.
Comment #4
miro_dietikerI would expect a test to check for double mapping error.
Comment #5
berdirHm, the only case that could happen is if mappings are configured to map local languages that exist as remote languages to other remote languages. E.g. if de is mapped to de-CH and a second mapping maps de-CH to en-CH. Which I'm not sure is going to work properly anyway and is a quite weird use case :)
Comment #6
miro_dietikerI would expect that through a double mapping it possibly maps to e.g. nothing since the (wrongly mapped) source key doesn't exist. Am i completely wrong?
Comment #7
berdirNo, the mapping just returns the same language code if there's no mapping for it.
Comment #8
blueminds commentedPatch that fixes mapping bug in getAvailableTiersOptions()
Comment #10
berdirThanks, committed and pushed.
Comment #11
berdir