Озверина как вы можете статику от клиента хранить на бэке? А если клиентов несколько?...

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

Озверина как сервер узнает, на каком языке ему отвечать?О-о
Вот для этого я и хочу сделать что все переводы брались с сервака, а фронт уже сам рулил какой язык и т.д.

Petro123Tsyklop,
Ты читаешь что пишу?
Реакт и ангуляр это не JSP.
Это толстый клиеент и тонкий импотент бэкенд.
Сначала в js ветку.
Может там вообще все языки загружаются liba.js.

мда... а еще ко мне претензии. Вопрос был в том как переводы хранить на фронте? в бд или в properties файлах. при чем тут jsp я вообще хз... при чем тут ветка js тоже хз...

chpashaблин, столько флуда ни о чем. Как и в чем хранить зависит от того как удобней пользоваться и какие инструменты используются. Кроме того важно как и кем осуществляется редактирование/перевод/добавление языков. Т.е. например, если переводы мы делаем сами - то вообще пофиг где и как. Можно и в property файлах, если например юзаем редактор понимающий языковые bundle (например та же IDEA). Если в этом задействованы уже двое/трое/много, то csv/excel будет уже не так неудобно, особенно при необходимости объединения изменений, да и property-файл может поставить простого пользователя в тупик.
Лично я на одном из проектов использовал такой подход: переводы в бд, редактируются через фронтенд несколькими людьми (фронтенд не в смысле клиент бд, а именно формочка со списками переводов, поиском и редактированием), клиенту переводы отдаются скопом при загрузке в виде json
Спасибо)

chpasha, а если в бд будет около 10к переводов. это же бд тяжко будет

Petro123смешно.
скажите в каком месте смешно и я тоже посмеюсь.