Hi Tobias

Its certainly can handle translation of anything that would have traditionally been translated using XML files. I just tried it on Alloy Demo Kit (https://github.com/episerver/AlloyDemoKit) which already uses Db Localization Provider and can confirm that page types can be translated. 

You will need to ensure your localization section looks like this to ensure all localizations are pulled from the provider:

<localization fallbackBehavior="Echo, FallbackCulture" fallbackCulture="en">
  <providers>
    <add name="db" type="DbLocalizationProvider.EPiServer.DatabaseLocalizationProvider, DbLocalizationProvider.EPiServer" />
  </providers>
</localization>

There is also a migration tool to move all lang.xml files into the provider too, will track down the link post here.

David

The migration tool I mentioned:

https://blog.tech-fellow.net/2016/03/01/episerver-database-localization-provider-released/

Ok, just want to make sure before I install this on our main development project: We don't have any xml-files yet and most PageTypes and BlockTypes's ContentType attribute only contain GUID and GroupName and properties' Display attribute only contain GroupName and Order (No Name or Description settings). Will existing PageTypes and properties be picked up and added as strings by the Db Localization Provider or do I need to create xmlfiles first that can be migrated?

"Will existing PageTypes and properties be picked up and added as strings by the Db Localization Provider" pretty sure the answer to this is no so you'd probably have to create them. The format is pretty simple to work out though, for example these are the keys for the start page in a standard Alloy site:

/contenttypes/startpage/description

/contenttypes/startpage/name

I'm pretty sure you could write in init module to spin through all the registered content types and create a key in the DB localization provider that would allow them to be translated.

Ok, will try this out. Thanks for the input