_Your new understanding has made you powerful. Please use your new powers for good._ ##1.25.1 固定的中文寫法 一直以來，我們都是硬編碼方式返回中文的文案或者提示，如： ```javascript $rs['msg'] = '用戶不存在'; ``` 這種寫法在項目根本不需要考慮國際化翻譯時，是完全沒問題的。 ##1.25.2 通用的翻譯寫法 當我們需要進行翻譯時，可以這樣進行調整： ```javascript $rs['msg'] = T('user not exists'); ``` 然后在對應的翻譯文件中（如中文對應文件是：./Language/zh_cn/common.php）添加對應的翻譯即可： ```javascript // $vim ./Language/zh_cn/common.php return array( 'user not exists' => '用戶不存在', ); ``` ###(1)當存在動態變量時？ 有時，我們需要動態返回一些值，這里可以用 **大括號** 將需要動態替換的值包住并提供替換的參數即可，一如： ```javascript echo T('hello {name}', array('name' => 'dogstar')); ``` 如果對應的中文翻譯是： ```javascript 'hello {name}' => '您好，{name}', ``` 將會看到輸出： ```javascript 您好，dogstar ``` ###(2)當多個動態變量時，還可以這樣省略變量名 如果要簡化動態變量的傳遞，可以這樣： ```javascript echo T('{0} I love you because {1}', array('PhalApi', 'no reasons')); ``` 如果對應的中文翻譯是： ```javascript '{0} I love you because {1}' => '{0} 我愛你因為{1}', ``` 將會看到輸出： ```javascript PhalApi 我愛你因為no reasons ``` ###(3)當翻譯不存在時？ 翻譯不存在，有兩種場景：一是指定的語言包不存在；二是語言包存在但翻譯不存在。無論何種情況，找不到翻譯時，都會用代碼硬編碼的內容返回。 ##1.25.3 語言的設定 當我們擁有了多種語言時，則可以在入口/初始化文件中，選擇設定需要的語言。 ```javascript SL('zh_cn'); //SL()函數等效于PhalApi_Translator::setLanguage() ``` 參數即為語言包的路徑名，如下面的en, zh_cn： ```javascript . |-- en | `-- common.php `-- zh_cn `-- common.php ``` 此處，也可以通過客戶端傳遞參數來自行選擇語言。簡單地： ```javascript SL($_GET['lan']); ``` ##1.25.4 添加語言翻譯包 有時需要手動添加語言翻譯包，因為對應的翻譯不一定在項目的./Language下，如擴展類庫。 當需要添加額外的語言翻譯包時，可以這樣添加： ``` PhalApi_Translator::addMessage(API_ROOT . '/Library/User'); ``` 在User這個目錄下的翻譯包類似地，為： ``` ./Language/ └── zh_cn └── common.php 1 directory, 1 file ``` 相當于追加一個額外的項目路徑，其他的加載過程和原來的一樣。 ##1.25.5 建議 所以，你可以輕松看到，所謂的翻譯也只是通過數組下標找一下對應的內容而已，沒有太多的技術性，也沒有過多的性能問題。 但正是有這樣提前周到的國際化準備，我們可以對外（如像產品、BOSS和外界）傳送這樣一個隱喻： **我們的項目可以快速支持國際翻譯** 。 這聽起來多么高大尚啊！因為那些不懂技術的人，根本不在乎是用PHP的數組來存放還是什么技術，而在于能不能走向國際化。 SO？既然翻譯”無傷大雅“（指對性能的影響和對代碼編寫的阻礙），統一使用翻譯的寫法是值得推薦的。 即使項目沒有機會用到真正的翻譯，但至少有兩點我認為也是有用的： + 1、便于產品維護接口返回的提示文案； + 2、被同行問到時，你們有支持i18n嗎？我們也可以笑著回答：有 ^_^ ；