Thank you for bringing this to our attention. I have managed to reproduce the issue you describe locally, and consider it a bug. Correspondingly, I have filed an issue ticket so that we can track this problem and hopefully address it in a future release, here:
I believe it should work the same as the free-text display date field - that is, it will allow a different value to be entered as a translation when editing while using a different display culture, but if no translation is present, it should fall back and display the original source string.
In the meantime, as a workaround you could enter edit mode in the secondary culture and either add your preferred translation, or else copy the source string so it displays when the description is viewed in that culture. Not convenient, but it does seem to work for now.