Лучший способ перевести устаревшее программное обеспечение на несколько языков? - PullRequest
1 голос
/ 04 января 2012

В моей компании есть веб-приложение, которое мы разрабатываем более 5 лет.У нас все еще есть кодовая база, которая содержит PHP4 и была расширена за счет загрузки PHP5.LOC довольно большой, около 471 тыс.Он не основан на фреймворке, ORM и т. Д. И т. Д.

Разработчики, которые начали с этого проекта, игнорировали любые i18n и переводы.Все языковые тексты жестко запрограммированы в программном обеспечении.Да, я знаю, что это отстой.На данный момент у нас все хорошо, поскольку мы продаем это только на том языке, на котором написано программное обеспечение, но мы также рассчитываем на расширение за рубежом.

Я борюсь с лучшим подходом к переводу.Как бы вы, ребята, подошли к этому?Было бы лучше переписать с использованием фреймворка, так как это, вероятно, также улучшит кодовую базу и обеспечит надежную структуру.Или вы просто используете текущее программное обеспечение и отфильтровываете языковые тексты.

Любые советы и подсказки на эту тему приветствуются!

Ответы [ 5 ]

2 голосов
/ 04 января 2012

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

Если он все еще стабилен, работает нормально, а PHP4 и другие «вкусные вещи» вам не нужныНе нужно, вы можете оставить и просто просмотреть все жестко закодированные тексты.Помощников i18n очень легко сделать.Вам больше ничего не нужно делать:

  • Выберите подходящий способ хранения текстов и переводов
  • Механизм кэширования для уже загруженных переводов
  • Класс и помощник для операций i18n.

Вы должны хорошо проанализировать свой бизнес-план, если решите переписать свой код.

1 голос
/ 04 января 2012

По моему опыту, нехорошо иметь один проект с двумя основными целями, особенно если эти цели практически не связаны с точки зрения бизнеса. У меня была бы одна команда проекта, отвечающая за локализацию (которая может включать не только перевод - в разных странах существуют разные юридические требования, валюты, поставщики платежей и т. Д.), И одну команду для «улучшения кодовой базы».

Я бы начал с того, что группа по локализации разработала примерный план (и стоимость) для «самого простого, что вы могли бы сделать» - ретроспективной настройки функций локализации на сайте, как сейчас. Если эта стоимость не является неприемлемой с деловой точки зрения - я бы пошел по этому пути.

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

Если бы на самом деле не было реалистичного способа выполнить локализацию без усилий по рефакторингу, я бы по-прежнему выполнял ее с двумя отдельными командами. Команда по локализации может быть основным владельцем требований для команды рефакторинга, и им действительно нужно работать вместе, но, поддерживая оба проекта независимо друг от друга, вы избегаете риска того, что вы получите 90% рефакторинга, но только 10% локализация.

1 голос
/ 04 января 2012

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

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

0 голосов
/ 04 января 2012

Это зависит от приоритетов и того, что вы должны делать.

Если основной проблемой является перевод языка, то вы можете начать с простого извлечения жестко закодированных строк, чтобы они моглиинтернационализированный.

Если есть другие потребности, например, желание легко поддерживать разные базы данных, это поможет определить, существует ли лучший подход.

0 голосов
/ 04 января 2012

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

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

Многое изменилось за последние 5 лет, так что если это приложение, которое вы планируете продаватьеще много лет, это, вероятно, стоит инвестиций в редизайн.

...