overview
overview copied to clipboard
program-in-chinese
参考MSDN，试搞.NET类库标识符的翻译版
肛他.jpg MSDN链接：.NET Framework 类库
是的，如你所见，这里面的文档一眼望去就是机翻。 不过，我们我们不要去纠结文档，择重要的（如System.Collections）对着“命名空间”、“类名”、“结构名”等等标识符（有些带模板声明的……想想怎么办）搞，某些用词仔细推敲一下订立一些标准，维护一个结构化的翻译结果。
各位意下如何。
这个思路和https://github.com/program-in-chinese/overview/issues/37 类似吗? 感觉可以探讨, 但很难形成直接实用工具吧. 当时我把java.util.Collections翻成了"集合们" :)
@nobodxbodon 对于Collections，我的想法是“容器类”。 并不是一对一照搬翻译（虽然也不是强行反直译，联想到易语言本土化命名的一些努力，有价值但确实有点反直译反现行译名）。翻译总是去找那一个最合适表达的嘛。
这个容器不一定要直接联想到Container，取“装东西”之意，类也不光是class，实际上它是个命名空间但是里面装了一些class（实际上里面还有一层命名空间……），这里类表示“容器这一类的东西”，顺便也可以表达集合概念“里面装的是容器class们”，这个“类”其实对应的是“s”。至于里面的class，就都按各自数据结构来命名了，英文命名也没见每个都吊一个XxxClass。
@farteryhr
并不是一对一照搬翻译（虽然也不是强行反直译，联想到易语言本土化命名的一些努力，有价值但确实有点反直译反现行译名）。翻译总是去找那一个最合适表达的嘛。
很同意.
里面的class，就都按各自数据结构来命名了，英文命名也没见每个都吊一个XxxClass。
之前我倾向于类名加后缀"类"主要是为了在名字上区分类和方法/变量. 因为中文命名后没有了大小写区分.
@nobodxbodon 作为vb用户表示是并不喜欢某些大小写用法的。 具体到中文命名的类与实例。 比如容器类，首先就不赞同List list，Vector vector这种做法。容器数据结构名称作为类，其实例对象，装的是啥东西，名字就叫啥，最多是单复数问题，可以前加“所有”，“诸”，后缀“集”，“们”，中英结合缀个s都没毛病，为何要去跟数据结构撞名？ 大概是只有在毫无目的测试容器类库的时候才找不到名字，此时放心地列表1列表2好了，甲乙丙天地人ABC都可以…… 有意义的类，其实例，我觉得仍然，如果一定要跟类名撞，多半是命名完全不达意。稍加修饰指明这是这类的什么实例，强制更易读，甚至觉得这设定挺好（汉字优势就在于多加两个字就能精确很多，哪怕变量普遍四五字，表意精确也不过长，正是潜力所在）
@farteryhr
不赞同List list，Vector vector这种做法
很同意
如果一定要跟类名撞，多半是命名完全不达意
现在感觉应该是这样, 在之前的个人实践中, 好像碰到过撞名, 但可惜没记下场景.
稍加修饰指明这是这类的什么实例，强制更易读，甚至觉得这设定挺好
这个风格好像是个选项. 个人比较在意的问题是, 代码风格目的在于统一整个代码的语义格式, 而这种风格最好足够简单可行, 不然协同开发时团队一大就困难了(当然, 不同背景和水平的团队都可以有自己的代码风格, 但一个业界基本公认的最低风格还是必需吧). 我觉得可以做一些实验. 有条件的话做一些简单的封装(类似 #37, 但肯定是小规模, 从最核心的部分开始), 然后用这个汉化库开发或者汉化一些简单的库/应用. 从实践中总结更有说服力. 不知你是否有其他的想法将这个标准翻译列表付诸实践?
另外, 想到 #11 中的这一条, 其实和命名空间很有关系:
集成代码版本控制功能, 语言开发团队对语言/标准库与用户库/项目提供版本控制服务, 以提高团队开发效率, 促进共享, 提升整体代码水平
理想情况, 所有人(包括第三方)开发的库/应用都可以共享到这个平台, 而符合最低代码风格, 有足够文档(这个也许也需要有个规范?), 而且没有命名冲突的话就可以合并到"准核心"库供所有用户查询使用(就像集成了Maven库API搜索功能的一个开发环境). 这样可以最大限度地减少重复劳动, 也可以及时规整命名空间.
感觉楼主是倾向于规整一套命名空间的英文术语的对应中文, 而不是开发一套.NET的汉化库(或者子集). 请问 @jeffreybaoshenlee 有什么看法? 因为感觉和https://github.com/jeffreybaoshenlee/IT-Terms-EN-CN 的思路有点接近.
@nobodxbodon 嗯，我感覺樓主的這個想法，與 .NET 結合得較為緊密，應該根據 .NET 的內在邏輯，與 .NET 用戶/開發者的實際習慣來推進。（至於我的那個項目麼，則較為寬泛一些，目前還沒有形成想要規範某一套特定術語的想法。）
@jeffreybaoshenlee 哇，看了下你的那个repo，我其实也有相同想法，整理一些可优化的IT术语翻译。目标也很有共鸣，不刻意不勉强，就去找最合适的。 不过放在github上似乎有点不太方便有想法的（平常人/中文语文水平比较高的人）提供意见…… 甚至想过做一个极简的，术语翻译想法分享页，带吃瓜群众投票什么的。（日常空想
至于这个.NET库标识符【其实就是随手一选，抽象一点来说就是“订立可行的翻译某种语言的标准库的流程”】，应该是一个人或者少数几个人组团来完成并且定稿的，因为毕竟是个整体还是要保证某种一致，而且目的是比较务实的。
@farteryhr 嗯，如果要收集大家的意見，而且要經常討論，那麼確實應該考慮採用一種更順暢的流程。比如某種事務管理或項目管理軟件，也可以通過提交表單等辦法來實現（暫時想到了這些，我還沒細想……）
（又或者，可以採用維基百科那種開放給衆人編輯的模式？但是可以指定幾名核心編輯，用來協調意見上的衝突……）
之前https://github.com/program-in-chinese/overview/issues/37 做了一些相关工具, 比如提取JDK的所有类/方法名之类. 下面是一些统计: 在JDK源码的整个java路径下, 1579个(顶层)类; 5093个公用方法; 3426个方法参数 在常用的java/util下(不包括子目录), 有120个类;540个方法;440个参数
接着, 如果把Camel命名法的类名拆成单词, 比如ArrayList-> [Array, List], java/util下的类名有110个单词, 而整个路径下的类名有864个单词. 其中还有不少同词根仅单复数不同的: Array, Arrays; Charset-Charsets等等. 如果加上方法和参数名, 单词数分别是628和3315.
没有对.net的进行统计. 不过估计量级差不多. 工作量还是可观的, 尤其考虑到单个词找到对应翻译后, 组合起来还可能不一定顺畅的问题.
另外, 同一个词, 比如Array, 如果语义相同, 是否要在不同语言间用一个翻译?
@nobodxbodon 同一个单词大部分情况下是要统一的，但是ArrayList这个情况我觉得是比较例外的，只要这两个单词某种程度上结合了、变成常用术语、含义有引申了，都可以考虑给一个更准确的新名。
以及上面其实也提到了大写版后缀“类"的做法，也算是一种偏严格的但是读起来不一定通的语义转换做法。我的看法总的来说就是不能一刀切，要看情况具体讨论。
@farteryhr ArrayList如果要特殊处理, 相关的其他相关类/接口(List/AbstractList/LinkedList等等)还要一致风格. 像这样的情况还有不少, 因此一个命名/单词的翻译改动可能会影响到好几个命名.
其实这里讨论的应该就是 @htwx 正在 https://github.com/program-in-chinese/CTS 做的("翻译支持库"), 欢迎分享一下心得.
我这些天正在 翻译 es6 es5 类型文件, 这些类库翻译成中文还是存在好多问题, 或者说真的应该形成个规范.需要征集大家的 意见, 主要问题是, 英文中有 大小写区分, 简写, 单复数也很麻烦. 我总结一下在说吧
@nobodxbodon 哇我才知道有很多个公用了List这个词（
那可能是要保持某种一致了，但是话说回来这个List怎么翻怎么一致，其实就是一个坑了。 不资磁全数“列表”，因为有个LinkedList链表（虽然也是惯例译名）……【链式列表【 直接提取公共字“表”好像也不太对……中文语义下光一个表我觉得很“表格”……
也还是可以考虑换个角度更加直击本质，抛弃字面一致，ArrayList变长组，LinkedList链（随惯用译名链表也可以），List列表（中文按抽象一点的方式理解，可“列”的表）？
Abstract，又是另一个问题了，直接抽象列表，有点过于直译了，但是好像也想不到更好翻法……
@bctnry 一个现实问题是, 没有现成的一个表, 列出那些有共识的命名的对应中文. 一些介绍某个语言的数据结构的译作会对常见的几种数据类型进行翻译. 也许可以基于那些开始归结.
https://zhuanlan.zhihu.com/p/36559989 下开始讨论一个比较汇总的词典, 针对API和编程中命名所用的领域无关词语进行统一的翻译. 打算先找找现有的相关词典, 以及相关项目, 比如 @jeffreybaoshenlee 的https://github.com/jeffreybaoshenlee/IT-Terms-EN-CN
考虑定义一个一致的数据结构, 以方便网页显示以及在此基础上的接口开发. 比如:
[
{
'英文': 'body',
'对应中文': [
{
'中文': '体',
'语境': [
{
'编程语言/框架': 'HTML'
'说明': '表示HTML文档内容所在之处。一个文档中只允许有一个 <body> 元素'
'参考': 'https://developer.mozilla.org/en-US/docs/Web/HTML/Element/body'
},
{
'编程语言/框架': 'Ada'
'说明': '标准关键词之一'
'参考': 'https://en.wikibooks.org/wiki/Ada_Programming/All_Keywords#Keywords:_body'
},
{
'编程语言/框架':
'说明': '函数体, 程序体等等'
'参考': ''
}
]
}
{
'中文': '主体', // 第二种可能译法
'语境': [
{
'编程语言/框架': 'HTML'
'说明': '<body> 元素定义了 HTML 文档的主体。'
'参考': 'http://www.w3school.com.cn/html/html_elements.asp'
}
]
}
]
}
...
]
欢迎批评.
@nobodxbodon 吳先生，我前幾天找到一個討論中文術語翻譯及辨析的項目，叫做書同文，它是掛在 wikia.com 名下的，網址是： http://shu1tong2wen2.wikia.com/wiki/Shu1Tong2Wen2:Home
有些詞條給出了參考資料，並且與相近的詞條之間做了辨析。例如 attribute 詞條（ http://shu1tong2wen2.wikia.com/wiki/Talk:Attribute ），就討論了該詞與 property 及 character 的異同。
於是，我在想，這種討論術語翻譯的事情，是不是更適合用 Wiki（維基）的形式來做？當然，這些討論形式和你定義的那個範例數據結構之間，可以有映射關係，以便實現同步修改、查詢以及導入/導出等功能。
@jeffreybaoshenlee 这个好，没想到已经有了这么多条目。不过跟我这帖子的大标题稍有不同（但是仍然是我想做的之一）。
你的是一个通用的计算机(?)术语库（近义词辨析链接非常有用，只是不知道维护起来难度如何）。这样的目标我觉得是可以公共编辑、提意见、带注释的，毕竟很多时候是多个候选，可能一词多义。结构不可能完全格式化。 话说我觉得也许支持就地（精简地）讨论甚至投票（不知wikia支不支持写出这么一个插件来）更佳。 （另外好像没看见“不转换”……以及我这老是看见那一大坨联合国鸡精会广告有点烦 （再另我觉得还是要稍微限制一下范围orz生物化学的都来了有点可怕
本帖一开始所述，是想限定一个语言（或者某种编程语言的生态圈），跟（标准库、自制库的）公开标识符一一对应，然后严格格式化，容易被代码编辑器直接拿来用的（直接（可能需要按树状路径）匹配然后替换显示）。 也就是要很严格的定义一个格式和标准，要合作也是少数人协力来做。 同时我是觉得这个格式里面应该还要包含输入法提示（比如中文名的拼音），不能指望各个编辑器去自动把中文转换为拼音。
这两种，虽然看起来核心一样，但是由于范围、广度、目的的区别，我觉得做法的区别还是会挺大。
@farteryhr 嗯，我感覺你要做的可能是一套針對某個語言或某個技術領域的規則體系，大家可以參照這個體系，去處理代碼，叫它們更貼近中文。術語翻譯，只是其中的一部分（當然可能是很重要的一部分）。
我還沒在 wikia.com 下面建立過項目，書同文項目是我偶然發現的，記得上次去看的時候，還有「不轉換」的選項，今天打開找不到了。這幾天我再看看。
（可以考慮在轉換工具裡面，內置討論與投票功能，這其實也就相當於，去操作託管在某個遠程網站上的頁面？如果這樣的話，那麼把這部分數據，乃至整個規則體系，都放在 github ，似乎也是可以的……當然，這是我胡亂想的……）
@htwx 不知你在汉化TS过程中, 有没有形成一个术语词典? 感觉至少也有上千条. 本来想用脚本试着从源码里提取, 不过短期估计没功夫试了.
看到v2ex三年前的帖子越来越觉得码代码时命名是件十分头疼的事，想发起一个项目建立一个命名字典. 再联系到之前的讨论, 考虑从一个web API原型开始做.
虽然术语词典还处于非常初步的阶段(词条很少), 总归需要平台/工具来演示它的用途. 想到的有:
- 类似https://github.com/unbug/codelf 的变量名搜索引擎(我们可以提供中文变量名推荐, 比如输入abstract list就返回"抽象列表"等等)
- IDE插件, 通过调用这个字典达到 @swizl 在https://github.com/program-in-chinese/overview/issues/59#issuecomment-411119728 中提到的效果
- 代码翻译, 详见@swizl 在https://github.com/program-in-chinese/overview/issues/59#issuecomment-411272880
这个API就是用来支撑这些应用的. 返回值的可能格式之一在楼上, 还需要继续改进和细化API设计.
在实现方面, API和源代码都尽量用中文命名, 项目本身和术语词典开源, API开放给第三方应用. 有兴趣参与的童鞋欢迎推荐和探讨架构/部署环境. 如果暂时无人参与, 也许就用自己最方便的做个原型出来再说. 像其他项目一样, 新开库后, 就在那里进行针对性讨论, 而这里最多是对项目的阶段介绍, 当然一般讨论照样继续.