v5.7
のラベル付けています。もしやりたいものがあればAssigneesにお名前追加してください! https://github.com/stzn/the-swift-programming-language-jp/issues (edited)String
で特定されているので、String
のみを保持することができます。 と訳していますが、今となっては全部「格納」で良いのかなと思ってきました。 当時はなんとなく「メモリに値を格納する」と「データを変数に保持する」みたいな感じで分けていたのかなと(ただ統一性がなく、なぜそうしたのかは1年以上前なので覚えてないです...)。 (edited)stored
が使われてる例だと stored procedure があるなあと思ったけどこれは「ストアドプロシージャ」で定着しててなんも参考にならんかった。struct
も Swift の文脈ではあまり「構造体」と呼ばない気がする。Stored Properties of Constant Structure Instances
のところ、定数の格納インスタンスのプロパティ
と翻訳されていました。 定数の格納インスタンス
は定数に格納されたインスタンス
という意味で通りそうですが、それでもProperty
にかかるStored
が抜け落ちているため、翻訳として適切でないと思います。 methods.mdからこの項目へのリンクがあったので、併せて修正しています。 // this range represents integer values 0, 1, 2, and 3
です。 3が抜けてコードと矛盾していました。
textlint-disable
で無視するようにしました。if let
の同名省略の記述を追加(Swift5.7からなのでコメントアウトしています) 特定の列挙ケースの全てのインスタンス
だと一つの列挙ケースにたくさんインスタンスがあるということになり、それは変じゃないかと思ったのですが、Swiftの列挙体は値型なので、別の変数に代入すればそれは異なるインスタンスになるのでした。ここは元の文に戻しておきます。 suggestion もし列挙型が Raw Value を持つ場合、これらの値は宣言の一部として決定されます。これはつまり、特定の列挙ケースの全てのインスタンスは、必ず同じ Raw Value を持つということです。もう 1 つの選択肢は、列挙ケースに関連値\(Associated Values\)を持たせることです。関連値はインスタンス生成時に決定され、列挙ケースのインスタンスごとに異なる値を持つことができます。関連値は列挙ケースのインスタンスの格納プロパティのように振る舞います。例えば、サーバから日の出時刻と日の入り時刻をリクエストする場合を考えてみてください。サーバはリクエスト情報に応じたレスポンスを返すか、リクエストが間違っている場合は間違っているという内容を返します。
定数、変数、プロパティ、または subscript
のようになっている文章が多く、サブスクリプトにしたほうが読みやすいかと思います。
opaque type
となっていました。 これに対する訳は他の言語コミュニティでも定まっていなさそうで、 一番定着している訳というのもわからなかったです。 他方、データベースの型について調べると 簡単に変わることはないのではと思う例がありました。 IBM と Oracle は自社製品に関するドキュメントの中で 不透明型
という訳を使っています。
不透明型
とするのはどうかなと思っています。value
の訳が 値
ではなく バリュー
となってしまっています。 GitHub の Projects 機能で管理してもいいのではないでしょうか。
value
は文脈による可能性ということですね。 要素
という語も浮かびましたが、適切なのか分かりません…。 とりあえず value
の表記揺れは他の方の意見を待ち、 それ以外の部分をチェックしていきます key-value pair
についてはキーバリューペアでいいと思います。 https://github.com/stzn/the-swift-programming-language-jp/blob/777b7d6f03b85e6de0000d0226c133f2b870d0c2/language-guide/collection-types.md?plain=1#L474 これを根拠として、辞書型ではバリューを使っていくというのでも良いんじゃないでしょうか。value
については バリュー
の訳になるよう気をつけます! 格納
にして問題なさそうなところはそのようにしていきますね。
キーパス
、KeyPath
、key-path
、key path
が混在しています。 原文では型を指す KeyPath
以外では key path
かkey-path
が使われています。 関連して、identity key path
(.self)の翻訳が識別キーパス
となっていますが、識別だと意味が違うような気がします。型が Sendable であることを示すことができます
にしたいがlintで弾かれる。structured concurrency
の翻訳が 構造同時並行性
になっていましたが、構造化された並行性
という翻訳が他言語でも広く使われているようです。 構造同時並行処理
のような形で出てきている箇所もありますが、これらも併せて変更しています。非構造タスク(unstructured task)
を 構造化されていないタスク
にすべきか迷ってとりあえずそのままにしています。 また、原文ではunstructured task
の初出は斜体になっているのですが、翻訳の際にルールはあるのでしょうか?key path
が良いかなと思いますが、いかがでしょうか? self key path
で良いような気がしますねー。いかがでしょうか?構造化されていない〜
という否定形が何度も出てくると読みにくいかなと感じました。 一方、少し上の方でunstructured child task
を独立した子タスク
と翻訳している箇所がありました。 unstructured
の翻訳として 独立した
を使うのが正当なのかはよく分かりませんが、読みやすさだけなら 構造化されていないタスク
より 独立したタスク
のほうが上だと思います。意味的にもずれてはいないと思いますがどうでしょうか。SE-0249 Key Path Expressions as Functions
の話ですが、字幕では全体に KeyPath
ですね。 https://developer.apple.com/videos/play/wwdc2020/10170 型の KeyPath
と混在してしまうという問題がありますが… 自己参照KeyPath
みたいにするより self KeyPath
のほうがシンプルで良さそうですね。unstructured
の翻訳を独立した
に変更しました。 unstructured task
を残してみました。* 正規表現の作成に関する情報を [正規表現リテラル](../language-reference/lexical-structure.md#lexical-structure-regular-expression-literals) セクションに追加しました
* アクターとタスク間のデータ送信に関する情報を [Sendable Types](../language-guide/concurrency.md#sendable-types) セクションに追加しました。また、[@Sendable](../language-reference/attributes.md#sendable) 属性と [@unchecked](../language-reference/attributes.md#unchecked) 属性に関するセクションを追加しました
KeyPath
に統一 identity key path (\.self)
の翻訳として self KeyPath
を導入 subscript syntax
だけ翻訳していたのですが、 @t-ae さんによる先の PR で包括的に解消済み To create an unstructured task that’s not part of the current actor, known more specifically as a detached task,
で、detached task ⊂ unstructured task
という関係が明示されています(翻訳では省略されていますね)。 なので独立したタスク
の中に完全に独立したタスク
があるというのも一理あるかとは思うのですが、読みやすさでは切り離されたタスク
のほうが良いと思います。現在のアクター上で実行されない独立したタスク
となり、独立した
の意味がブレそうなのが気になるのも一因です)access context
と access level context
が出てきて、ここでは access context
です。 使い分けがよく分かりませんが、とりあえず出てくるものに合わせました。but whose conformance to an internal protocol can only be used within the internal protocol’s defining module.
準拠自体のアクセスレベルの話をしているようなので、プロトコルへ準拠した実装は
は違うと思います。 ある型が InternalProtocol
を実装しているとして、外部のモジュールからは InternalProtocol
に準拠していることを認識できないというような意図ではないかと思っています。John Appleseed
人名も翻訳したほうがいいですかね? 例えば「ジョン・アップルシード」に変えたほうがいいでしょうか?4
に変更しました。Customer
クラスのname
プロパティなので、呼称を「さま」にしました。全てのタイプエイリアスは、アクセス制御の目的で別個の型として扱われます。タイプエイリアスは、エイリアスする型のアクセスレベルより制限の厳しいアクセスレベルを設定することができます。例えば、private タイプエイリアスは private、fileprivate、internal、public、または open 型のエイリアスになれますが、public タイプエイリアスは internal、fileprivate、または private 型のエイリアスにはなれません。
[Default Initializers\(デフォルトイニシャライザ\)](../language-guide/initialization.md#default-initializers)で説明されているように、Swift は、全てのプロパティにデフォルト値が提供されていて、かつ 1 つもイニシャライザが定義されていない構造体または基本クラスに、引数なしの_デフォルトイニシャライザ_を自動的に提供します。
少なくとも同じレベル
-> 同じかより高い
-> 同じかより緩い
で同じ気がしてきました… 頭の中で緩厳で認識していたので、少なくとも同じレベル
だと緩厳どちら方向が許されるのか曖昧だなと思ったのですが、高低で考えると分かる箇所ですね。 元に戻します。suggestion 列挙型定義の Raw Value または関連値に使用される型には、少なくとも列挙型のアクセスレベルと同じ高さのアクセスレベルが必要です。例えば、private 型を internal アクセスレベルの列挙型の Raw Value 型として使用することはできません。
https://github.com/stzn/the-swift-programming-language-jp/pull/333#discussion_r939156980 このコメントで元の文を復元したのですが、元の文はレベルが複数回出てきて読みにくい気がします。 アクセスレベル自体が高低を持った概念なので、少なくとも同じレベル
という言い回しより 少なくとも同じ高さ
で良いかと思いました。
name
プロパティで3つも出し分けが必要でした。 Person
のname
プロパティ: 「さん」 Customer
のname
プロパティ:「さま」 HTMLElement
のname
プロパティ:敬称なし The fallback logic to use “World” when name is nil has to be done inline using the ?? operator,
インラインで実行する
だと意味が通らないので 記述する
に変更しました。
suggestion 最終更新日: 2022/8/10
suggestion print("letters は \(letters.count) 個の要素を持つ Set<Character> 型です。")
suggestion print("ただ今 \(customerProvider()) を接客中!")
servingは[飲食物を人]に配るという意味だから、 customersInLine
に合った訳は「接客中」のほうがいいかもしれないan axis
を「ある軸上」と訳すよりは具体的な軸に言及したほうがわかりやすいかなと思いました。swift printAndCount(string: "hello, world") // prints "hello, world" and returns a value of 12 printWithoutCounting(string: "hello, world") // prints "hello, world" but doesn't return a value
https://docs.swift.org/swift-book/LanguageGuide/Functions.html
print
の英文が抜けていたので、翻訳は原文を参照しました。
swift let doubleIndex = findIndex(of: 9.3, in: [3.14159, 0.1, 0.25]) // doubleIndex is an optional Int with no value, because 9.3 isn't in the array
with no value
の情報が現状抜け落ちていたので補いました
xxx演算子
と訳すのが良さそうですね。 候補は下記がありそうですが、どれもググって正式に使われているシーンがちゃんと見つけられないです・・・ print("\(customerProviders.count) 個のクロージャーが保持されています。")
print("空港辞書には \(airports.count) 個のアイテムがあります。")
// 私には 3 個の好きな音楽ジャンルがあります。
// theAceOfSpades: 柄は ♠, 数字は 1 と 11
保持されています
良いと思いますairports
dictionaryを定義して説明していく流れになっています。 本文も 「airports
辞書」と説明しているのでいるので「airports」はそのままにするほうがいいかなと思いました。 var airports: [String: String] = ["YYZ": "Toronto Pearson", "DUB": "Dublin"] `airports` 辞書は、`[String: String]` 型と宣言され、 // 本文もairports辞書で説明 「`String` 型のキーと `String` 型のバリューの `Dictionary`」を意味します。
https://github.com/stzn/the-swift-programming-language-jp/pull/342/files/0cf86c48e96ae9a73398642791d8be0228efafbf#...
airports
dictionaryを一度定義してそれを使って説明する流れになっています。 https://github.com/stzn/the-swift-programming-language-jp/blob/0cf86c48e96ae9a73398642791d8be0228efafbf/language-guide/collection-types.md?plain=1#L481 なので、 「the airports dictionary.」は上の定義を指しているので「airports」は削らないほうがいいかなと思いました。 また、今までの訳では「airport/空港 辞書」で説明したところがいきなり「辞書」だけになると読者も同じものを指しているかが分かりくくなるかなと思いました。airports
のままで大丈夫です!suggestion print("予期せぬ自動販売機とは関係ないエラーが発生: \(error)")
suggestion print("(\(x), \(y)) は x == -y の線上にあります")
suggestion 上記の例では、`approximateCount` が `switch` 文で評価されています。それぞれのケースでは、1 つの数値または範囲で比較しています。`approximateCount` の値は、12 から 100 の間にあるので、`naturalCount` には `"数多くある"` という値が代入されます。実行後は `switch` 文から抜け出します。
suggestion print("(\(x), \(y)) は x == y の線上にあります")
〜である〜
と書きたい所を〜な〜
と書いている箇所が散見されます。 textlint-rule-no-mix-dearu-desumasuのREADMEによると、オプションでstrict: false
と設定することで文中の〜である〜
が弾かれなくなるようです。 問題なさそうならこの設定に変えても良いのではないでしょうか。これらの要件を定義するために、`Container` プロトコルは、コンテナが保持する要素の型を参照する必要がありますが、特定のコンテナでその型が何なのかを知る必要はありません。`Container` プロトコルは、`append(_:)` メソッドに渡される値の型、およびサブスクリプトによって返される値の型とコンテナの要素の型を一致することを要求します。