#java #spring #mongodb #internationalization
#java #spring #mongodb #интернационализация
Вопрос:
У меня есть серверная часть в Java Spring с базой данных mongo и коллекцией, в которой хранятся туры (roadtrips). Поскольку это приложение предназначено для использования туристами, мы хотим внедрить интернационализацию. Базовый объект Tour выглядит примерно так
{
"_id" : ObjectId("5c826e272173e100044496b1"),
"startingDate" : NumberLong(1552160940),
"start" : {},
"end" : {},
"title" : "Dummy tour",
"duration" : NumberLong(25653),
"transportationType" : "DRIVING",
"polylineDecoded" : [ ],
"waypointList" : [ ],
"ownerIds" : [ ]
}
Мы хотели бы добавить заголовки, основанные на языковом стандарте пользователя. Каков наилучший способ построения класса Tour?
Существуют ли лучшие практики для такого рода вещей?
РЕДАКТИРОВАТЬ: Пока что это наиболее распространенный подход, но я боюсь, что это приведет к раздуванию объекта tour в случае добавления слишком большого количества языков.
{
"_id" : ObjectId("5c826e272173e100044496b1"),
"startingDate" : NumberLong(1552160940),
"start" : {},
"end" : {},
"title" : {
"en" : "Tour",
"gr" : "Ξενάγηση"
},
"duration" : NumberLong(25653),
"transportationType" : "DRIVING",
"polylineDecoded" : [ ],
"waypointList" : [ ],
"ownerIds" : [ ]
}
Комментарии:
1. Почему бы просто не использовать ключ для глобализуемых значений вместо самого жестко закодированного значения? Т.е. единственное значение для
title
выглядело бы примерноstrings.title
. Затем вы бы сохранили это в интернационализированных ресурсах свойств и извлекли значение с учетом языкового стандарта пользователя. Примерно так интернационализация работает обычно.2. @Mena можете ли вы привести пример в ответе, пожалуйста? Я не совсем понимаю, что вы имеете в виду.
3. Вы можете посмотреть, например, здесь краткое руководство по интернационализации с Java (возможно, старое, но общие принципы должны сохраняться). По сути: вы сохраняете только данные, связанные с моделью, в своей коллекции tour, то есть данные о турах, а не все переводы для общих строк. Они сохраняются где-то в другом месте как ключевые значения, и когда вам нужно отобразить значение с заданной локализацией, вы знаете ключ для него и можете получить правильное значение.
4. Большое спасибо за ссылку @Mena
5. Никаких проблем. Взгляните на общий принцип, но я бы не рекомендовал воспринимать все буквально. На мой взгляд, общая идея заключается в том, что вы отделяете свои переводы от своих бизнес-объектов и переводите только на том уровне, который этого требует (обычно прямо во внешнем интерфейсе, но не всегда), запрашивая переведенное значение с учетом ключа (например,
tour.title
) и языка (например,el
) или полной локали (например,el_GR
) и т.д. И т.п.