User talk:Lynnboy
将内存序的顺序修改成定序有什么理由吗？虽然确实是通过内存序确定内存的修改顺序，但宽松定序、释放-获取定序、释放-消费定序、序列一致定序等词不需要强调确定，尤其是宽松顺序不确定任何顺序。 此外“在多生产者-多消费者的情形中，若所有消费者都必须以相同顺序观察到所有生产者的动作出现，则可能必须进行序列定序。”等句中，不如将“sequential ordering”翻译为“确定序列的顺序” -- YexuanXiao
术语翻译的一个特征是相对稳定性，采用固定对应词翻译而非日常用语中随表达目的灵活选用近似词。 order 一词本身的含义可以翻译成顺序、次序等，但 memory ordering 作为术语词组的含义，正如你所说，是通过内存序确定内存的修改顺序，其合适的中文翻译正是“内存定序”。至于 relax ordering 的情况，则如同 void 也是类型，null 也是值，“不处理”也是一种处理等情况一样，本就是合理情况。
至于其他语境中出现 ordering 一词，如果确定其并非术语或等同相关术语的含义，则当然可以按普通词语一样处理。
关于复杂度的翻译
请问“Exactly ranges::distance(first, last) applications of the function object f”等类似的复杂度表述的翻译，“精确”或“准确”为什么要改成“恰好”，对于复杂度的表述应该没有什么“恰好”的，况且这个表述会引入歧义。
因为不符合中文语言习惯。“精确”和“准确”不是用来修饰数量的，而是用来修饰行为的。比如： “我走这条路恰好走了30步。”不能说成“我走这条路精确走了30步。”只能说“我走这条路走了30步，（这种说法）是精确/准确的。” “恰好”本来就包含“不多不少”，用在此处没有不恰当。
我觉得，即便在翻译技术文档时，符合语言的表达习惯仍是很重要的。 英文也是表述为“exactly N ...” 而未更文绉绉地说成“precisely N ...”。
你给出的这个理由相当糟糕。
“恰好”适用于不能提前得到结果的情况，例如：“我走这条路恰好走了30步“ ”费马恰好验证了5个数”。 “我走这条路恰好走了30步。” 的前提是“我”在走之前不知道结果，因此用恰好，如果结果是确定的，则不应使用恰好。 而“准确”适用于可以提前得到结果的情况，例如：“这张桌子的宽度准确为2米” “我从家出发走到这里准确走了10分钟”
好吧，你说的有道理。但“恰好”“恰为”并不总是用于表示不可预知的结果，至少在我的日常表达中“XX恰好为YY”本就多用于表达“严格”“精确值”的意思，反而要表现不可预知结果时，才是需要前后语境铺垫的。 我所表示的是符合“语感”的问题。至少在日常表达中，几乎没有人会说“我准确走了五步”，”准确“、”精确“的使用方法在现代汉语中多有以下几种：
- 形容词，“XX很精确”，“准确的描述”
- 副词，“准确（地）划出界限”，“精确（地）与之匹配”等
- 直接修饰代表数量的名词：“精确值”，“准确度”，“精确大小”等
不过反过来说，“我准确（地）走了五步”其实从语法上没有问题，只是真的很少出现这种说话方式。
我认为“恰好”暗指结论精确，不应该用于未经过计算就存在的事实。
例如：“周润发恰好摸到了红中”和“周润发准确摸到了红中”，前者是剧中视角，剧中人不知周润发一定摸到红中，因此使用恰好，而后者是剧外视角，周润发是主角是赌神一定会摸到红中。
因此，标准抛给我们具体的复杂度，不应该使用恰好，而应该使用准确。
此外，我认为不应该在初始化语法中采用“...式”，理由如下：
1. “...器”是主流译法，平白更改为新译法会造成分裂
2. 旧译法经过我调整并无明显歧义
3. 新译法并没有解决旧译法的问题
在cppref中，旧译法经过我调整已经不存在错误及明显歧义：
- 用于初始化的任何花括号包裹的列表 -> 花括号初始化列表
- initializer_list -> initializer_list
- 用于初始化非静态数据成员的项及列表 -> （构造函数）（默认）成员初始化器（列表）
- 复制初始化的右操作数的 -> 初始化器
中文常常用“功能+机器”造词来为实现抽象功能的具体事物命名，
例如：发动机、热水器、永动机、电器、传感器、洗衣机、飞机。
这种用法也延伸到了计算机领域，例如：下载器、模拟器、生成器、阅读器。
恰好“downloader”、“simulator”、“generator”、“reader”都是以“er”或“or”结尾，这并不是偶然。
由于“列表”已经脱离了抽象，因此不需要加“器”，而新译法只是粗暴的在初始化后增加器，对含有“列表”的任何语法来说都是冗余，并不妥当。
关于 initializer 等的翻译，我的想法与你有所不同。 C++ 规范中出现的各类名词主要可以作如下分类：
- “XX式”，这一类主要强调的是它们作为一种语言结构，对编译器可见的信息的整体性。就如“等式”，“方程式”等的含义：expression, initializer, declaration, definition, specialization, initialization - “表达式”，“初始化式”，“声明式”，“定义式”，“特化式”，“实例化式”。这里其实还有一种关键区别，“XX式”强调的是语言构造，尤其是“特化式”，它是特化某个主模板的“声明式”，而给模板标识加上模板实参列表所代表的实体，则称为该模板的“特例”。在 cppref 上，后面几种的翻译我会遵循广为接受的版本。
- “XX符”，这一类主要强调它们作为基本语法单位，而非独立提供完整语义实体。如 identifier, operator, specifier, modifier, qualifier, capture, placeholder, declarator, enumerator - “标识符”，“运算符”，“说明符”，“修饰符”，“限定符”，“俘获符”，“占位符”，“声明符”，“枚举符”。不过将 enumerator 翻译成“枚举项”也是很好的。
- “XX器”，这一类主要强调的是它们在执行时实现的功能逻辑。如：allocator, container, iterator, handler, adaptor, wrapper - “分配器”，“容器”，“迭代器”，“处理器”，“适配器”，“包装器”。
以上解释了我为什么会将 initializer 翻译成“初始化式”。我在网络上搜了一下，'initializer' 的翻译包括“初始化式”，“初始化器”，“初始值设定项”等。某些语言或平台中，initializer 是运行时决定行为的函数或可执行代码，这里把它翻译成“初始化器”甚至“初始化函数”都可以，但 C/C++ 中，initializer 的核心视角其实不是动态行为而是其语法构造，所以我仍觉得“初始化式”比“初始化器”更合适。
至于 initializer list 的翻译，如 int x{0}; 或 vector v{1,2,3}; 中，0, 1, 2, 3 这样的东西是 initializer “初始化式”，而 {0}，{1,2,3} 则是 initializer 所构成的列表“初始化式列表”。这里并非按“（实现）行为（的）列表”，而是“元素（构成的）列表”来构词。若采用“初始化列表”，其含义是这个列表中包含了一组“初始化动作”，而若采用“初始化式列表”，则它只是提供一组用于初始化的值，而初始化动作其实是由“带初始化声明符”完成的。
替换不应改为代换
替换不应改为代换，这种改动没有任何意义，我的观点仍然式广泛使用的翻译如果没有严重的缺陷/歧义，就不需要更改。
此外 @Fruderica 反对使用“初始化式”，理由是“初始化式”可能会被误解为一种表达式，或许你可以找他聊聊。
-- YexuanXiao
你好。
我觉得“替换”和“代换”还是有比较明确的差别的。普通情况下使用“replace”或“substitute”时，确实是日常用语中的“替换”，“取代”的含义，但 C++ 中的函数式宏和模板这两种机制，基本可以等同于数学中的“代入”操作，在概念上最好把它术语化。宏的英文术语采用了“replacement”，这个保留“替换”没问题，但模板的“substitute”最好翻译成“代换”（“代入”也可以）。
关于“初始化式”，我觉得本来语言上就是和“表达式”类似层次的概念，把它当做某种具有内在逻辑的“器”反而是不妥的，请参见上面的讨论。
欢迎和几位进一步讨论。
代换并不比替换更“术语”。此外模仿（使用）其他领域的术语并不总是好的，这可能会造成严重的歧义，例如编程语言中的 function 和数学的 function 有很大差异，因此应该避免这种翻译风格，而不是鼓励它。
-- YexuanXiao
关于container/emplace的修改
https://zh.cppreference.com/mwiki/index.php?title=Template:cpp/container/emplace&diff=82480&oldid=73506 1.这里的value_type是容器的元素类型，我认为不需要翻译 2.关于ars...作为形参包展开语法的模式，应指代形参，而只有在函数调用的语境时指代实参，作为文档参考时没有语境的应直接翻译成参数，而不应该暗示语境。 3.placement new的翻译有定位,布置,布局，放置.这里使用"布置"沿用了cppref的一贯翻译
1. 没有空格的 value type 是普通术语，需要翻译，带下划线且标有等宽字体的 value_type 才不需要翻译。
2. 一般可以谨守 argument-> 实参，parameter-> 形参 的翻译，少数情况下确实翻译为 参数 更好，但很罕见
args...在包索引页面中被叫做形参包，即使它是arguments的缩写。实参一般代表函数调用表达式在括号内的操作数，而形参指的是函数参数列表中的名字。 或许可以调整英文版本的描述以增强一致性。
--YexuanXiao（讨论） 2024年8月27日 (二) 23:32 (PDT)
同意。名为 args... 是给调用方看的函数签名部分，函数内部它就是个形参，英文原文应当改为 parameter pack 或 parameters。
关于具名要求:可就位构造的修改
https://zh.cppreference.com/mwiki/index.php?title=cpp/named_req/EmplaceConstructible&diff=86951&oldid=72886 此处修改完全改变了原意。草案原文为If X is not allocator-aware or is a specialization of basic_string, 此处非知配容器与basic_string 的特化并列。
好吧。可是 allocator-aware 是个形容词。A is not red or is a title bar 还是得翻译成 **A 不是红色的或者是个标题栏** 比较好。
Re：关于初始化器
两位好：
我认为这并不像别的措辞问题一样是哪个更好、更贴切的事，无论在网络上还是现实中我从未见过支持“初始化式”的说法，不仅仅是 C++，也包括 JS 等其他编程语言，本不应存在争议。看到这个地方达不成一致我是很惊讶的，因为直觉上中国大陆简体中文环境成长的中文用户“初始化式”一词甚至不太会在大脑中出现，这是典型的台湾中文。包括您给出的三类名词分类，我的语言直观里同样不存在“‘XX式’强调的是语言构造”这个概念。
您提到的功用与动作的区别我并无异议，我认可这几种区分，但世界上没有两片完全相同的树叶，只是它们之间的差别并不足以让其一不叫树叶。简体中文里，“不是动态行为而是其语法构造”的东西仍然偏好使用“器”，否则这区分将直接指向“函数应该翻译成函式”的典型台式用词了。我唯一能想象出早期翻译中可能出现过且符合简中习惯的另一个用法是“初始化子”，比如数学物理里将 centralizer，normalizer, operator 翻译成中心化子、正规化子、算子。
诚然 initializer 有形态上的意义，但它未必就一定要体现在翻译里，更多还是关注其功用。而且一个 c++ 概念或者实体，标准出于严格表述的需要，可能会给出偏向某些角度的定义，这都不代表相关用词实际指涉的概念关注的是形态本身，（比如 parameter 是声明，argument 是子表达式，但无论是命名还是大家用到它们的时候，其实都在在谈某种实体），它取决于这些概念的定义首先出现在 lex, syntax 还是 runtime 阶段。标准里 initializer 是 lex 阶段定义的，在 tokenize 和此阶段里，甚至逗号都算“实体”，但我们在语法或者文法中谈及 initializer 的大多数时候，逗号还停留在作为词法层面的概念。
大陆中文跟台湾中文的措辞何者更贴切是另一个可以商榷的话题，但 cppref 的中文页面并不是繁体中文，整体表达风格的自洽也很重要，即使认为其他翻译更好也只能说是个人偏好。如果需要尊重港台和马来西亚新加坡用户的习惯（我不清楚这个问题上其他几地用词是怎样的），是否可以让管理员添加其他中文区域子页面？或许可以采用 Wikipedia 的策略，简繁体中文以自动机翻为主，只需人工修正个别表述。
sqsy（讨论） 2025年3月26日 (三) 19:33 (PDT)
经过测试，我发现即使把语言变种偏好设为繁体中文台湾，函数也显示成函數而不是函式，我感觉 cppref 的策略还是不甚妥当。