The current implementation if a language code is valid is to check if the language code's length is more than two characters. This is incorrect since there are languages on our public API that uses locales, specifically for cyrillic and latin versions (i.e.: kk_la, kk_cy). It's better to validate the language code against the official list of languages that our api supports. To do this, we can call the /all-languages endpoint however it can become expensive if we do this every single time.
To get around this, a script to generate a typescript file with all of the supported languages is added to the precompile step so that it is ensured that every time we build and publish a version, our language list is up to date. This generated file is then referenced to a couple of functions that checks if a language is supported or not.
The current implementation if a language code is valid is to check if the language code's length is more than two characters. This is incorrect since there are languages on our public API that uses locales, specifically for cyrillic and latin versions (i.e.: kk_la, kk_cy). It's better to validate the language code against the official list of languages that our api supports. To do this, we can call the
/all-languagesendpoint however it can become expensive if we do this every single time.To get around this, a script to generate a typescript file with all of the supported languages is added to the
precompilestep so that it is ensured that every time we build and publish a version, our language list is up to date. This generated file is then referenced to a couple of functions that checks if a language is supported or not.