在我的公司，我們有一個我們已經開發了5年以上的Web應用程序。我們仍然有一個包含PHP4的代碼庫，並且已經擴展了大量的PHP5。 LOC很大，約471k。它不基於框架，ORM等等。將遺留軟件翻譯成多種語言的最佳方法？
開始使用此項目的開發人員忽略了任何i18n和翻譯。所有的語言文本都在軟件中進行了硬編碼。是的，我知道這很糟糕。 目前我們很好，因爲我們只用軟件的語言來銷售這些軟件，但我們也在考慮向國外擴張。
我正在努力處理翻譯的最佳方法。 你們會如何處理這個問題？使用框架重寫會更好，因爲這可能會改善代碼庫並提供一個堅實的結構。或者你會只使用當前的軟件並過濾出語言文本。
任何有關這個問題的提示和提示，讚賞！
這聽起來像你有超過一個翻譯項目在你之前。如果你想把它帶到國外，你會有重新設計至少部分的系統。
如果您的預算允許並且利益合理，您將需要退後一步並查看整體設計。保持你所能做到的，但不要害怕破壞，重新設計，替換和升級它的主要部分。
在過去的5年裏發生了很大的變化，所以如果這是一個計劃賣出多年的應用程序，它可能值得投資於重新設計。
是的。我想我也會考慮devdRew的商業計劃評論。此外，當您使用現代框架代替時，很難預見重寫5年遺留產品的影響/時間。 – tomvo 2012-01-04 19:13:26
分解成模塊並評估每個模塊。他們可能不需要重寫。確定模塊重寫的成本/工作影響比爲整個系統做更簡單。 – 2012-01-05 18:31:26
這取決於優先事項是什麼，至於你應該做什麼。
如果主要關注的是語言翻譯，那麼您可以從取出硬編碼字符串開始，使其可以國際化。
如果還有其他需要，比如想輕鬆支持不同的數據庫，那麼這將有助於確定是否有更好的方法。
我認爲這兩種變種都是可能的。你可以留下你的代碼，或者重寫。但正如你所知，重寫是一個漫長的過程，儘管如此，你已經寫了5年多了。
如果它仍然穩定，可以正常工作，並且不需要PHP4和其他「美味的東西」，那麼您可以離開並僅檢查所有硬編碼文本。國際輔助人員非常容易製作。你所要做的僅此而已，那麼：
如果你決定重寫你的代碼，你應該很好地分析你的商務計劃。
這也是對所有答案的評論，我想我的問題的一部分也是處理遺留問題時的挫敗感，當你在開發者世界中看到許多新的偉大的東西出現在你身邊時。它使你想把它扔掉，從頭開始。 – tomvo 2012-01-04 19:10:32
我們都遇到過這種情況，但您必須戴上您的商業夥伴帽子並說「對企業最好？」開發很少專注於使用我們可用的所有有光澤的新玩具。這是關於在一個有效的和成本效益的莊園完成工作。 – 2012-01-05 18:33:21
還有其他答案。翻譯幾乎相同的字符串非常昂貴。將其與語言數量相乘，人們意識到：通過共享相同的字符串和格式可以實現更好的國際化效率。
第一次重寫模板部分，可能是有道理的。首先用手寫，然後用你寫的自動轉換工具。它應該準備I18N。
如果我說大概50％的PHP代碼會生成HTML並且沒有模板，該怎麼辦？ – tomvo 2012-01-04 15:28:31
我只是知道你的感受;遺留代碼的豐富經驗。但您至少必須將HTML轉換爲適合國際化的組件（如'
根據我的經驗，單個項目有兩個主要目標並不是一件好事 - 尤其是如果這些目標幾乎完全與商業角度無關。我會有一個項目團隊負責本地化（這可能不僅涉及翻譯 - 不同國家有不同的法律要求，貨幣，支付提供商等），還有一個團隊負責「改進代碼庫」。
我首先讓本地化團隊針對「您可以做的最簡單的事情」制定出一個粗略的計劃（和成本），即現在正在對網站進行改裝的本地化功能。除非從業務角度來看，這筆費用是不可接受的 - 我會沿着這條路線走下去。
如果重構的業務案例尚未完成，我不會試圖將它放到您的本地化項目中 - 我曾經見過類似的事情發生過，所有的開發人員都希望在酷重構東西，討論各種框架的相對優點，以及使用哪種源代碼控制系統，而企業關心的事物則推向未來;最終，企業主失去了對該項目的興趣，並取消了它。
如果真的沒有現實的方式來做本地化沒有重構的努力，我仍然運行它與兩個，分開的團隊。本地化團隊可以成爲重構團隊的主要需求所有者，他們確實需要一起工作 - 但通過保持兩個項目獨立運行，您可以避免重構90％的風險，但只有10％本地化。
我想所有的答案都可以幫助我決定下一步該做什麼。我還需要接受答案嗎？ – tomvo 2012-01-09 14:21:20