Для мультиязычной архитектуры есть несколько подходов. Описывать их не стану - в сети информации достаточно. Первый подход самый простой, но не самый эффективный. В вашем случае я бы предложил обойтись 2мя таблицами (условно, точное разделение без ТЗ сложно определить, здесь важен принцип). Даю на примере того же блога, архитектура близка к WordPress:
# Таблица 1 - "Посты"
id
translation_of | 0 или id оригинала
language
title
short
full
...
# Таблица 2, вариант 1 - метаданные постов (любые)
id
post_id | id поста(ов) из таблицы 1
key
value
# Таблица 2, вариант 2 - метаданные постов (конкретные)
id
post_id | id поста(ов) из таблицы 1
image
author
...
Важный момент - post_id во второй таблице. Можно держать один ID, но тогда данные будут дублироваться (2 одинаковые картинки для поста на 2х языках), что не дает никакого выигрыша. Можно держать массив ID, тогда одну и ту же картинку можно назначить разным постам. А можно обойтись 1м ID, а переводам назначать ту же картинку программно - в поле post_id всегда держать только ID поста на языке оригинала, для вывода проверять, если есть картинка для перевода (по его ID) - брать ее, если нет - брать по ID из поля translation_of. Такая система будет более гибкая, в том плане что много полей из 1й таблицы можно вынести во 2ю, и появляется возможность работать "и так, и сяк" - если есть перевод поля, используем его, если нет - используем из оригинала. Это так, в общих чертах.
Данный подход не является "правильным", "лучшим" и тд. Это один из рабочих вариантов, со своими плюсами и минусами. Оптимальное решение выбирается на основе ТЗ.
