留言板

  • 🤓 有任何疑问和建议都可以在这里讨论!
  • ✌️去注册个账号以接收更新通知和评论留言;
  • 😎 帮忙宣传哟~~~

 

《留言板》上有321条评论

  1. Swift指南->方法->类型方法->Player类->第5行和第6行: LevelTracker.unlockLevel(level + 1)
    tracker.advanceToLevel(level + 1)
    有误,应该为
    LevelTracker.unlock(level + 1)
    tracker.advance(to: level + 1)

    参考苹果官方文档代码

  2. 站长你好,我是一个程序员,在使用swift的过程中,看到你的网站,我觉得这个网站做的很不错,真的帮助到了很多人,真心感谢你和其他辛苦付出的人。
    但是使用的过程中,对照英文原版,发现很多中文翻译还不到位,我正好比较有空闲,也想加入翻译的队伍,贡献一点力量,希望能够让更多人受益。
    期盼你的回复 ?

  3. “Enumerations in Swift are first-class types in their own right.”

    Excerpt From: Apple Inc. “The Swift Programming Language (Swift 4.1).” iBooks.

    Swift 中的枚举是具有自己权限的一类类型。// 这个翻译偏了

    Enumerations(枚举)是Swift 类型系统中的头等类型

  4. 章节3.4 可变形式参数

    原文定义函数:
    func arithmeticMean(numbers: Double…) -> Double {
    var total: Double = 0
    for number in numbers {
    total += number
    }
    return total / Double(numbers.count)
    }

    可变形式参数“numbers”没有使用省略实际参数标签,函数默认“numbers”作为实际参数标签,下面调用“arithmeticMean(1, 2, 3, 4, 5)”会因为标签缺失引发错误“Missing argument label ‘numbers:’ in call”,应改为:“arithmeticMean(numbers:1, 2, 3, 4, 5)”,或者定义函数时候使用省略实际参数标签:“func arithmeticMean(_ numbers: Double…) -> Double”

  5. 勘误

    「Swift指南」 > 「字符串和字符」 > 「字符串字面量」一节中,

    字符串字面量是被双引号包裹的固定顺序文本字符(”)。

    兴许应为

    字符串字面量是被双引号(”)包裹的固定顺序文本字符。

    原文:
    A string literal is a sequence of characters surrounded by double quotation marks (“).
    The Swift Programming Language (Swift 4.0.3) > Language Guide > Strings and Characters > String Literals
    https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/StringsAndCharacters.html

  6. 感谢博主!

    唯一的一个缺点就是服务器有点慢,不介意的话我可以免费提供国内的阿里云服务器!

    有意的话可以发邮箱:-=安全起见已隐藏=-

    1. 对的,实际上是应该叫 构造器 和 析构器,但不这么用的原因有两个:1、我个人至今不理解为什么这么翻译,构造我能懂,可是析构到底是个什么鬼?? 沿用 Java 不是 C,Swift 不是 Java;2、苹果方面也不希望你这么叫,为啥捏?因为构造器用的名字是 Constructor , 而这里苹果用的词汇是 initializer ,这样一来你就明白它们之间的不同了。

      实际上对于构造器和初始化器的叫法,在编程上都有(Java 里也有人叫构造器为初始化器)……说的好像跑题了,总之,就是为了对应初始化器,我把这个 deinit,翻译为了“反初始化器”,认为它是“ deinitializer” 的缩写。


      1. 解释:劈开木头。
        会意:右边的斧头(斤)劈左边的木头。
        用法:析薪、分析、解析。
        参考文献:『說文解字』。

    1. 我 想给一笔钱给站长。可是,你这个站却要求我使用支付宝。出于隐私权的保护,我是不会安装这个东西的。我只用微信。你却没有微信的账号。
      总的说来,似乎站长早已收下了支付宝的垄断费,好像不再需要其他钱了吧?说笑的。不过从这个角度来看,站长并不懂把握这个领域的商机。这种机遇不是你懂技术就可以把握的,关键是商业意识。
      这个网站可以做得很丰富的。但现在似乎就是一套苹果的Swift的手册的中文翻译本。
      1.可以将教程和教师指南结合起来 (苹果官方的培训课程)。
      2. 在此基础上可以将1提及的教程和教师指南进一步细化。比如说字符串这个章节里的名词解释有些马虎和过分专业,对初学者来说,尤其是没有接触过编程的人来说就一头雾水,还有就是练习和检查方面做得可以更细更多的。
      3. 也应该把Xcode的拉进来翻译。实际上swift是在xcode上建立起来的所见所得化的工具。必定有很多不完善的地方。
      4. 这是最后一点,请从新写过留言系统。其实网上有的是照搬的模块。

  7. 文中initializers多次被翻译为初始化器,是不是应该叫初始化方法。感觉初始化器听起来像一个新概念,但本质上并不是。

  8. 目前在留言板中讨论”however”问题的人有三四个人,只有你一人坚持“总之”。由此可见,“总之”给70%以上的人带来了阅读理解障碍,而非你个人认为的“更适合新手”。

    再看另一个例子,就是“便捷初始化器”那段讨论。我看了下原文,就想知道你们谁更有理一点,这一看不得了。为了了解上下文,Automatic Initializer Inheritance 节标题开始看。

    首先映入眼帘的是 “Automatic Initializer Inheritance” 被翻译成了 “自动初始化器的继承”,即是 “自动+初始化器+的+继承”。

    Automatic 是形容词,语法规则上是“形容词+的+名词”,“漂亮的人”、“自动化的电梯”,“的”字可省略,而且进一步可省略为“自动电梯”。
    Automatic 应是“自动化”,暂不再深入省略用法,先看接下来的。

    Initializer 这是一个名词无疑,有编程经验的人应知道,它这里是指类中的初始化方法,即“Initialization method”,原文没用“Initialization method”可能是出于区别其他语言考虑,因为其他语言一般类中定义的函数才叫方法,而事实上,Swfit中类、结构体、枚举里均可定义函数,都叫做方法(method),参考“Methods”章节开篇说明。既然原文没用“Initialization method”,而用“Initializer”,所以你翻译为“初始化器”也无可厚非,因为已经存在“初始化器”这种译法。不过在实践中,“初始化器”更多的是指程序员采用工厂模式等编程设计模式编写的一种控制程序,让多个对象可以被集中管理初始化过程的程序。

    Inheritance 是名词,我们知道它肯定是和“Initializer”结合的,因为常识告诉我们“自动化”这个形容词是不可能有继承关系的。而且在语法上 “名词+名词”是一种固定组合,叫做复合名词,所以“Initializer Inheritance”是一个整体。但在翻译 Inheritance 的时候又出现了问题,因为中文的“继承”是动词,而英文的“Inheritance”是名词。两种语言的词性差异你没有仔细琢磨。有个方法,那就是把中文的动词变成名词,词性就一致了。先把“继承”用“继承规则”代替,“规则”是名词,为何选择“规则”来补全这个词?因为此文语境就是在讲述规则如何。

    “名词+名词”结构中的“的”字,有些情况可加可不加,有些情况必加,有些情况不能加,也需要分清楚。例如“儿子的父亲”,可以加,表示一个主体“父亲”;“儿子父亲”,也可不加,表示联合并列;“爸爸的爸爸”,必须加,如果改成“爸爸爸爸”就意义全变;还如“妻子女儿”,不能加,若改成“妻子的女儿”,又变了,英文中也类似“Moon River”,“月亮河”,不可是“月亮的河”。

    那“Initializer Inheritance”这个复合名词的完整翻译就出来了“初始化方法的继承规则”。从上段“名词+名词”的语法分析中可知,两名词中间加“的”字一定会改变原意,至少表述的侧重点都会发生变化。该节内容讲述的主体就是继承规则而不是初始化方法,所以这个“的”字需要加上。类比例子就是“电梯的运行规则”。

    此标题语法结构应该是“形容词+复合名词”,形容词和名词之间的“的”字可加可不加,我们先加上看看“Automatic Initializer Inheritance”的完整翻译“自动化的初始化方法的继承规则”,相比“自动初始化器的继承”哪个一目了然无需多言。再看如何简化完整版,先看类比的例子“自动化的电梯的运行规则”,句子结构与词的词性完全一致,通常情况下大家会怎么简述这句话?“自动电梯的运行规则”,“规则”一词不可少,否则对上下文不敏感的读者会脑补“运行过程、运行状态、运行结果”等意义不同的结果,而且也讲过要把“继承”变为名词,所以“规则”一词更不可少。更进一步简化“自动电梯运行规则”,运用到我们的节标题上,“自动初始化方法继承规则”,“自动初始化器继承规则”尚可。

    所以,就“Automatic Initializer Inheritance”分析了那么多,就为了说明一件事,翻译的遣词造句要“信达雅”并不容易,要结合专业术语、专业知识背景。也许在你看来最终结果改善不大,但是,有句话叫“失之毫厘谬以千里”,假设你的误差只有3毫厘,但传播给别人后,放大三倍就会成为9毫厘的误差,与真实差距是9;如果你能竭尽所能控制误差在1毫厘,那别人放大3倍是3,与真实差距是3。

    传播知识的严谨性一定要时刻牢记于心,翻译“信达雅”,可信第一、通达明白第二、简明优雅第三。

    可能由于你的编程实践经验不丰富,而导致了你在你的能力范围内可做到的误差已经是3,那么,在有外人帮助你的情况下,我们可以一起改进的,成长的,也是你自己。

    如何看出你的编程实践经验不丰富呢?比如“两段式初始化”这个翻译,很明显是通用英语思维带来的翻译结果。“Two-Phase”在既有计算机术语中,全都称为“二阶段”,如分布式事务处理中的“二阶段提交”,如并发控制中的“二阶段锁”。还有“In practice, this means that you do not need to write initializer…”这句中的“In practice”。

    “Two-Phase”为何要“二阶段”而不是“二段式”?因为“阶段”,能体现出一前一后或一上一下的逻辑关系,能给人脑海里这种直观感觉,还能感觉出这两个阶段的处理应该有所差异,如果无差异,何不合并在一起?而“二段式”就给不了人这种感觉,就仅仅是“两段”,它既能表达有先后顺序的两个阶段,也可以表达没先后顺序的两个并列阶段,就让菜鸟有了50%的误会可能性。

    “In practice” 如果是我,会翻译成“实践中,”而不会翻译成“实际上”,“事实上”更不可取。在通用英语思维中认为这三者并无差异,因为词典上就是这么写的。但结合到语境,就有不同了。“事实上,”给人的感觉是要开始给人讲一个根本性的道理。“实际上,”给人的感觉也差不多是要开始讲道理或者是表达某种现象。“实践中,”就直接明了的告诉读者,在实际践行所授知识的过程之中可以怎么做。

    “实践中,这意味着你不必…”,阅读速度快的程序员在看到这些字眼后,不论大脑如何将这几个词打散后再组织,意义都不会有偏差。“这意味着你在实践中不必……”, “这意味着你在实际上不必……”,结合编程这种身体力行的活儿来讲,“实践中”怎么都比“实际上”更应景。

    姑且说这些吧。说了这么多,“便捷初始化器”还没提,也不想多提了,你在用电脑的时候应该看过“快捷方式”这个深入人心的词,而没看过“便捷方式”吧?

    此翻译确实有用心,但由于诸多原因导致的质量改进空间还很大。年轻人有自己的主见和看法是好的,但你太有些以自我为中心,生活中你有自信乃至自大的一面。要学会承认山外有山人外有人,这个世界上没有个人英雄主义(牛顿、爱因斯坦、咸蛋超人都是踩在前辈和同仁的肩膀上)。多经历就好了,谁都年轻过。

          1. 只要能帮到帮助的人,这就足够了,何必在意某些“高手”。每次有基础点忘记了,我不是打开官网,而是直接在你们网站看,这就是你们的作用。对于那些说什么“蹩脚”翻译,你能力那么强怎么不做点无私的事情?

      1. “在有外人帮助你的情况下,我们可以一起改进的,成长的,也是你自己。”

        ——摘录自上文留言。

        另说:
        传播知识,虽然你是免费的,但也应当以严谨而审慎的态度。宁可不说,也不可误说。不可误人子弟的责任感亦当时刻背负。但人无完人,没有最完美,只有更优秀。当大家都在帮助你的时候,你应经过自己的理性思维,选择性地改进。而不应如此年轻气盛,负气而为,这是对他人的不尊重也是对自己已经付出的心血的糟蹋。
        如此,才可能将此站发展成为受业界认可,受新人信任的 Swift 语言中文社区的中坚力量之一。若能如此,是你的荣誉,也是我们的光荣。

        1. 感谢站长的付出。根据留言上下文,我觉得@阿驹 的批评据事而论,判断有据,站长对他的批评,应该给予重视,而不是“负气而为”。

        2. 我觉得阿驹说的很中肯,批评的也非常优秀;但我认为阿驹忽略了一个事实:就是在目前的国内,还没有一个完整的 Swift 4 的中文翻译网站或者电子文档(如果有,还请正误)——除本站之外。
          在这种情况下,最需要的是,有人来做,先出一个版本再说。
          这个版本的质量的高低其实并不那么重要,最重要的是:有这么一个翻译版本了,大家能来看,然后勘误,提出修改意见,然后改进。
          如果第一个版本才出来,就求全责备,大加批评,可能对于最初的热心是很浇了一盆冷水的。
          说一句难听的话,阿驹先生也没见翻译一个版本出来。
          我丝毫不否认阿驹先生论述的合理性,但是,对一个新生儿需要的是严厉的批评(即便是正确无比的)还是细心的呵护,我想答案是显而易见的。
          站主几乎是一个人搞起来这样一个不小的工程,不简单。现在需要的是针对一些明显错误的勘误,不需要许多文字来说道理,说一下错误在哪里,或者哪里跟官网的不一致,站主看到了及时正误或者调为一致,这就挺好。
          另外有一部分人要求把“栗子”改为“例子”,其实也大可不必。如果想要改,就是一个查找和替换的事——这样写,除了好玩就是活泼一点(意思的理解上,应该是完全没有任何歧义的)。
          总之,有这样一个完整的翻译版本了,我们一定要呵护,并且使它少错误,同官网一致;大加批评,甚至说站主年少气盛什么的,真不需要(人家一个年轻人,做成了这么一件事,盛也有盛的资本)。后面 Swift 修改少了,稳定了,再来着手调节一些名词的译法,也没什么。

    1. 在我看来本站是更新比较及时的了,翻译质量也不错,再说站长又不是专业学英语的,有点偏差也是可以理解的,又不是去出书。
      照你的标准国人大部分的翻译都是不合格的,既然你这么专业那么好不如你都翻译翻译??

    2. 你的指正很细致,而且的确有理有据。

      人之患在好为人师

      知识水平高,并不代表可以站在高位指导他人,用探讨和推荐的语气说这些话,站长也许早就接受了你的指正

  9. Swift 4 的”协议”中的”类专用的协议”部分已经更新了:

    You can limit protocol adoption to class types (and not structures or enumerations) by adding the AnyObject protocol to a protocol’s inheritance list.

    protocol SomeClassOnlyProtocol: AnyObject, SomeInheritedProtocol {
    // class-only protocol definition goes here
    }

    即类的专用协议需要使用 AnyObject 关键字, 译文中还写的是使用 class 关键字. 示例代码也更新了.

    参考链接:
    https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Protocols.html#//apple_ref/doc/uid/TP40014097-CH25-ID267

  10. 关于”Argument Labels”和”Parameter Names”的翻译.
    把他们翻译成”实际参数”和”形式参数”好像不太合适吧, 实际参数应该是调用方法时传入的参数.

    我觉得把它们直译成”参数提示标签(或内容提要标签)”和”参数名”更好一些.

    1. 这个是国际公认的软件开发方面的专业名词,我也没办法。argument 就是 实际参数,而 parameter 就是 形式参数,也就是我们常说的实参和形参。在开源版本里以前就是统一翻译为 参数,现在也都改正了。
      我比较讨厌实参和形参的说法,所以我就写全了,叫 实际参数 和 形式参数。

        1. 并不会,如果说简写,那就直接形参实参最好了,但这是一种古老的叫法,会给新手带来不可想象的困惑。至于是标签还是名称,实际上都是参数名,翻译为标签并不合适。
          另外就是技术名词不应该自己创造,也好考虑到后来人和其他技术人员沟通时候的通用性,不应该随意增减创造(实在没标准翻译的也没办法,但这个是公认的哈。

  11. “Swift 指南->初始化”中:
    当满足规则2的一部分时,子类的便捷初始化器可以实现父类指定初始化器。

    原文:
    A subclass can implement a superclass designated initializer as a subclass convenience initializer as part of satisfying rule 2.

    as part of satisfying rule 2 应该翻译为: “作为满足规则二的一种情况”, 而不是”当满足规则2的一部分时”.

    1. 子类能够以便捷初始化器的形式实现父类指定初始化器来作为满足规则2的一部分。

      这个不是满足规则2的一种情况,而就是一部分,实际上我好像也没这么用过,总之,我重新翻译了一下,这下和原文文风一致(绕口+没有标点符号短句),这句应该是我校对时候丢了。另外我还统一了本文中便捷初始化器和便利初始化器的冲突问题。

  12. 我发现 However 基本上都翻译成了 “总之”, 有的地方已经偏离原意很远了, 比如:

    “Swift 指南->可选链” 中:
    john.residence 的值当前包含合法的 Residence 实例。总之, john.residence.address 的值目前为 nil 。

    原文:
    The value of john.residence currently contains a valid Residence instance. However, the value of john.residence.address is currently nil.

    这个地方是一个很明显的转折了, 肯定得翻译成”然而”的.

    1. 要不翻译为更旧的通用翻译「无论如何」怎样?这句里 john.residence.address是空的,原文中并明有解释,因为原因很明显,所以就「总而言之」了一下,我觉得是很合理的。你也可以理解为转折,但我理解的是递进。1、这是合法的;2、这个是空的;3、它是 nil。
      文中重点要描述这个nil,所以说了一个 however,是一个结束论点的句式,不愿在「为什么是空」这个问题上多做纠结。

  13. “Swift 指南->可选链” 中的第一句话:
    可选链是在可能递归为 nil 的可选项中查询和调用属性、方法和下标的过程。

    原文是:
    Optional chaining is a process for querying and calling properties, methods, and subscripts on an optional that might currently be nil.

    是不是把 currently 误翻译成了”递归”?

  14. Swift指南->属性:
    “总之,属性也可以与类型本身相关联” 的原文是 “However, properties can also be associated with the type itself”, 需要把”总之”改为”然而”.

    1. however 也可译做 「总之」。 在上下文中,取「然而」并不符合原文意思,这里并没有转折的意思,我们常说「这个怎么怎么样,然而,它也怎么怎么。」但这里显然是一个进一步的说明「can also」是说「也能」。所以,我认为这里是一个进一步的总结,意思是 「总之,这个属性也可以与类型本身去关联。」是一个补充和说明,并无转折的意思。

      1. Stored and computed properties are usually associated with instances of a particular type. However, properties can also be associated with the type itself.

        翻译一: 存储属性和计算属性通常和特定类型的实例相关联。总之,属性也可以与类型本身相关联。
        翻译二: 存储属性和计算属性通常和特定类型的实例相关联。然而,属性也可以与类型本身相关联。

        我觉得还是翻译二比较符合原意. “总之”是对前面表述的总结, 但这里不是对前面的总结, 而是在阐述另一种情况.

          1. “Swift 指南->可选链”中:
            你可以通过连接多个可选链来在模型中深入访问属性、方法以及下标。总之,多层可选链不会给返回的值添加多层的可选性。

            原文:
            You can link together multiple levels of optional chaining to drill down to properties, methods, and subscripts deeper within a model. However, multiple levels of optional chaining do not add more levels of optionality to the returned value.

            这个地方的 However 翻译成 “总之” 好像意思就不太符合原意了. However 后面有较明显的转折的意思.

          2. 总之,是总而言之,但如果是总结,我们尝试一下「你可以通过连接多个可选链来在模型中深入访问属性、方法以及下标。但是,多层可选链不会给返回的值添加多层的可选性。」这是严重的转折语气,但前后似乎并没有这么严重的转折,「你可以通过连接多个可选链来在模型中深入访问属性、方法以及下标。另外,多层可选链不会给返回的值添加多层的可选性。」这是严重的递进语气,这两个其实都不是很合适。这句上下文本身就没有一个很明确的关系,并不是上文有「会」,下文出现「不会」就一定是转折,这里是一个进一步的说明。是说你可以链接多层……,可返回的不是多层。这里如果用但是,语句上更通顺,但是,这样就不是中文的用法,我认为用「总之」,比一个烂大街的「然而」要好很多。用「然而」取前肯定后否定的意思,是可以的。我用「总之」则是说后边的内容是前边内容的一个递进。——合并来讲,可以说是「无论你链接多少层可选,返回的总是一个」这样的意思,而不是「你可以链接很多层但是返回的只有一个」。意思是一样的,但描述的方式是不一样的。所以我觉得这里这个连接,用什么都可以,去掉也行,为了保持文风,我才留下的。我始终觉得从小学就教的把 however 翻译为「然而」是一个很�的选项。

          3. 支持“然而”或“但是”,这里的“However”是表转折。奶人(姑且这么称呼)应该承认自己在翻译中的“印随效应”,你一开始接触“However”这个单词,不管是你的启蒙老师还是谁告诉你的,它的意思就是“总之”,这个“总之”深深地印在了你的脑海,所以才会出现大家评论的“However几乎全翻成了‘总之’”。

            我们不妨先用类比法来看原文中的“However”如何翻译较好:
            结婚通常是一个男人和一个女人关联在一起,However,一个男人也可以和另一个男人在一起。(明显用‘总之’是不恰当的)

            我们再用抽象法来看:
            A和B在一般情况下和C关联,However,A/B 也可以与D本身关联。(大多数情况下按前半句做,少数情况下也可以按后半句做。)

            说来说去,however,本身就是一个转折性的词语。不论翻译成“然而、总之、总而言之、话说回来、但是……”

            最后一个例子:
            去公司上班通常是周一至周五,总之,周末也可能去公司上班。
            去公司上班通常是周一至周五,然而,周末也可能去公司上班。
            去公司上班通常是周一至周五,但是,周末也可能去公司上班。

            不论如何,我是不支持“总之”的。

          4. 和你说的恰好相反,我的启蒙老师——都统一翻译为“无论如何”,从我小学开始到大学,没有任何变化,请原谅我不是天资聪颖没有读一个英语专业,总之,我在这里还是坚持把它翻译为总之,并且没有对原文造成任何内容上的混淆。我不是专业翻译,不再和你们争论,我坚持我认为正确的东西,这样翻译更有助于新手阅读,也更符合我所理解的原文的意思,毕竟话又说回来,中文里很难简单的用两个字来表现英文中的 somehow,however,whatever 之类的词,毕竟是语言不同的。

  15. 类型转换
    case let stringConverter as String -> String:
    print(stringConverter(“Michael”))
    中的第一个String应该加上()变为
    case let stringConverter as (String) -> String:
    print(stringConverter(“Michael”))

  16. /”使用断言和先决条件不能代替你代码中小概率非法情况的处理设计。总之,使用他们来强制数据和状态正确会让你的 app 在有非法状态时终止的更可预料,并帮助你更好的 debug。在检测到异常状态时尽可能快地停止执行同样能够泥减小由于异常状态造成的损失。/”

    最后一句话,同样能够泥减小?

  17. 控制流:
    与 C 不同,Swift 允许多个 switch 情况来判断相同的这。事实上,坐标 (0,0) 可能匹配这个栗子中所有四个情况,第一个匹配到的情况会被使用。坐标 (0,0) 将会最先匹配 case(0,0) ,所以接下来的所有再匹配到的情况讲被忽略。

    第一句和最后一句有误,烦请修正,谢谢!

  18. 大大们,“ Swift 同样也为三个主要的集合类型提供了更牛逼的版本, Array” 一个严谨的翻译,不应该出现“更牛逼”这样的俗语吧~~~

  19. 楼主你好,在学习 Swift 4 的时候搜到了你的网站,之前看到过 SwfitGG 也做过翻译的工作,不过就像你说的,你这里是第一时间紧跟官方的预览文档,所以也让我有了第一时间学习到中文版新知识的机会,英文文档我也能看,只不过我看起来太慢了,所以感觉还是看母语的文档能快速学习。另外看到这里的中文版有一些小伙伴参与了翻译,所以我也想参与进来,不知道楼主对参与翻译有哪些要求,如果能满足这些具体要求,我也很愿意参与进来。

  20. 相反,传给 someFunctionWithNonescapingClosure(_:) 的闭包是非逃逸闭包,也就是说它可以引式地引用 self
    更正:
    相反,传给 someFunctionWithNonescapingClosure(_:) 的闭包是非逃逸闭包,也就是说它可以隐式地引用 self

  21. 书写错误
    位置:方法-在实例方法中修改值类型
    错误:mutating func moveByX(deltaX: Double, y deltaY: Double)
    正确:mutating func moveBy(x deltaX: Double, y deltaY: Double)

  22. 闭包那一节:
    “在 Swift 中,一个能够捕获值的闭包最简单的模型是内嵌函数,即被书写在另一个函数的内部。一个内嵌函数能够捕获外部函数的实际参数并且能够捕获任何在外部函数的内部定义了的常理与变量。”
    倒数第四个字是错别字,应该是:“常量与变量”

  23. 建议和疑问:

    为何不用 GitHub 开源,然后用 GitHub Pages 轻松建站?
    这样别人可以很方便地提交PR和issue。
    而且很多程序员都在用GitHub,也便于宣传和搜索到。

    或者,像[The swift programming language 3.0 中文版](https://www.gitbook.com/book/znoodl/swift/details)一样用GitBook。不过,我没发现参与贡献的方法,所以不太推荐。

    1. 因为我不会用那个,当时最熟悉这个,顺手就搭建了,而且是我自己翻译和校对(后来才有朋友参与进来),所以并不想那样做。现在我维护不过来了,但遗憾的是我没时间把它迁移过去。

      1. 你没有时间,就只能等你有时间了。这没啥好说的……
        不过,github早晚要学的吧……
        你可以慢慢来。先在github上发点别的简单东西试水。

      1. 我能理解你的意思。
        但我认为这里原文并不是强调“把代码转换成自然语言来阅读”。
        这两行代码是高度符号化的(只有两个关键词”let”和“var”,且“let”跟常量字面上完全不沾边,只是出于别的考虑才选择了它吧),“转换成自然语言”是非常牵强的。
        而且,一般程序员阅读代码也不应该转换成自然语言,这不是好习惯,不应提倡或暗示新手。

        阅读由两步组成:第一步是你阅读了代码`let maximumNumberOfLoginAttempts = 10`,识别出里面的结构、词法和值;而第二步是理解其含义和效果。
        在英文里,一个”read”兼顾了两者。而”read as”更侧重后者,而且往往是需要深入思考或体会的。
        我给的链接(有道词典)的例子(比如”All western films can be read as a series of codes and the variations on those codes.”)无疑也都是侧重后者。
        中文的“读作”则更侧重表面(发音和简单的词语变换),而并不太侧重理解。
        当“读作”和“理解为”两个翻译候选都不足以覆盖原文”read as”的内涵的情况下,我认为还是选择后者,相对更好一些。

        1. read as 可以被翻译为“读作”“理解为”“看作”“解读”等等,在数学上,课本中经常会有某些定义公式,说xxxx(某公式),可以被读作xxxx(中文的解释),而不是“理解为xxxx(中文的解释)”。
          比如这一段:

          蕴涵词”→”也是个二元命题联结词。将两个命题P、Q联结起来, 构成一个新的命题P→Q, 读作如果P则Q, 或读作P蕴涵Q, 如果P那么Q, 其中P称前件(前项、条件), Q称后件(后项、结论)。

          这里只是解释了字面的意思,并不带有主观上要求读者把它理解为什么。“新的命题P→Q, 读作如果P则Q”而不是“新的命题P→Q, 可以理解为如果P则Q”,本章或者本翻译中大量类似的内容,也应该是具体代码的人类语言中立解释,应该是“读作”,而不是很主观的“可以被理解为”,每个人的理解都是不同的,而读作,是必须的、固定的、官方的。

          参考链接:
          http://202.197.191.206:8080/29/text/chapter01/section2/part5/r1.htm
          http://blog.wenxuecity.com/blog/frontend.php?act=articlePrint&blogId=15490&date=200702&postId=21673
          http://cn.linguee.com/中文-英语/search?source=auto&query=read+as

  24. 错误处理的指定清理操作的第2句,

    “这个语句允许你做任何无论执行如何离开当前代码块都必须要做的清理工作——无论是因为抛出了错误还是因为 return或者 break这样的语句。”

    “任何无论执行如何离开当前代码块” -》“如何离开当前代码块”更通俗易懂

  25. 函数 — 多形式参数的函数 — 报错
    func greet(person: String, alreadyGreeted: Bool) -> String {
    if alreadyGreeted {
    return greetAgain(person: person)
    } else {
    return greet(person: person) //此处会报错,提示少了 alreadyGreeted: Bool 这个参数
    }
    }
    print(greet(person: “Tim”, alreadyGreeted: true))
    // Prints “Hello again, Tim!”

    1. return greet(person: person) 这里的 greet(person:)是上文中的一个函数,本例中声明的函数类型是greet(person:alreadyGreeted:)

      正如下文所述:“注意这个函数与之前展示的函数 greet(person:) 是明显不同的。尽管两个函数都叫做 greet , greet(person:alreadyGreeted:) 接收两个实际参数但 greet(person:) 函数只接收一个。”

  26. 自动引用计数-闭包的循环强引用,第6行代码,lazy var asHTML: Void -> String = {,官网已更新为:lazy var asHTML: () -> String = {

  27. 你好,枚举的隐式指定的原始值这节中,
    let earthsOrder = Planet.Earth.rawValue
    // earthsOrder is 3

    let sunsetDirection = CompassPoint.west.rawValue
    // sunsetDirection is “west”

    rowValue不支持这种用法了?
    xcode8 求帮助,谢谢

  28. 刚开始学习。
    在https://www.cnswift.org/a-swift-tour 这页上面的函数和闭包这一章:

    ……使用 _ 来避免使用实际参数标签。
    func greet(_ person: String, on day: String) -> String {
    ……
    greet(“John”, on: “Wednesday”)
    ……

    on day: String =>这个是我漏掉了什么吗?
    因为按这节上面那个例子,看起来应该是on : String,
    或者 两行一起改为day : String呢?
    func greet(_ person: String, day : String) -> String {
    ……
    greet(“John”, day: “Wednesday”)
    ……

  29. func hasAnyMatches(list: [Int], condition: (Int) -> Bool) -> Bool {
    for item in list {
    if condition(item) {
    return true
    }
    }
    return false
    }
    func lessThanTen(number: Int) -> Bool {
    return number 10 后仍旧显示true,想请教一下这是什么原因,未入门的新手求指导,非常感谢。

  30. 延迟存储属性那一节最后部分“只有在 importer 属性第一次被访问时才会创建DataManager实例”有误,应当是创建DataImporter实例才对吧。

          1. 在 Swift 指南 – 字符串和字符 里面:
            ” Swift 的 String类型桥接到了基础库中的 NSString类。如同 AnyObject(此处应有链接)中描述的那样 ”
            链接不可点.

  31. 最近学swift,主要看官方的文档,用这里的中文版做辅助。发现有些章节还没有翻译,正好最近有时间,想帮忙做些事情。

  32. 概览-错误处理 中译文第一句话有误:
    译文:
    你可以用任何遵循 ErrorType 协议的类型来表示错误。
    原文:
    You represent errors using any type that adopts the Error protocol.

  33. 概览-枚举和结构体漏掉了一段内容:

    If an enumeration has raw values, those values are determined as part of the declaration, which means every instance of a particular enumeration case always has the same raw value. Another choice for enumeration cases is to have values associated with the case—these values are determined when you make the instance, and they can be different for each instance of an enumeration case. You can think of the associated values as behaving like stored properties of the enumeration case instance. For example, consider the case of requesting the sunrise and sunset times from a server. The server either responds with the requested information, or it responds with a description of what went wrong.

    enum ServerResponse {
    case result(String, String)
    case failure(String)
    }

    let success = ServerResponse.result(“6:00 am”, “8:09 pm”)
    let failure = ServerResponse.failure(“Out of cheese.”)

    switch success {
    case let .result(sunrise, sunset):
    print(“Sunrise is at \(sunrise) and sunset is at \(sunset).”)
    case let .failure(message):
    print(“Failure… \(message)”)
    }

    Add a third case to ServerResponse and to the switch.

    Notice how the sunrise and sunset times are extracted from the ServerResponse value as part of matching the value against the switch cases.

    1. 补充:
      我在译文中找到了这段内容,看起来只是译文的顺序有点问题,上面指出的那段内容应该放在“枚举”之后,“结构体”之前。

  34. 在 概览-枚举与结构体 里面,有翻译漏掉了部分信息:
    译文:
    添加一个 color()方法到 Suit,方法返回“black”
    原文是:
    Add a color() method to Suit that returns “black” for spades and clubs, and returns “red” for hearts and diamonds.

  35. 在类和结构体这一章中的类是引用类型中举的例子中:使用let 创建某个常量,后来又给此常量修改值,是不是错误了,应该声明为var变量

      1. 引用类型的值对其修改其实改的是其内容而不是引用本身,这里我们说的“引用”其实就是这个对象的指针啦。
        结构体啊数组啊这些不能改,是因为它们是值拷贝类型,他们的内容就是他们的值。

  36. 控制流中while square < finalSquare {
    // roll the dice
    if ++diceRoll == 7 { diceRoll = 1 }
    // move by the rolled amount
    square += diceRoll
    if square < board.count {
    // if we're still on the board, move up or down for a snake or a ladder
    square += board[square]
    }

    官方文档为:
    while square < finalSquare {
    // roll the dice
    diceRoll += 1
    if diceRoll == 7 { diceRoll = 1 }
    // move by the rolled amount
    square += diceRoll
    if square < board.count {
    // if we're still on the board, move up or down for a snake or a ladder
    square += board[square]
    }

  37. 控制流中 游戏棋盘用 Int 值的数组来表现。它的大小基于一个叫做 finalSquare 的常量,它被用来初始化数组同样用来检测稍后的胜利条件。棋盘使用 26 个零 Int 值初始化,而不是 25 个(从 0 到 25 ):

    let finalSquare = 25
    var board = [Int](count: finalSquare + 1, repeatedValue: 0)

    变量board错了,官网上是var board = [Int](repeating: 0, count: finalSquare + 1)

  38. 在 控制流 -> fallthrough 中, 『fallthrough 关键字不会为switch情况检查贯穿入情况的条件。』 -> 『fallthrough 关键字不会检查它下一个将要落入的 case 中的匹配条件』??

  39. 在 集合类型 -> 访问和修改数组 中,『除非当 count为 (就是说数组为空),否则最大的合法索引永远都是 count – 1,因为数组的索引从零开始』,应该为 『count 为 0』。

  40. 在 集合类型 -> 数据类型缩写语法 中,『尽管两种格式功能上相同,我们更推荐缩写并且全书涉及到数组类型的时候都会使用简写』 中 『简写』是不是应该为 『缩写』?

  41. 在 字符串和字符 -> UTF-8 表示法 中,『 print(“\(codeUnit) “, appendNewline: false) 』应该为 『print(“\(codeUnit) “, terminator: “”)』。

  42. 在 字符串和字符 -> 前缀和后缀相等性 中,『如同字符串和字符相等性一节所描述的那样, hasPrefix(_:)和 hasSuffix(_:)方法执对字符串当中的每一个扩展字形集群之间进行了一个逐字符的规范化相等比较』 中 『执对字符串』是不是应该为『执行对字符串』?

  43. 在 字符串和字符 -> 前缀和后缀相等性 中,『要检查一个字符串是否拥有特定的自出福安前缀或者后缀』,是不是多了 『自出福安』?

  44. 在 基本运算符->混合逻辑运算 中,『如果我们输入了正确的密码并通过了视网膜扫描,或者如果我们有合法的钥匙或者我们知道紧急超驰密码,就允许进入』中,『紧急超驰密码』应该改为『紧急强制密码』。

  45. 在 基本运算符->逻辑非运算符 中,『在这个栗子当中,要注意布尔量的的常量和变量名能够帮助你保持代码的可读和简洁』,应该将『布尔量的的常量』改为『布尔量的常量』

  46. 在 基本运算符->合并空置运算符 中,『下边的栗子使用了合并空值运算符来在默认颜色名和可选的用户定义颜色明之间做选择』,这句话中『用户定义颜色明』应该改为『用户定义颜色名』。

  47. 有个地方看了原文文档,感觉有点不太对劲,大神们仔细看一看吧
    初始化部分最后那个棋盘的地方,那个程序是不是有点不对劲,我把实例最后的一个row和coumn写成7和7,返回出来的是true。
    我的想法是,两个for循环做的一个事情是将8×8的棋盘拉成了一条64个格子的首位相连的长条然后依次赋予false和true,但是实际的棋盘的情况则是,(7,0)和(0,1)两个格子是一样的,但是在64个格子的长条中则是相反的。
    不知道我表达清楚没有。。。。
    望大神给回复

        1. 嗯我查看了官方文档,确实是一致的,这个没有办法了。我们翻译的目标是与官方完全一致,至于好不好理解这个……原则上不能随意更改,不然就不叫翻译啦!

          我想,既然你已经能够对它有自己的看法,那这一章你一定已经掌握的很好了:)继续你的旅程吧~

  48. hello,版主
    我是一个3年移动开发经验的开发者,最近赋闲,想要为Swift的翻译做出一份贡献。
    我的邮箱是k9629@qq.com。
    希望可以获得这次机会。

  49. 可选项绑定中你可以在同一个 if 语句中包含多可选项绑定,使用 where 分句来检查布尔量条件:
    if let firstNumber = Int(“4”), secondNumber = Int(“42”) where firstNumber < secondNumber {
    print("\(firstNumber) < \(secondNumber)")
    }
    // prints "4 < 42"

    这个是错误的吧? 官方文档上是
    if let firstNumber = Int("4"), let secondNumber = Int("42"), firstNumber < secondNumber && secondNumber < 100 {
    print("\(firstNumber) < \(secondNumber) < 100")
    }
    这样的

  50. 能不能在更新文档时,把从1.0到2.0到3.0-xxx的更新之处写出来,这样后人在看文档时能知道之前是怎么写的,在后面开发中更好的适配。

  51. 1. 概览里面的《泛型》好像还没更新到swift3.0吧?
    译文:
    func anyCommonElements (lhs: T, _ rhs: U) -> Bool

    swift3.0:
    func anyCommonElements(_ lhs: T, _ rhs: U) -> Bool
    where T.Iterator.Element: Equatable, T.Iterator.Element == U.Iterator.Element

    2. 泛型下面的 EXPERIMENT 的翻译也有点不妥
    译文:
    修改 anyCommonElements(_:_:)函数来让一个返回任何有两个相同顺序元素的数组。

    原文:
    Modify the anyCommonElements(_:_:) function to make a function that returns an array of the elements that any two sequences have in common.

    个人建议:
    修改 anyCommonElements(_:_:)函数,使之返回任意两个Sequence的公共元素组成的数组。

    1. 确实,这里当时更新的时候好像有点问题,已经更正了。最后一句话也更新了——不知道什么时候悄悄改的。 那个实验的内容确实有点奇怪,已经改正为“两个数组中共有元素”。
      感谢反馈!

  52. 有错字,反初始化那一节的‘deinit{}’代码后面一段话写的‘…你不能自行调用反初始化器。父类的反初始化器可以被自雷继承’

  53. 「Swift 概览」的「函数和闭包」中,「在闭包中使用 in来分隔参数和返回类型。」的翻译不正确。原文是「Use in to separate the arguments and return type from the body.」,应该翻译为「在闭包中使用 in来把参数以及返回类型和函数体分隔开。」

    1. separate from 这是一个词组,用来说明是“分开、区别”的意思,这里是 separate from body,这里body显然指代的是闭包函数体,翻译为中文则是 闭包(函数体),这里闭包即指代闭包函数体本身。

      关于 arguments ,这里是旧翻译,应该翻译为 实际参数 ,那么比较本地化的翻译就是 “在闭包中使用 in 来分隔实际参数和返回类型。” 如果非要说严肃一点,那就是“在闭包(函数体)中使用 in 来分隔实际参数和返回类型。”

      已更正。

  54. 枚举那一节的代码 func evaluate(expression: ArithmeticExpression) -> Int { 有问题
    应该是 func evaluate(_ expression: ArithmeticExpression) -> Int {

  55. 在“属性”-“全局变量和局部变量”一节,第一段的第二句翻译为:
    全局变量是定义在任何函数、方法、闭包或者类型环境当中的变量。局部变量是定义在函数、方法或者闭包环境中的变量。
    原文:
    Global variables are variables that are defined outside of any function, method, closure, or type context. Local variables are variables that are defined within a function, method, or closure context.
    个人建议这里翻译为:
    全局变量是定义在任何函数、方法、闭包或者类型之外的变量。局部变量是定义在函数、方法或者闭包内部的变量。
    因为有个outside和within,都译成“环境中”,阅读起来有一定的理解难度。

  56. 函数那个位置:
    ————————————————————————
    func greet(person: String, day: String) -> String {
    return “Hello \(person), today is \(day).”
    }
    greet(person: “Bob”, day: “Tuesday”)
    ————————————————————————
    调用函数的时候有 person: 么?
    Xcode报错

  57. 在“集合类型”–> “数组”–>“使用默认值创建数组”中,方法不对,在 Swift3.0中已经更改为:public func repeatElement(_ element: T, count n: Int) -> Repeated;所以对于示例应该改为:var threeDoubles = Array(repeatElement(0.0, count: 3));同时显示的结果为[0, 0, 0]

      1. 但是这个方法在 Xcode8 beta 版本确实是无法找到的,不知道为什么?能调到的方法var threeDoubles = Array(repeatElement(0.0, count: 3));只有这个,而且实现的效果是一样的!

  58. 闭包“简写的实际参数名”中。这里s1和s2并不占内存,所以省略的应该是“形式参数”而不是“实际参数”。但是看了一下原文,原文用的是argument,搜索了一下,形参是parameter,实参是argument。大概是原文本身就自相矛盾吧?

    1. 这里确实用哪个都行,对外是形式参数,但对内这个确实是实际参数的名字……这么说的话其实也算对。如果都说成参数就没有歧义了。——不我过还是遵照原文的意思,把两个参数区分了哈。

  59. 请问一下,在基本运算符一章的浮点数取余计算里,我用 Swift3.0也就是 Xcode8的版本去写,发现不能直接那样写会报错的!报错信息:% is unavailable:Use truncatingRemainder instead。
    所以想问一下是什么情况?

  60. 闭包一章,非逃逸闭包,
    func someFunctionWithNonescapingClosure(closure: @noescape () -> Void) {
    closure()
    } 目前这样书写报错,正确写法:
    func someFunctionWithNonescapingClosure(@noescape closure: () -> Void) {
    closure()
    }

  61. 在这个栗子中,初始化过程从一个子类的便捷初始化器开始。这个便利初始化器还不能修改任何属性。它委托给了同一类里的指定初始化器。

    栗子。。。

    1. 例子就是上文的插图,初始化过程从子类的便捷初始化开始,然后它调用了自己的指定初始化器,指定初始化器又调用了父类的指定初始化器~这个示例不是代码哈,原文也是这么写的,我也觉得改成“图示”之类的会好些。

  62. 所有类的存储属性——包括从它的父类继承的任何属性——必须在初始化期间分配一个初始值。
    这句话应该写清楚,初始值包含可选值?

    1. 要求赋值,如果你规定这个属性为可选类型,那它就会在没有赋值的情况下自动赋值为nil,这和初始化需要赋值没有任何冲突——所有的属性在初始化的时候都必须赋值。

  63. 概览/错误处理中 let printerResponse = try sendToPrinter(“Bi Sheng”) 应改为 let printerResponse = try send(job: 1040, toPrinter: “Bi Sheng”)

  64. 你好,非常感谢你们翻译的这么及时。想问下,有PDF版可以下载吗,因为边看边做笔记有助于记忆。看网页我有时候找不到阅读过的印象。非常感谢。

    1. 很遗憾,如你所见——现在 Swift 编程语言 还没有全部翻译完成,PDF等格式电子书一定会有——只不过会在全部翻译完成之后才会提供,至少在基础部分翻译完成之后吧:)
      所以还要稍微等一等咯~

  65. “在用浮点数初始化一个新的整数类型的时候,数值会被删减。也就是说 4.75 会变成 4 , -3.9 会变为 -3 。” 这里“删减”用截断可能会更合适。

  66.   “Swift 语言中逻辑运算符 && 和 || 是左相关的,这意味着多个逻辑运算符组合的表达式会首先计算最左边的子表达式。”
      这句话有点歧义,会误以为 && 和 || 具有相同的优先级。最好改为:
      “……这意味着多个 ‘相同的’ 逻辑运算符组合的表达式会首先计算最左边的子表达式。”

    1. :) 感谢你的建议,苹果官方 Swift 3 原文就是这样的呢……另外,在 Swift 中,它们同优先级的,确实是“多个逻辑运算符组合的表达式会首先计算最左边的子表达式”,它的意义就是“多个相同或者不同的逻辑运算符”,这一点可能是和其他语言不同的地方。另外据我经验,手册全文应该也没有提到逻辑运算符的优先级问题,如果有,欢迎你再来斧正。

      1. if true || false && false
        {
        print(“&& 具有比 || 更高的优先级,因此右边的逻辑运算符首先计算。”)
        }
        else
        {
        print(“|| 和 && 具有相同优先级,因此按从左到右的顺序计算。”)
        }

        结果是 true。
        实际计算过程是 true || (false && false)。原文有误。另外,辛苦了。

    1. 嗯,这是一个比较尴尬的问题……简单来讲就是PDF等格式的电子书会比较晚才能出来,因为:一、要等整个文档全部翻译完成;二、全部翻译结束之后,还要进行一遍精翻来处理那些比较生硬的段落。在这之后,才会进行处理生成好看方便的PDF、epub、mobi等格式电子书:)

  67. 前几天打开时,无法连接服务器,以为你们不做了……

    原来在更新3.0,非常真诚的感谢你们,你们做的有意义的事情,也将影响/改变我们使用这个语言做有意义的事情!

    再次感谢,并加油,并支持~

    1. 首先感谢你的留言,好感动!
      但我还是要认真地承认错误,前几天网站挂掉的时候其实 3.0 就已经完成了的……只不过后台数据库更新导致不太兼容所以网站都挂了。持续时间大概断断续续 10 个小时之多,我们深感抱歉 XD。不过,现在问题已经解决了,现在网站速度更加迅速:)
      (其实我一度以为是服务器遭到了攻击,还好不是呐)

    1. 很抱歉由于我的疏忽在个别页面的翻译上出现了错误,我把迄今为止所有翻译了的页面都进行了检索,一共找出了接近10处错误,现在应该不会再有“整形”出现了。关于“栗子”的问题我一直坚持这是个风格问题——但实际上可能真的是“栗子”和“例子”交替出现的,暂时我不会去修改因为还没有想好。我想将来翻译完成了如果集结成书,则可能会为了严谨而改为“例子”,不过在此之前,我们还是多举几颗栗子来放松心情吧:)
      Swift 编程语言与其他翻译不同的地方之一就是“快速响应”,总之,感谢你的提醒呢,希望这个网站的内容能在你的学习之路上祝你一臂之力!祝学的开心,读得愉快。
      另:如果有其他问题,还请继续留言哦~
      十奶。

  68. 来自单表达式闭的隐式返回

    单表达式闭包能够通过从它们的声明中删掉 return 关键字来隐式返回它们单个表达式的结果,前面的栗子可以写作:

    reversed = named.sort({s1, s2, in s1 > s2})
    1

    这里, sort(_:) 方法的第二个实际参数的函数类型已经明确必须通过闭包返回一个 Bool 值。因为闭包的结构包涵返回 Bool 值的单一表达式 (s1 > s2),因此没有歧义,并且 return 关键字能够被省略。

    标注:reversed = named.sort({s1, s2, in s1 > s2})多写了个逗号,导致报错,应该是reversed = named.sort({s1, s2 in s1 > s2}) ,希望你们能改掉

发表回复