2012-03-20 21 views
3

據我所知,使用資源文件的本地化字符串來處理.NET動態數據的最佳方式是讓你的本地化字符串與resources.resx文件一個佔位符:Lorem {0} ipsum。並在您的代碼中,以這種方式處理:string.Format(Resources.My_Localized_Key, myValue);資源文件的String.format和佔位符在.NET

我關注的是以下幾點:

1 /如何確保佔位符將由實際值來代替?例如,您的團隊中的新開發人員可能需要在他正在編寫的一些新代碼中使用此本地化字符串,但不知道他必須用一些數據提供它。也沒有什麼樣的數據。

2 /如果以後,由於某些原因,該本地化字符串變爲的Lorem {0} ipsum的{1}。,我們如何確保跨應用程序使用此字符串的所有用途都將被更新?

有沒有更好的方法來處理這個問題?例如,以強類型方式處理這些佔位符的方法,而無需使用反射或必須解析本地化字符串的內容...?還是僅僅是這樣做的方式?

+0

這位新開發人員將如何知道如何使用此消息?要麼他會找到現有的代碼(已經將其包裝在一個「格式」中,或者他正在瀏覽資源(在這種情況下,他將閱讀消息並查看「{0}」佔位符)。需要提供格式調用 – 2012-03-20 11:57:30

+0

這是事實,但對我來說最重要的第二點仍然有效:這樣做並不會強化佔位符的數量。 – Guillaume 2012-03-20 12:06:26

回答

1

在實踐中,第1個開發商大概不會重用一個字符串,而不檢查其內容,如果他們做到了,當他們運行他們的代碼(或QA會),他們可能會注意到佔位符。所以這不太可能,也不會是世界末日。

對於問題2,您可以在Visual Studio中使用「Find Usages」查找自動生成的屬性,該屬性爲資源創建,以查找其使用的每個位置,並確保參數的正確編號(和順序)在那裏在任何地方使用。但總的來說,資源字符串不會被重複使用(實際上,由於語言規則或空間限制,實際上不建議在不同的上下文中重用可本地化的文本,因爲翻譯可能需要在不同的上下文中進行更改)。

我會看到另一個風險是,譯者可以省略或陷入困境中的佔位符,這將是難以檢測。但是,這只是一個本地化bug的例子......當本地化應用程序時,還有很多其他事情可能會出錯,並且通常沒有辦法防範它們。

0

我認爲你可以寫你自己的Visual Studio定製工具(http://www.codeproject.com/Articles/31257/Custom-Tools-Explained),它可以從resx-file生成Resources類並使用它來代替標準一個。在你的工具中,你可以解析本地化的字符串,如果它有佔位符,那麼你可以生成方法,而不是屬性Resources.My_Localized_Key。根據佔位符的數量,方法可以看起來像帶有適當數量的參數的Resources.My_Localized_KeyFormat(object param)

但這僅僅是想法,我還沒有實現它自己(但我沒有實現的自定義工具,代碼生成的resx-文件,它工作正常)。

或者你可以使用F#這在編譯時檢查PARAMS其版本的String.format的。

+0

僅當編譯器在編譯時已知(格式)字符串時,編譯時檢查纔會起作用。 – 2012-03-20 14:07:59