Добрый день.
Есть некое intranet web-приложение (C# MVC5, EF, knockout) для работы с продуктами — обновление спецификаций, картинки, то-сё. Используются все более-менее стандартные best practices Microsoft — MVC, DataAnnotation, никаких особых извращений не выявлено. Проект писался нами, примерно 6 чел/месяцев.
Сейчас заказчик захотел добавить возможность данные вводить не только на английском, но и на французском языках. В то же самое время интерфейс вполне себе остается английским. Т.е. если было
Product Name: [_______]
Product Image: [upload]
то теперь это надо как-то подружить и со вторым языком.
Итого вопросы:
Как это сделать наиболее "мякгим" способом, не ломая существующий код/логику? Всё с нуля переделывать не хочется.
Визуальная соствляющая — как наиболее интуитивно сделать переключалку между языками + индикацию наличия перевода (или устаревшего перевода)? Может кто видел что-то похожее на рынке?
База — как грамотнее сделать базу? Мысли пока были следующие:
(a) Хранить в product_name сериализованный xml/json со всеми языками/статусами — тогда вообще никаких изменений в базе не надо
(b) Сделать копию структуры в новой базе DB_fr — и в неё писать уже только перевод. Плюсы — текущая база остается без измнеений
(c) Сделать таблицы вида Product_fr, ProductModel_fr — и в них уже хранить, что надо.
(d) Расширить существующие таблицы — Product { name, name_fr, name_translation_status ... }
лично я склоняюсь к варианту 3d вот примерно так:
Все поля, которые надо переводить, в моделях EF пометить свои аттрибутом [Localizable]
Написать автоматическую генерацию partial class по этим аттрибутам для расширения существующих моделей — {name_fr, name_translation_status, ... }
Написать расширение маппера, что бы теперь и для моделей вьюх эти поля автоматические по аттрибутам генерились/подсасывались
сделать свой Html.EditorFor — для корректной работы с [Localizable] полями
мне так кажется, это покроет процентов 80 всей работы. Ну и дальше уже руками допиливать оставшиеся моменты.
Я в том направлении мыслю? Или может есть какие-то устоявшиеся паттерны? Спасибо.
Здравствуйте, avs99, Вы писали:
A>Сейчас заказчик захотел добавить возможность данные вводить не только на английском, но и на французском языках. В то же самое время интерфейс вполне себе остается английским.
Это скорее всего ненадолго.
A> Визуальная соствляющая — как наиболее интуитивно сделать переключалку между языками
Обычный флажок чем не подходит? Это же веб-приложение.
A>+ индикацию наличия перевода (или устаревшего перевода)?
Предположу, что эта индикация нужна далеко не всем, а только сотруднику, ответственному за полноту перевода. Остальным же будет только мешать.
A> База — как грамотнее сделать базу? Мысли пока были следующие:
A>(a) Хранить в product_name сериализованный xml/json со всеми языками/статусами — тогда вообще никаких изменений в базе не надо
A>(b) Сделать копию структуры в новой базе DB_fr — и в неё писать уже только перевод. Плюсы — текущая база остается без измнеений
A>(c) Сделать таблицы вида Product_fr, ProductModel_fr — и в них уже хранить, что надо.
A>(d) Расширить существующие таблицы — Product { name, name_fr, name_translation_status ... }
A>[/list]
(e) Каждое локализуемое символьное поле заменить ссылкой на словарь (один для всех таблиц). Затем построить параметрические view. Для изменений — процедурный API.
