定義：在源代碼中擁有本地化文件vs硬編碼變量的優缺點是什麼？
文件：
具有存儲在物理文件中的本地化短語，使程序在應用程序啓動時讀取和短語存儲在存儲器通過UTIL-方法進行訪問。短語以鍵值格式存儲。每種語言一個文件。
變量：
本地化的文本存儲在應用程序的源代碼硬編碼的變量。變量是複雜的數據類型，根據當前的語言，返回適當的短語。
背景：
的應用程序是一個Java Servlet和開發人員使用Eclipse作爲其主要的IDE。
一些簡短的利弊：
由於Eclipse是使用，跟蹤和發現未使用的本地化更容易時，他們被保存作爲變量，而在一個文件中有他們。但是，應用程序的源代碼變得更大和臃腫。
什麼是在文件中的本地化文本與源代碼中的硬編碼變量的優缺點？你做什麼，爲什麼？
更新1：在我的具體情況下，重新編譯和部署不是問題，因爲它已完成，因爲我們有測試階段，使我們有機會找到錯別字等。因此，我們很少需要更改應用程序在生產時的短語。
在其源代碼中進行應用程序本地化有許多缺點 - 可能是最大的缺點，即當您想修復/添加/刪除某些本地化時，必須重新編譯並重新分配新版本。使用單獨的文件，更新更加靈活，更快速，更容易維護，當然其他人可以添加本地化到您的應用程序，而無需訪問代碼。
所以我會建議去與單獨的文件選項，而不是硬編碼到應用程序。
在理想的世界中，您的配置文件將經歷與源文件一樣嚴格的變更管理流程。 （代碼是代碼）但是，我發現通常配置的控制較少，修復可以更快地推出。 – 2010-06-03 14:15:02
對於我的具體情況，無論如何都是每天都進行重新編譯和部署。我們永遠不需要在不進行重新編譯/部署的情況下更新本地化文件。 – corgrath 2010-06-03 14:16:58
即使在這種情況下，我會建議去文件。您的情況在未來可能會發生變化，當項目完成時，維護它將變得更加容易。最後一個觀點是：「它的良好做法」。此外，您仍然可以將版本控制下的本地化文件與其一起使用，就像它們是真正的源代碼一樣。 – PeterK 2010-06-03 14:31:23
如果您的項目將被數百人使用，本地化是值得的，因爲其中一些人更傾向於熟悉另一種語言。如果這個項目只用於內部使用，那麼硬編碼變量就沒問題。如果用戶數量低於100，尋找翻譯員和維護每個本地化文件的任務過於繁瑣。
我想有親和好:) – corgrath 2010-06-03 14:17:24
我認爲「文件」和「變量」之間沒有選擇。因爲它應該始終是「文件」。
優點：
一）易於維護 - 整個定位是在一個單一的文件。
b）當有變化時不需要重新編譯。
c）易於引入另一種語言。
通常筆譯員是 非技術人員。
不需要改變 多個地方。
如果您打算使用本地化版本的程序，那麼您很可能在某個時間點需要翻譯器。如果你沒有本地化文件，你必須讓翻譯者使用字符串資源訪問每個源文件（你甚至知道它們是哪一個？），然後你需要手動修改源文件，這很容易出錯。
對於大型軟件公司來說，本地化過程傳統上是由開發團隊（通常是在不同的國家）的獨立小組執行的。本地化組織經常使用二進制文件 - 因此對資源包的要求是單獨的人工製品。該過程的目標之一是不要讓譯員打破源代碼;另一個是不讓程序員破壞字符串。
從您的意見，這聽起來像你有工具來做一些替代形式的自動字符串提取和插入。如果做得對，這可能是一個可行的選擇。
問題，我會問你的翻譯過程：
\uXXXX缺乏支持的字符轉義使用壽命較長的產品可以累積未使用的資源，但我從未見過它成爲一個實際問題。如果您對此感到強烈，則可以通過掃描源來檢測未使用的密鑰。
當你指的是「硬代碼變量」你是指靜態決賽？ – 2010-06-03 14:11:23
在我的情況下，不，因爲我們仍然希望有機會在運行時改變它們的值 - 以防萬一。 – corgrath 2010-06-03 14:20:06
而且，你的意思是「在源代碼中」你根本沒有進行本地化？或者你有一系列.java文件，這些文件基本上是字符串映射的容器類？ – 2010-06-03 14:20:17