Разработка локализованной схемы базы данных [дубликат]

Сначала я скажу, что раньше не имел дела с локализацией, так что это действительно только мое мнение и не основано на опыте.

Мне нравится ваш второй вариант. Что касается БД... ее данных и способа доступа/манипулирования данными. В этом случае все данные находятся там, и вы будете в основном читать их и иметь хороший способ добраться до них. Вы можете ответить на одну и ту же проблему в обоих сценариях. Я бы предпочел второй вариант сам, потому что он уменьшает сумасшедшие таблицы везде. Вы храните таблицу для конкретной цели перевода. Вы можете использовать ее повторно (больше никаких таблиц не создается только для последующих обновлений), и она сохраняет целостность. Вы даже можете повторно использовать имена, если это где-то имеет смысл. Например, если бы у вас был 'Mantequilla' как Категория и как Избранное где-нибудь в другом месте.

Мне нравится помещать связанные данные в одну таблицу, когда это возможно, и не иметь данных, связанных с "переводом", в нескольких местах.

Единственное место, где это может оказаться неудачным, это если у вас есть нечто большее, чем просто Имя и Описание для чего-то, что нуждается в переводе. Может быть, у вас есть Имя, Описание, Код, Волшебное Слово, Глупый Никнейм и т.д. для элемента. Хотя вы могли бы обойти это, добавив больше NameTokens в соответствующую таблицу и повторное использование Name, но это немного хакерство.

Просто убедитесь, что модель соответствует вашим потребностям всех и она должна работать нормально. Вы всегда можете добавить специальную таблицу перевода, если это понадобится позже для конкретной таблицы. Это не будет отличаться от создания множества таблиц, хотя гибридное решение может сбить с толку. Лучше всего найти один способ и попытаться придерживаться его.