It looks like you found an unmodified section in the help I will be sure to get this fixed.  You are correct in referencing the MessageDataSourceKey if you are going to use a SQL Server connection from which you are going to pull your localization keys.

Using SQL Server is actually not the most optimized source form which to pull your localization keys, but rather using embedded XML files.  However, if you have the need for this to be changed at run-time then SQL Server would be the best avenue.

If you use the embedded XML files then the deployment conversation is a mute point because the localization files are stored within the compiled assembly.  However, if you are going to use SQL Server, then you MUST deploy the localization keys to your end-users somehow.

The DDT makes short work of this and has a wizard to create a deployment data package which will pull all of your keys in from a specified localization project.  If you have the DDT then you can use it just for this single purpose if you choose and use your current means of deploying your structures in tact.  Otherwise you will need to make sure that your current deployment process will create the following tables:

• MessageLanguages
• MessageItems

You DO NOT need MessageProjects.  You will however need to gather up any records that have the foreign key of the projects primary key when creating your deployment packages (this is what the DDT does for you through a wizard).

Once you have all of this done the only thing remaining is the connection to where these tables will reside.  If the MessageLanguages and MessageItems tables reside in your default connection then you can ignore the MessageDataSourceKey since it will be the same.  Just be sure to set the MessageKeyType to SQLServer.  However, if the above specified tables will be in a separate database, then you will have to create another data source (you can refer to the docs on this....they are up to date, I checked ):

And then you will need to specify the MessageDataSourceKey to follow suit: