Сохранение текстов на разных языках в базе данных
Есть какая то база, в ней ней есть таблицы с полями текста, допустим название города. База отображается через приложение которое имеет выбор языка отображения. Хотя бы нем. и англ.
Выбрал пользователь en показываем Cologne, выбрал de, показываем Köln.
Типа так: https://en.wikipedia.org/wiki/Cologne ,только данные вводит администратор и разных таблиц будет много.
Вариантов имплементации много, что вам больше нравится?
Предложенные варианты:
1. Использовать динамический перевод от гугла.
2. Упаковать в одно поле все языки
3. Использовать паралельные языковые таблицы, где только перевод полей, для каждой таблицы
4. Использовать дополнительное поле для каждого языка в одной таблице CityId, CityNameEn, CityNameRu, CityNameDe, ZIP
5. Глобальное хранилище переводов - "id-язык-перевод" + кэш
Ваш вариант решения.
Так?
Таблица City:
CityID, LangID, Description
Таблицая Language:
LangID, Description
Дальше:
SELECT c.Description FROM City AS c INNER JOIN Language AS l ON c.LangID l.LangID WHERE LangID = .. AND CityID = ...
Например:
Language:
LangID Dscription
1 Русский
2 English
City:
CItyID LangID Description
1 1 Москва
1 2 Moscow
SELECT c.Description FROM City AS c INNER JOIN Language AS l ON c.LangID l.LangID WHERE LangID=1 AND CityID=1
Результат:
Description
Москва
SELECT c.Description FROM City AS c INNER JOIN Language AS l ON c.LangID l.LangID WHERE LangID=2 AND CityID=1
Результат:
Description
Moscow
Сохраняйте название в таблице связей. Отношение * to *.
LangId
LangName
CityId
CityName (например, английское название, или можно вообще выкинуть это поле, т.к. оно будет в таблице связей)
Таблица связей
CityId
LangId
CityName
Что делаем для других языков?
-----
Пишем, укзывая язык.
Еще нужен "язык по умолчанию" - то, что подставится если нет записи на нужном языке.
Подобных таблиц и связей довольно много.
-----
И?
Работы - да, много...
Если хочешь вариант - делаешь ресурсные дллки под языки и работаешь с ними в ручном режиме...
Меньше работы не будет.
Добили Москва и Садовая и сказали что эта улица в Москве для ru.Что делаем для других языков?
Когда я делал портал по недвижимости, то я в каждую таблицу вставлял поле langid. Если у вас не App и не десктопное приложение, а веб приложение, то можно заставить гугл переводить - см. https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/translate. Если поле "улица" не используется для поиска, то ИМХО можно использовать шаблон, использовать разделительные знаки типа |, или сериализовать даже целый объект.
Пример как использовать разделительные знаки типа |:
Садовая|Sadovaya|Sadowaia, а дальше сплитуете см - https://docs.microsoft.com/ru-ru/dotnet/api/system.string.split?view=net-5.0
Пример как сериализовать целый объект:
[Serializable]
class Street {
public Int32 StreetID { get; set; }
public String Description { get; set; }
public Street(Int32 StreetID, String Description) {
this.StreetID = StreetID;
this.Description = Description;
}
}
Street s = new Street(1, "Садовая|Sadovaya|Sadowaia");
Дальше читатет тут https://www.c-sharpcorner.com/UploadFile/a5470d/using-xml-serialization-with-C-Sharp-and-sql-server/
Пример как использовать разделительные знаки типа |:
Садовая|Sadovaya|Sadowaia, а дальше сплитуете
Я про то же спрашивал недавно, когда говорил, как организовать мультилокальность в ресурсных файлах. Сплитить одну строку условными разделителями, писать одну запись несколько раз с разными языками (CityNameEn, CityNameDe, CityNameRu), заводить полноценные отдельные файлы под каждую локаль. Остановился на полноценных отдельных файлах, т.к. оптимальное решение между сильно зажатым вариантом с разделителями (уже не расширишь никак на добавочные требования или поля) и слишком гибким (и сложным) вариантом типа полноценной БД.
У ТС вариантов нет - только БД. На один язык приходится много городов. Один город может быть назван на многих языках. Название конкретного города на конкретном языке - уникальная запись. Вывод - для этого больше подойдёт поле в junction table между таблицами города и языка. И так для каждой связи "сущность - язык": "улица - язык", "город - язык" и т.д.
Ну так это для одной таблицы, а хотя бы для двух и больше? На каждую свою языковую копию делать? И все текстовые поля туда?
Не понял. Приведите пример. Я написал выше такой вариант. Дополню ещё полями и второй таблицей, чтобы было понятнее:
LangId
LangName
CityId
ZIP
Population
CityId
LangId
CityName
AnotherLocalizedCityData
StreetId
FoundationYear
Lang
StreetId
LangId
StreetName
AnotherLocalizedStreetData
Сколько сущностей требуют мультилокальность, столько и таблиц связей. В пределе можно вообще отказаться от отдельной таблицы городов или улиц, если известно, что в них только данные, требующие мультилокальность - т.е. данных типа почтового кода или населения нет. Но обычно это заранее неизвестно или таки такие данные есть, поэтому более гибко будет всё равно завести по отдельной таблице.
то можно заставить гугл переводить
То есть вариант - динамический перевод. Тут тоже проблемы, одно слово правильно перевести часто не получается. И еще непонятно как быть с большим количество запросов? И с задержкой перевода, страницу ведь можно показать только после полного перевода всего что там есть.
Ну так это для одной таблицы, а хотя бы для двух и больше? На каждую свою языковую копию делать? И все текстовые поля туда?
Именно так. Следующий уровень упрощения - вместо таблиц с локализацией делать поля с локализацией
CityId
CityNameEn
CityNameRu
CityNameDe
ZIP
Population
Минус - при добавлении новой локали нужно обновить приложение (обычно требуется обновление ORM). В варианте с отдельными заранее созданными таблицами связей - не нужно.