Não sei por que você está preocupado com o número de tabelas:ter menos tabelas não significa automaticamente que seu banco de dados é menor, mais eficiente ou melhor projetado. Especialmente se reduzir o número de tabelas aumenta a complexidade de suas consultas, eu tomaria muito cuidado ao fazê-lo.
De qualquer forma, eu iria para uma tabela de tradução por tabela 'base'. A principal razão é que sua segunda solução não é flexível:se a chave primária não for um único inteiro, torna-se extremamente difícil de implementar e usar. A consulta de traduções também é mais complexa e, dependendo do tamanho da tabela e dos dados, pode ser difícil indexá-la de forma eficaz.
Não está claro por que você tem um
TranslationID nos Products tabela; geralmente a relação é inversa:create table dbo.Products (
ProductCode char(10) not null primary key,
ProductName nvarchar(50) not null,
ProductDescription nvarchar(100) not null,
-- other columns
)
create table dbo.ProductsTranslations (
ProductCode char(10) not null,
LanguageCode char(2) not null,
ProductName nvarchar(50) not null,
ProductDescription nvarchar(100) not null,
-- other translations
constraint FK1 foreign key (ProductCode)
references dbo.Products (ProductCode),
constraint FK2 foreign key (LanguageCode)
references dbo.Languages (LanguageCode),
constraint PK primary key (ProductCode, LanguageCode)
)
Dependendo do seu conjunto de ferramentas e do processo de implantação, você pode querer gerar tabelas de tradução diretamente das bases como parte da construção do banco de dados. E você pode usar visualizações para fornecer uma versão conveniente e 'totalmente traduzida' da tabela base.
Uma questão interessante é qual idioma é usado para as colunas em
Products e se eles podem ser usados diretamente quando nenhuma tradução é necessária. Minha sugestão seria que todo código de produção passasse um parâmetro de idioma e pegasse o texto do ProductsTranslations tabela apenas, mesmo para inglês (ou qualquer que seja o idioma interno da sua empresa). Dessa forma, você pode ter certeza de que todos os nomes 'oficiais' são encontrados na mesma tabela e as colunas na tabela base estão lá para clareza e integridade do modelo de dados, bem como conveniência do desenvolvedor e (possivelmente) uso interno em ad hoc relatórios e assim por diante. 
