和同事争执了一个很细节的设计问题
下午的时候,和同事讨论了产品安装包中国际化的一些问题。本来对于一个通过简单的Loader窗口来拾取安装主界面语言的经典国际化安装界面模式,是没有什么问题和不妥,可是对于这个Loader窗口本身的国际化配置文件,我却和他在一个很细节的设计上有了一些不同的意见。
这个Loader窗口其实只有4个控件,一个Label、一个ComboList和两个Button。需要国际化的地方也就4处,窗口标题、Label内容和两个Button,如下图:

本来要是从我的看法来说,这种窗口根本不做国际化都完全说得过去的,但是既然PM的spce规定要国际化,那就做呗。于是这里要说的细节问题,就是关于这4个国际化资源的存储格式的。同事的设计是使用*.ini文件来存放Loader窗口的国际化资源,其存储格式大概为:
使用*.ini文件,我觉得到没有什么,反正有现成的API可以读取。只是对于[Languages]节点的设置,我感觉有待商榷。[Languages]节点功能其实一目了然,也就是设定默认语言、语言种类计数和语言描述。而我觉得这个ini文件中Languages Section是多余的,完全没有必要,这里面除了Default这个key/value对外,其它的描述可以说是一种冗余的信息,只要有了下面各种具体语言的Section,这个Count以及Key的信息也就自动有了,而在Languages Section中放置Count和KeyN,反而会带来修改ini文件时需要手动同步信息的负担,使得该ini文件没有做到真正的文档格式自描述。
取消掉Languages Section中的Count和KeyN后,我们要获得ini文件中语言编号的列表,可以直接通过调用Win32 API函数GetPrivateProfileString(string lpAppName, string lpKeyName, string lpDefault, byte[] byBuffer, int size, string lpFilePath),使lpAppName为NULL就行了。
可是同事却坚持认为,[Languages]节点中的Count和KeyN是有必要的,而且就是在修改ini文件时,即使国际化的语言有10多种,靠改文件时自己数清楚Count也是不难的事。我也并不是觉得数数语言的个数是mission impossible,但使我有些郁闷的是虽然我确实觉得那个设计不是很好,可也没有很有力的观点来支持我自己的意见。当然这个问题本身不是什么原则性的问题,而且按我们Product Team的规定,非原则性问题的最终决定权归具体实现者:)
这个Loader窗口其实只有4个控件,一个Label、一个ComboList和两个Button。需要国际化的地方也就4处,窗口标题、Label内容和两个Button,如下图:

本来要是从我的看法来说,这种窗口根本不做国际化都完全说得过去的,但是既然PM的spce规定要国际化,那就做呗。于是这里要说的细节问题,就是关于这4个国际化资源的存储格式的。同事的设计是使用*.ini文件来存放Loader窗口的国际化资源,其存储格式大概为:
[Settings]
// some settings for setup
[Languages]
Default=1033
LangCount=2
Key0=1033
Key1=2052
[1033]
Language=English
Title=Select Setup Language
Description=Select the languge to use during the installation:
Ok=Ok
Cancel=Cancel
[2052]
Language=中文(简体)
Title=选择安装语言
Description=请选择在安装过程中使用的语言:
Ok=确定
Cancel=取消
// some settings for setup
[Languages]
Default=1033
LangCount=2
Key0=1033
Key1=2052
[1033]
Language=English
Title=Select Setup Language
Description=Select the languge to use during the installation:
Ok=Ok
Cancel=Cancel
[2052]
Language=中文(简体)
Title=选择安装语言
Description=请选择在安装过程中使用的语言:
Ok=确定
Cancel=取消
使用*.ini文件,我觉得到没有什么,反正有现成的API可以读取。只是对于[Languages]节点的设置,我感觉有待商榷。[Languages]节点功能其实一目了然,也就是设定默认语言、语言种类计数和语言描述。而我觉得这个ini文件中Languages Section是多余的,完全没有必要,这里面除了Default这个key/value对外,其它的描述可以说是一种冗余的信息,只要有了下面各种具体语言的Section,这个Count以及Key的信息也就自动有了,而在Languages Section中放置Count和KeyN,反而会带来修改ini文件时需要手动同步信息的负担,使得该ini文件没有做到真正的文档格式自描述。
取消掉Languages Section中的Count和KeyN后,我们要获得ini文件中语言编号的列表,可以直接通过调用Win32 API函数GetPrivateProfileString(string lpAppName, string lpKeyName, string lpDefault, byte[] byBuffer, int size, string lpFilePath),使lpAppName为NULL就行了。
可是同事却坚持认为,[Languages]节点中的Count和KeyN是有必要的,而且就是在修改ini文件时,即使国际化的语言有10多种,靠改文件时自己数清楚Count也是不难的事。我也并不是觉得数数语言的个数是mission impossible,但使我有些郁闷的是虽然我确实觉得那个设计不是很好,可也没有很有力的观点来支持我自己的意见。当然这个问题本身不是什么原则性的问题,而且按我们Product Team的规定,非原则性问题的最终决定权归具体实现者:)
posted on 2006-02-18 00:21 birdshome 阅读(2537) 评论(12) 编辑 收藏 举报
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· .NET周刊【3月第1期 2025-03-02】
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器