Как делают интернационализацию в Java?

Тысячей способов…

По вашей ссылке вообще не про Java, а про Javascript…

Самый стандартный способ из-коробки в JDK/JRE - ResourceBundle https://docs.oracle.com/javase/8/docs/api/java/util/ResourceBundle.html

Возможно, какие-то нестандарные библиотеки в чём-то удобнее и современнее.

А если вам нужен spring mvc, у него огромная документация. https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/mvc.html#mvc-localeresolver

А зачем делать как нафталиновые деды? Заведи перечисление с типами фраз, по нему захардкодь словарь для основного языка, для остальных тяни с файлов пары ключ-значение. С максимально простых файлов, типа, ключ, перевод строки, значение, перевод строки

Строка «Java™ Platform Standard Edition 8» означает версию Java SE 8, выпущенную корпорацией Oracle в 2014 году. (ЭТО БЫЛО 10 ЛЕТ НАЗАД!!!)

https://en.wikipedia.org/wiki/Java_version_history

19th March 2024 => «Java SE 22» 66

https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/ResourceBundle.html

Вы не поверите, насколько Java-8 хороша и популярна, потому что стабильна. И насколько чаще её в индустрии сегодня можно встретить, чем Java-22 или хотя бы Java-17. Вот буквально участвую в разработке продукта (не напрямую), который только-только со скрипом обновлятся до 17, и то совместимость с 8 ломать не получается даже там, где казалось бы давно надо.

Несмотря на гонку версий, Java-8 куда более важные отличия от 7/6/5 содержит, чем всё, что шло после. Хотя не спорю, лучше не застревать.

Я почему собственно ссылку ту кинул, это первое что мне поисковик кинул. 22 тоже можно, я думаю, именно в ResourceBundle там мало что поменялось.

Если сравнить эти две ссылки, то там есть лишнее слово - «модуль» (/java.base/):
https://docs.oracle.com/javase/8/docs/api/java/util/ResourceBundle.html
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/ResourceBundle.html

Модули появились в Java с выходом JDK 9.
Я, например, что такое модули - не знаю.

Зависит от того интернализацию (i18n) чего тебе надо делать. В современном мире rest-а i18n в java уже 100 лет не встречал, она вся в js сидит. Если у тебя i18n для простых сообщений, то ResourceBundle , если у тебя полноценных spring портал, то у него свои средства (например, посмотреть можно тут, они тоже сводятся к ResourceBundle в конечном итоге). Если у тебя кастомный jsp, то не надо так делать.

она вся в js сидит

Сказки. Не бывает такого, чтобы сайт вытягивал все локали в js и затем использовал только одну из них.

А если js запрашивает конкретную локаль, то значит серверная часть в них разбирается и в ней есть соответствующий код.

Ты спрашиваешь про интернализацию т.е. уровень твоих знаний где-то на уровне джуна, но прям тут же начинаешь уверенно вещать про то в чём полностью не компетентен. Очень глупо выглядишь.

Сказки. Не бывает такого, чтобы сайт вытягивал все локали в js и затем использовал только одну из них.

Да легко. Ничего не мешает набить все локали в один бандл или даже в несколько, но они будут загружаться все сразу, а не динамически.

А если js запрашивает конкретную локаль, то значит серверная часть в них разбирается и в ней есть соответствующий код.

Требуемая локаль вполне может определяться чисто на клиентской стороне, например, из navigator.language или сохранённой настройки в куках или local storage. Сервер вообще может никак в этом не участвовать.

Общий принцип: имеется локаль, имеются файлы, в которых хранятся строки с переводами, программа по выбранной локали подбирает нужный файл.

Конкретней надо смотреть в конкретной программе.

Модули делать не надо. Как в программе сделано, так и оставлять.

При опакечивании надо всю программу опакечивать как есть. Положить её в /opt/programname/programname.jar и сделать лаунчер, который выполняет java -jar /opt/programname/programname.jar "$@". Команду list-modules использовать не надо. Разбивать переводы на отдельные пакеты не надо. Программа должна быть в том виде, в котором её сделал программист.

