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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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