-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
术语表讨论确定 #2
Comments
贴一下 原术语约定。 |
关于 effect 原来的 wiki 里有一个地方要改:effect flush timing 要从副作用刷新时机改为 effect 刷新时机(不过其实这一条感觉不需要在 wiki 里单列出来了)。 |
同意对自然存在的 |
认同,我删掉了 |
我觉得 effect 作为 Vue 中特定的概念就统一不翻译了,不仅仅针对“effect scope”。Side effect 里面的 effect 不是这个概念,就翻译成“副作用”。 |
所以我们针对 effect 有一个结论么? 我个人是觉得 effect 作为一个基本单词,出现的频率很高,我个人在翻译的时候秉持的原则是 “除非一个词确实是很难翻译,且概念非常特殊” 我才会保留原词,尽量不让中文文档中老是出现英文词汇。 另外,这个词结合上下文语境 采用恰当的中文词汇 翻译,往往能更符合中文语言习惯。 cc @yyx990803 可否看完后也给些意见?( 😅 这次翻译量比较大,大家需要很多时间才可以完整看完) |
如果简化一下说法,我们是不是可以认为特指 Vue 里的 Effect Scope API 的时候不翻译,其它场景都翻译成“作用” Ref:https://v3.vuejs.org/api/effect-scope.html
截至目前还有别的特定概念吗? @Justineo |
有的,Vue 本身就有 |
哦,发现了。Effect Scope API 确实范围说得有点太小了。 你觉得可以重新归纳为 Reactivity API 范围内吗?还是索性理解为“Vue 中的相关特定概念” |
就是VCA里的概念吧 |
这里我想先确认一点保证我的理解和大家没有偏差 ... effect 作为 Composition API 的特定概念是不是就是在表示 "(依赖变更、引发响应式变化所带来的)(副)作用" 呢?还是其他的什么概念 ... (因为我自己在翻译的时候是这么认为的,如果有误,可能在相应章节有较大调整。) 我感觉在原文中很多地方 effect 和 side effect 表达的意思区别不大呀😂;这二者的具体区别是什么?如果有必要说明的区别可能也需要在翻译中体现。 为了使讨论有效果,我也认同 effect 是特定概念,可以不翻译。 但每当有这种情况,对入门读者来说,很难让他们直接像 redis 一样将一个英语单词对应一个概念。所以我是希望我们能先在文档中说明这个特定概念究竟是什么。 |
在 深入响应性原理 原文,定义 “a few terms” 的时候有这样一句:
所以我在那之后大多数情况下都把 effect 认为是 side effect 的 short hand 如果是将 原文这一段 “定义了一些术语” 作为概念的介绍,那么引入 effect 这个英语单词是合理的。但我又考虑到这一章节是进阶阅读,且位置偏靠后,所以一般都是用了 “副作用” 这一译法 |
理论上 VOA 里想用这些 API 也可以,我个人是把 Reactivity API 和 VOA/VCA 分开看的 |
好问题,我个人理解 effect 这个词是从函数式编程里的概念来的。另外 side effect 有一个比较主流的中文翻译了叫“副作用”,相比于“main effect” (似乎没有特别的中文译法与之对应),指各种除了返回值以外执行函数对外界产生的影响。其余部分我也是一知半解。 回到 Vue 的 effect 相关概念和 API,我个人感觉这里从 tech design 的角度,大家并不介意这个 effect 是 main effect 还是 side effect,总之是个抽象的 effect。比如 我可以再试着找一些周围对 FP 比较熟的同学加入讨论。 谢谢 |
我注意到现翻译许多 caveats 被翻译为了”约定“,根据先前达成的共识,建议修改为”注意事项“。见 vuejs/docs-next-zh-cn#793 |
同意。我看这个术语表里也有,应该不存在什么问题 |
在 |
或者参考C的引用/解引用? |
@zhangenming 个人理解,此处的语境与 C 的引用有些不同,wrap\unwrap的操作对象都是基础类型,是将一个基础类型包装成引用类型(object);这个概念与 JavaScript中的包装对象几乎是一致的。vue 作为JavaScript 的框架,我认为还是参考已有《JavaScript 高级程序设计》中的翻译更合适一点儿。 |
同意。
之前中文文档讨论的结论是:包裹/解包,见 vuejs/docs-next-zh-cn#487 |
我看了之前的讨论,虽然当时给定了一个翻译,但是当时的讨论中并没有列举出太多相关的已发布的翻译参考 我找到了《JavaScript 高级程序设计》的英文原版《Professional Javascript for Web Developers》,其中对原始值包装对象的描述如下: 在上述例子中 wrapper 被译为 包装对象 且其提到的包装对象与本文档的 Reactive Variables with ref() 中所描述的思想有异曲同工之妙。(仅个人理解的相似)
再者,鉴于《JavaScript 高级程序设计》译本的流行程度,绝大部分前端开发者都或多或少的阅读过此书,所以我认为参考书中的译法有助于开发者理解本文档。 综上所述,我依旧提议将 wrap/unwrap 译为 包装/解包 |
unwrap 本身译法也是解包,我相信这个大家比较容易达成共识。 guide 译为指南我觉得没问题 BTW,这个帖子我倾向于针对后续每个新的词的译法讨论单独开贴,因为讨论总量有点过长了。我个人建议我们把以下词汇讨论清楚之后整理到 wiki 然后关闭该 issue:
谢谢 |
|
近一段时间,我由于身体原因没有太多参与讨论。 |
@ShenQingchuan 嗨,感谢你的翻译,请多多保重身体嗷! |
@Justineo 嗨,我完全同意你说的 wrapper 与 ref 有很大区别。我来说一下上文中我没有完全说明的相似之处是什么吧。请允许我先用“包装”来描述相关内容,你可以将其看做是“包裹”: 先聊聊原始值和其包装对象吧。我简要概括了一下《JavaScript 高级编程》中的内容,JavaScript 为了让 原始值具有一些基础的方法和属性,选择在访问其方法和属性时创建一个相应的包装对象,从而暴露出操作各种方法和属性。当然包装对象与正常对象也是有区别哒:
而关于 reactive() 与 ref(),首先说明我并没有完整地阅读过 Vue 的源码,并不清楚 reactive() 与 ref() 的内部实现 ,以下的一些理解仅来自于文档内容以及个人有限的 JavaScript 知识,可能有错误,敬请斧正,感谢! 我们先来看看 reactive() 局限性的第一点吧:
在这里我们想一下为什么 reactive() 对 接下来我们来看看可以解决上边这个局限性的 ref():
从上边的内容中,我们可以知道 终上所述,我完全同意 @Justineo 所说的不同,我将其总结如下:
但这些不同对 wrap 有什么影响吗?我个人认为是没有的,这两者之间诚然有非常多的不同,目的、结果等等都不相同,但它们的过程都是一致的,都是 将一个原始值转变为一个对象,而 wrap 不正是用来描述这个过程的吗? 而这也是我前面所提到的我个人理解的思想层面的相似:
最后,回到关于 wrap 的翻译,翻译为“包装”或者“包裹”都能表达其含义,但如果你能同意我前面所说的这种相似性,那我认为“包装”可能更合适,阅读过《JavaScript 高级程序设计》的同学可能从中更快地理解这个过程。 |
JS本身就有包装对象的概念吧 |
Hi 诸位,不介意的话我另外开一个 wrap/unwrap 的译法讨论好了,看上去其它的译法讨论都已经有结论了,这个术语讨论的 issue 我就先关掉了。🙏 |
这个 issue 帖用于讨论确定本文档中的术语表。
在翻译团队审阅完目前的全部文档内容后,这个置顶帖会统计和罗列最终确定的结果。
任何疑问、意见或建议都可以通过在此 issue 下方跟帖来提出。
最终敲定表
这里汇总的是本 issue 帖中的意见归纳,可能和现有已确定的术语表有重合。
The text was updated successfully, but these errors were encountered: