Архитектура программного обеспечения для локализации

В настоящее время мы внедряем программное обеспечение для онлайн-бизнеса на другие рынки ЕС, где не только язык, но и правила и нормы отличаются от страны к стране, что заставляет меня задуматься, каков наилучший способ внедрения такого программного обеспечения?

Локализация пользовательского интерфейса на самом деле не является проблемой — это делается больше раз, чем я мог бы сосчитать, но, например, в то время как странам, выставляющим счета, обычно требуются разные данные (ну, не совсем разные, но достаточно разные, чтобы вы думали об этом в архитектуре) это означает разные входные данные, разные проверки и несколько разную обработку этих данных.

Какой способ можно считать лучшим?

  • Стандартный способ локализации пользовательского интерфейса и добавления необходимых условных операторов для отображения дополнительных и скрытия несущественных элементов с аналогичными условными выражениями в классах Controller
  • Создание копии приложения для данной страны со слегка измененными контроллерами и представлениями (что сделает постоянные обновления кошмаром, но код станет намного чище)
  • Пытаетесь как-то создать шаблон Factory / Builder вокруг этого?

Хотя последний из них звучит для меня наиболее разумно, он расстраивает меня еще больше, поскольку я пока не знаю, с чего начать. Какие-нибудь хорошие указатели на это?

Язык выбора — PHP с Laravel

0

Решение

Определенно не делайте разные копии.

Посмотрите на вашу текущую архитектуру базы данных и посмотрите, как вы можете расширить ее для удовлетворения ваших требований. Затем перепишите или обновите уровень кода бизнес-логики вашего приложения.

Тогда вам нужно будет лишь внести незначительные изменения в интерфейс.

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]