Occasionally I’ve run into an issue where enabling multilingual translations doesn’t correctly reach out to all aspects of my existing Sitefinity instance. Progress Sitefinity will allow translations to be made (under Interface Labels and Messages), and Pages and some content types will allow me to provide translations as well, but some dynamic content types will still behave as if there’s only one language available.
My first thought would always be that maybe existing dynamic types have to be re-installed in order for translations to be made available to them. While you can uninstall a custom module builder module, then reinstall it, this can wipe out all the data for that module. This sledgehammer approach works, but obviously isn’t desirable.
Thankfully, there’s a much easier way to go about this problem. In actuality, Sitefinity did enable multilingual translations for the content types missing the ability to add/edit translations. It’s just that, for whatever reason, the CMS failed to modify the backend screen so that the options are presented correctly. All we have to do is modify the screen to get it to show us the buttons:
That’s it! Sometimes Sitefinity simply fails to perform this step for you, but otherwise all of its types should have translations activated and available to you immediately after enabling a second language on your site. The next time you are working on an existing Sitefinity instance and find yourself wondering why multilingual translations don’t exist for your custom module, don’t take the sledgehammer approach: This is all you need!