Программа должна быть в том виде, в котором её сделал программист.

Нет. Нельзя доверять программистам компиляцию, иначе они там повыбирают зависимости сами и у пользователей не будет никакого контроля за этим. Зависимостями должен управлять системный пакетный менеджер. А для этого он должен быть проинтегрирован с местным менеджером модулей.

Нет. Нельзя доверять программистам компиляцию, иначе они там повыбирают зависимости сами и у пользователей не будет никакого контроля за этим. Зависимостями должен управлять системный пакетный менеджер. А для этого он должен быть проинтегрирован с местным менеджером модулей.

У пользователей и не должно быть никакого контроля над зависимостями. Пользователи получают программный продукт в виде набора файлов, в который уже включены все зависимости нужных версий. Никакие действия с этим набором файлов недопустимы.

О состоянии интернационализации и локализации на сегодняшний день нужно знать три вещи: всё очень, очень и очень плохо

В жабе-то? Это ты ещё логирование там не настраивал.

Просто положи конфиг в LDAP

положи конфиг в LDAP

Чтобы конфиг куда-то положить, надо его сначала напесать. А ты ещё даже фреймворк для логирования не выбрал.

Никакие действия с этим набором файлов недопустимы.

Нет. Такие запреты нарушают лицензию LPGL. Она говорит, что можно обновлять библиотеки на новые версии с фиксами дыр.

Вопрос не в GPL а в здравом смысле. Ты можешь делать что угодно, но будет ли получившийся софт работать как задумывал разработчиком - вопрос очень нетривиальный. Может будет, а может и не будет.

обновлять библиотеки на новые версии с фиксами дыр

STABLE APİ/ABİ İS NONSENSE @ ПЕРЕПИСАТЬ ВСЁ С НУЛЯ!

обычно в ресурсы складываются файлы с названием messages_{lang}.properties, где lang это en, ru, de, cn и т.п., согласно конвенции используемой технологии, вместо messages может быть имя модуля или приложения

файлы складываются

Это всё супер, пока они лежат в директории исходников. Но затем исходники компилируются при помощи javac в .class-файлы и попадают в другую (выходную) директорию. А оттуда архивируются в .jar или .war файл.

А про ресурсы непонятно, они же не компилируются, в другую директорию не попадают, и в финальном архиве не оказываются.

По крайней мере, в этой форумной нити пока никто не написал, как это происходит.

Или пишут такое:
«The interpretation of a resource name is relative to a class loader instance. Methods implemented by the ClassLoader class do this interpretation.»
«Applications use «well known locations» such as System.getProperty(«user.home») or System.getProperty(«java.home»), then add «/lib/resource», and open that file.»

Это же нифига не ясно написано.

Можно предположить, что ресурсы укладываются в архив как лежат в директории исходников (т.е. копируются перед упаковкой в выходную директорию). Но я не должен об этом догадываться, это должно быть написано в туториале со ссылками на нормативные документы, в которых об этом написано. В этом туториале ссылка общая, а не конкретная и только одна, в то время как должно быть несколько, описывающих весь процесс. В частности я не вижу объяснения того, что с ресурсами делает maven и как обойтись без него.

ресурсы складываются в архив, не всегда прямо в неизменном виде, но в общем случае если положить свой файл в ресурсы он попадет в каталог META-INF или WEB-INF или classes. Этот лейаут зависит от формата, в jar чуть по-своему, в war по-другому и есть еще разные форматы и у каждого формата альтернативные варианты лейаутов. С точки зрения разработчика это должно быть не очень существенно, т.к. в коде вы вызываете некий getClass().getResource(«name») или его аналог, а среда выполнения сама находит вам ресурс

Все это обязательно где-то описано, и даже стандартизированно, в джаве иначе не бывает, например вот тут можно глянуть:

https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/