Как обычно делают i18n на уровне БД? 
Т.е. если надо интернационализировать не только UI, но и некоторые таблицы.

Это сообщение отредактировал(а) dementiev - 18.2.2010, 02:00

Подводные камни здесь такие:

а) Надо в БД/таблицах установить charset unicode и использовать поля типа nvarchar, nchar и ntext (для SQL Server) 
б) Надо как-то определиться как хранить в базе мультиязычные дела. Некоторые все поля дублируют, некоторые дублируют таблицы - есть и такие кто сразу дублируют БД. Есть подход, когда каждая запись в таблице имеет поле принадлежности к тому или иному языку.
в) Четко надо понимать что делать с коллейшном. Допустим делаем запрос к БД с арабским профилем - допустим каким-то образом определились как будет сформирован (из каких бд/таблиц/вью) запрос. Теперь нужно выдать его с правильным коллейшном. Лучшее решение которое я видел - это отдельная таблица где хранятся правила коллейшнов.

Мой личный преференц (с учетом того что работать надо будет из Java):
1) Естественно все строчные/символьные поля в БД на unicode (лучше сразу на UTF-16)
2) В каждой таблице присутствие обязательного индексируемого поля LANGUAGE (если не ломает можно добавить и CULTURE) - по которому делаем фильтр по языку, понимая, что если поле NULL - это язык по умолчанию
3) Отдельная табличка для COLLATION где для каждой пары LANGUAGE/CULTURE сопоставлено правило для ORDER BY
4) Все это хозяйство запихиваем в Hibernate, где перед каждым запросом должны знать значение LANGUAGE/CULTURE - пишем на Java/HQL/SQL несложную надстройку для модификации запроса с тем, чтобы из БД возвращались всегда i18n-specific ответы.

Ну типа:


Где значение ARABIC/IRAQ должен давать клиент, а значение Arabic_CI_AS это результат подчиненного запроса к таблице коллейшнов

Что такое интернационализация таблиц? У тебя что пользователь будет лазить в базу SQL клиентом?