To be precise, we don't have a specification for localized external choices. select_one_from_file works the same in Enketo and Collect as far as I know and neither supports localization with forms produced by pyxform at the moment. What @martijnr describes here implies it is likely possible to get localized files working with Enketo with modifications to the form definition XML but these modifications would currently be outside the ODK XForms spec. On the Collect side, the search() appearance/function lets you specify columns to use for different languages' labels on the choices sheet. This is also currently outside of the ODK XForms spec.
Could you please share a form that results in a crash? Here is an example that works the same in Collect in Enketo. The unlocalized labels are shown as expected and the localized columns are ignored.
To be explicit, I brought in the localization concept into this thread because I think it's critical and because I also think it may make us go down a different path for the column customization. Often when people have external CSVs, those come from external processes, and the ideal for them would be to be able to use their files unchanged.
For example, they may have columns id, name, nom and they'd like to be able to specify that values in the name column are to be used as the label in the default language and that nom is to be used as the label in the French (fr) language. Putting all of this in parameters seems it could become quite cumbersome. I'm not sure what a reasonable ODK XForms spec would look like for this (maybe a special instance to represent the mapping?) but I think it's important to at least explore. We may end up having to go with a convention like the ::language (lang code) suffix for practicality reasons but in many cases it will be less convenient from a user standpoint.
I'd really like to take this on but it will likely be a sizable project that touches multiple tools so I'm not sure when it will happen. Spec ideas are most welcome in the mean time.