I would also advocate a single-table/language-segmented design where all the languages are stored in a single table with a language column.
Dynamic SQL may be potentially vulnerable to SQL injection. If the @LANG variable cannot be trusted (or if the schema and table need to be validated to be a valid combination), you can check it against sys.schemas using a technique like this:
DECLARE @template AS varchar(max)
SET @template = 'SELECT * FROM {object_name}'
DECLARE @object_name AS sysname
SELECT @object_name = QUOTENAME(s.name) + '.' + QUOTENAME(o.name)
FROM sys.objects o
INNER JOIN sys.schemas s
ON s.schema_id = o.schema_id
WHERE o.object_id = OBJECT_ID(QUOTENAME(@LANG) + '.[TestingLanguagesInNameSpacesDelMe]')
IF @object_name IS NOT NULL
BEGIN
DECLARE @sql AS varchar(max)
SET @sql = REPLACE(@template, '{object_name}', @object_name)
EXEC (@sql)
END
Now you have the power and flexibility of dynamic sql, but it is not vulnerable to injection.