Интернационализация в Java Spring с помощью mongodb

#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 ) и т.д. И т.п.