Guild icon
swift-developers-japan
コミュニティ / swift-doc-jp
The Swift Programming Language(日本語版) サイト: https://swiftlangjp.com/ Github: https://github.com/stzn/the-swift-programming-language-jp
Avatar
jollyjoester 5/31/2022 8:47 AM
わいわい!
👏🏻 3
Avatar
わいわい
👍 1
Avatar
jollyjoester 6/1/2022 1:59 AM
作っていただいたのにすぐ動けなくてごめんですが、ちょっとわたわたしているので土日あたりにNext Actionしますね〜
Avatar
ありがとうございます🙇🏻‍♂️ ひとまずの共有ですが、swift.orgへのリンクの件はこちらで話しています。 https://forums.swift.org/t/the-swift-programming-language-japanese-translation/57715
Hello, everyone. We decided to maintain this TSPL Japanese translation in Japanese Swift developer community. Here is the deployed site Here is the Github repo We would be glad if it’s linked to Translations. What should we do for it? Thanks!
👍 1
Avatar
@shiz Chinese, Korean, Spanish はアルファベット順に並んでいるのかもですね。 https://github.com/apple/swift-org-website/pull/71/files
Add TSPL Japanese translation Related forum thread: https://forums.swift.org/t/the-swift-programming-language-japanese-translation/57715 Motivation: We decided to maintain this TSPL Japanese transl...
👀 1
2:20 AM
コミット履歴を遡ってみましたが、その三つの言語はまとめて初回コミットされていて、アルファベット順を意図しているのかはわかりませんでした。今後言語が増えることを考えるとアルファベット順の方が探しやすそうには思います。
👍🏻 1
Avatar
Avatar
koher
@shiz Chinese, Korean, Spanish はアルファベット順に並んでいるのかもですね。 https://github.com/apple/swift-org-website/pull/71/files
ありがとうございますmm一旦コメントで聞いてみてます。 (edited)
🙂 1
👍 1
Avatar
@koher やはりアルファベット順だったので修正してApproveしてもらいました。もうちょっと様子みて、今日中にマージ予定のようです🙂 ありがとうございました🙇🏻‍♂️
🙏 1
Avatar
Wow, that’s very very subarashii!
ってコメントあってほっこりした
t_wakaru 7
Avatar
マージされました🙌🏻 https://www.swift.org/documentation/#translations (edited)
Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.
👏 16
Avatar
jollyjoester 6/1/2022 11:32 AM
はやい!🙌
Avatar
jollyjoester 6/1/2022 1:16 PM
公開するまでも何か作戦がいるだろと思っていましたが動いたら一瞬でしたね〜
1:16 PM
次はメンテを盛り上げてくのをやっていきましょう👍
1:17 PM
Swift愛好会Slackで宣伝しといた
🙂 1
🙌 1
Avatar
ひとまず、今後やっていくことや進め方、その他気をつけたいことなどをまとめました。(一部CONTRIBUTIONの内容と被ってますが) 不明な点などはお気軽にこちらのチャンネルに書いていただけますと🙇🏻‍♂️ - ドキュメントの更新のタイミング
  • 公式ドキュメントの更新のタイミングでこちらのドキュメントの更新作業も開始します。Appleから更新のお知らせはないと思われます。去年の経験から考えるとWWDC22後にSwift5.7 Beta版に更新されるはずです。
- 変更箇所の特定
  • 記載のない箇所も変更されていることが多々あるので、変更箇所を探します。Appleの人にうまい見つけ方がないかを聞きましたが、最新のePubをダウンロードして過去のePubとの差分を見てみる、という回答でした。以前calibreというツールを使って試してみましたが、画像の差し替えなどがあるとバイナリの差分が出てしまいあまり活用できず、結局は地道に探しました。何かうまい方法をご存知の方がいれば教えていただいきたいですmm
  • Document Revision Historyにしたがってissueを立てたいと思います。各ページ内の見出し単位に分かれています。
できそうなissueのAssigneesのリストに自身の名前を追加します。最初にこれを行うことで作業の重複が起きないようにしたいです。
  • こちらで必要なissueは用意する予定ですが、上記に記載のように、地道に探す必要もあるため、抜け漏れが発生することが多いにあり得ます。なので、もしissueにない変更に気づいた場合は新しくissueを立ててください。issueを立てたからといって自身で必ず修正する、ということはありません。
  • 一度issueを受け持ったとしても、きつそうでしたら外れていただいて大丈夫です。途中まで行っていた場合は、きりの良いところまで行っていただき、issueにどこまでやったのかを記載して、PRを出してください。issueは開いたままにしておき、続きを他の方が行っていきます。
- 修正方法
  • 元のリポジトリをforkして作業してください。
  • 修正後は元のリポジトリのmasterブランチに対してPRを出してください。
  • PRへのコメントはどなたでも可能です。みんなでより良いものにしていけたら良いなと思っています。
  • マージ権限については特定の人に限らせていただきます。基本的にreviewは1日以内に開始する予定ですが、もし反応がない場合はdiscordやPRのコメントでreviewerにメンションをお願いします。
- その他
  • 当たり前の話ですが、他の方への誹謗中傷はしないでください。もし気になることがありましたら、discordやtwitterのDMで僕宛までメッセージをください
  • サイト自身に対するリクエストなどに関してもissueを立ててください。僕自身、webサイトに関する知識も経験も全然足りていませんので、改善方法の提案やPRをいただけるととても嬉しいです。
  • 無理はしないでください。ベストエフォートでみんなで分担していけたら良いなあと思ってます。
(edited)
👍 4
🙌 4
Avatar
ちなみにSwift5.7は今ぱっと思いつくだけでも変更がすごいたくさんあるなあと感じています😅
Avatar
jollyjoester 6/6/2022 1:31 AM
やるぞ🔥
💪 2
Avatar
>去年の経験から考えるとWWDC22後にSwift5.7 Beta版に更新されるはずです。 と思ったら早速Swift5.7に更新されていたので、まずissue作っていきます https://docs.swift.org/swift-book/RevisionHistory/RevisionHistory.html (edited)
t_kihyouzumi 1
Avatar
issue作成しました。v5.7のラベル付けています。もしやりたいものがあればAssigneesにお名前追加してください! https://github.com/stzn/the-swift-programming-language-jp/issues (edited)
🙌 1
Avatar
2つのissueに対するPR作成してみました。もしお時間あれば見てみてください🙏🏻 (※PRを出してもこちらに投稿していただかなくて大丈夫です。) https://github.com/stzn/the-swift-programming-language-jp/pull/254 https://github.com/stzn/the-swift-programming-language-jp/pull/256 (edited)
👍 1
Avatar
WWDCも終わったので、修正した箇所は順次マージしていきます。もしご指摘などがあればこちらのチャンネルやgithubのissueでお知らせください🙂 (edited)
Avatar
README.mdにご協力いただいた皆様の一覧をGithub APIを使って出そうと思っているのですが、こういうのって、個々に掲載OKかどうかの確認した方が良いでしょうか?? 使おうとしているGithub action https://github.com/marketplace/actions/contribute-list PR https://github.com/stzn/the-swift-programming-language-jp/pull/259/files (edited)
Avatar
jollyjoester 6/13/2022 5:19 AM
活動自体はGitHub上ですでにPublicになっているので「掲載させていただきました!(困ることがあったら教えてください)」というスタンスでいい気がします〜
t_naruhodo 1
t_kansha 1
Avatar
jollyjoester 6/13/2022 7:52 AM
ちょっと落ち着いたのでissue一通り拝見しました! 少しずつやっていき💪
t_kansha 1
🙇🏻‍♂️ 1
Avatar
Avatar
shiz
README.mdにご協力いただいた皆様の一覧をGithub APIを使って出そうと思っているのですが、こういうのって、個々に掲載OKかどうかの確認した方が良いでしょうか?? 使おうとしているGithub action https://github.com/marketplace/actions/contribute-list PR https://github.com/stzn/the-swift-programming-language-jp/pull/259/files (edited)
出してみましたー -> Webページでの表示がおかしいですねw修正します。 https://github.com/stzn/the-swift-programming-language-jp#contributors (edited)
👏 1
Avatar
自動生成されるhtmlのtableタグをうまく読み取れていなかったようです。なので出力方法変えました😅 https://github.com/stzn/the-swift-programming-language-jp#貢献者 https://www.swiftlangjp.com/#貢献者 (edited)
🙌 1
Avatar
↑前の形式に戻してみました。何か変なところありましたら教えていただけますと🙏🏻 (edited)
Avatar
こういった形で改善PRをいただけると大変うれしいので、もし何か気がついたことがあればほんのちょっとで全然大丈夫ですのでお気軽にお願いします🙏🏻 https://github.com/stzn/the-swift-programming-language-jp/pull/291 (edited)
Closes #271 読みやすさと理解しやすさの向上を目指した変更です。 なるべく前提から読めるように、いつくか文の構成を変えています。 文が同じ語尾で繰り返し終わると単調になりやすいので、これについてもいくつか変更を試みました。 また、文のリズムを乱さないよう読点の数も減らしています。
Avatar
ご相談です。 PRを出していただいた際にこのチャンネルに通知を送りたいと考えているのですが、いかがでしょうか? 僕だけだと主観的になってしまうため、余裕があれば他の方にもPRを見ていただきたいなあと思ってます。
👍 1
Avatar
クオリティが担保できるかはあんまり自信がないですが、あいてたら見てみますね
🙇🏻‍♂️ 1
Avatar
ありがとうございます🙇🏻‍♂️ 一応方法は見つけていて、もしOKなら僕の方でやってみようかと思っていたのですが、どうでしょうか? https://mekurun.com/tips/discord-github/
この記事では、DiscordのWebhookを使ってGitHubリポジトリのコミットやプルリクエストの通知をDiscordチャンネルに自動で送信する方法をご紹介します。
👍 1
Avatar
良いと思います!権限足りなければ教えてください
👍🏻 1
Avatar
同じことを指す別々の言い回しを統一。 また、文脈から明らかな冗長表現を避けるべく文の構成を変更した。 Closes #298 よろしくお願いします 🙇
Avatar
ドキュメント内で使われる用語に関して 翻訳時の表記揺れ抑制を目指す為の 英和対応表を追加した。 よろしくお願いします 🙇
t_kansha 1
Avatar
ご相談です🙇🏻‍♂️ 何かご意見などいただけたら嬉しいですmm 「store」という単語の訳をどうするかに悩んでおります。 現状だと「stored property」という単語に関しては「格納プロパティ」としているのですが、 他の箇所に関しては「格納する」と「保持する」が混同しています(僕が混同させました…) ここをどうにかしたいのですが、「格納」か「保持」のどちらかに統一した方が良いでしょうか?それともこの2つは意味が異なるため使い分けが必要でしょうか? もしくはもっと適した訳があればぜひぜひ教えてください🙇🏻‍♂️
Avatar
stored propertyはcomputed propertyと対なので、それはそれで解りやすい方が良さそう。日本語だと格納プロパティ<->計算プロパティで十分解りやすそうです
2:03 AM
一方で、storeに「保持」のニュアンスがあるかはちょっとわからないです。文例があると助かるかも。個人的に、保持を意味する語はretainで出てくるんじゃないか?と思っているが
t_naruhodo 1
Avatar
ありがとうございますmm 例えば、
Like C, Swift uses variables to store and refer to values by an identifying name.
を C 言語のように、Swift は、名前を特定して値を保持したり、その値を参照するために変数を使います。
Because this particular array has specified a value type of String, it’s allowed to store String values only.
を この配列は値の型が String で特定されているので、String のみを保持することができます。 と訳していますが、今となっては全部「格納」で良いのかなと思ってきました。 当時はなんとなく「メモリに値を格納する」と「データを変数に保持する」みたいな感じで分けていたのかなと(ただ統一性がなく、なぜそうしたのかは1年以上前なので覚えてないです...)。
(edited)
Avatar
「メモリに値を格納する」と「データを変数に保持する」みたいな感じで分けていたのかな
この気持もわかりますが、僕もどちらのケースも「格納」で良いように思いました。 stored property を格納プロパティと訳すなら stored property に(転じて変数にも)格納するのは自然ですし。
(edited)
Avatar
Kishikawa Katsumi 7/15/2022 5:29 AM
stored propertyやcomputed propertyは決まった用語なので統一している方がいいですが、それ以外の通常の文章に使われる単語は無理に統一しようとせずにそのときその時で自然に訳すのがいいのではないでしょうか。
5:30 AM
毎回迷って困る、みたいなことがあるなら指針程度のものはあるといいと思います。
Avatar
元の文脈としてstoreがretainを兼ねて使われていそうなら保持は良いのかなと思いました。ところで、propertyが値を保持するのって、ARCな言語特有の現象ではあるので (edited)
5:31 AM
それであるならば保持の意味合いを持たせたいなら原文もretainになってるのでは?と言う感覚がやはりありますね。
Avatar
岸川さんの言うように、必ずしも統一する必要はないと思いますが、上記の 2 例については「格納」でいいんじゃないかと思いました。基本指針としては「格納」で、文意として明らかに違和感があるときは他も検討するくらいでいいんじゃないでしょうか。tarunonさんの言うretainとの混同も気になりますし。
Avatar
omochimetaru 7/15/2022 5:40 AM
ソフトウェア系で stored が使われてる例だと stored procedure があるなあと思ったけどこれは「ストアドプロシージャ」で定着しててなんも参考にならんかった。
Avatar
まあ僕は「ストアドプロパティ」でもいいと思ってる派なので、自分で「格納プロパティ」と言うことはないですね。
Avatar
Kishikawa Katsumi 7/15/2022 5:45 AM
Storeの訳としては「保存」もあるけど、それが変数やstored propertyで不自然に感じるのは変数やstored propertyは削除するってことがないからかなあ。
Avatar
「保存」になるときは大抵ファイルへの書き込みを伴うんじゃないでしょうか? (edited)
5:49 AM
インメモリのKey-Value Storeみたいにメモリ上で完結することはあっても、概念的にファイルへの書き込みと抽象化されてるし。
Avatar
Kishikawa Katsumi 7/15/2022 5:49 AM
確かに保存というとそういう印象が出てきますね。
Avatar
「ストアドプロパティ」でもいいと思ってる派
僕もそう思っているのですが、いくつかのサイトを見て「格納プロパティ」と使われていたのと、プログラミングが初めての方には「格納」の方がイメージしやすいかなと思ってこの単語を選びました。
基本指針としては「格納」で、文意として明らかに違和感があるときは他も検討するくらいでいいんじゃないでしょうか。
これが良いかなと思いました。
保存
最初にこれを思い浮かべたのですが、ちょっとイメージと違うかなと思って「格納」もしくは「保持」にした記憶があります。
(edited)
Avatar
Avatar
koher
まあ僕は「ストアドプロパティ」でもいいと思ってる派なので、自分で「格納プロパティ」と言うことはないですね。
僕もこれ派ですね。ある程度カタカナでもいいんじゃないでしょうか
Avatar
ある程度カタカナでもいいんじゃないでしょうか
そうですね。ちょっと難しく考えすぎかもしないですねw
Avatar
初学者だと"ストアド"プロパティじゃなくて"ストアドプロパティ"として1単語で覚えてしまい、プロパティの意味を見失ってしまう可能性があるのか。難しいですね
Avatar
ストアド・プロパティとか?
6:01 AM
アソシエイテッド・タイプ、イグジステンシャル・タイプ、オペーク・タイプあたりになってくると全部カタカナが良いのか判断が難しそう。 (edited)
6:02 AM
かといって、存在型は existential type とか、訳語の対応覚えるのも無駄なんですよねぇ。
6:02 AM
「存在型」という単語から existential type の本質を理解できるわけじゃないし。
6:03 AM
invariantが「不変」と訳されてたけどimmutableとわかりづらいから「非変」と呼ばれることが多いとか。訳して何かわかりやすくなったのか?感がある・・・。
Avatar
Kishikawa Katsumi 7/15/2022 6:05 AM
まあカタカナだらけになるならそのままStored PropertyやExistential Type、Invariantって書いた方が分かりやすそう。
Avatar
Avatar
Iceman
初学者だと"ストアド"プロパティじゃなくて"ストアドプロパティ"として1単語で覚えてしまい、プロパティの意味を見失ってしまう可能性があるのか。難しいですね
項目としてプロパティの下に来てるので、ドキュメント内では問題ないかなとは思います。
t_naruhodo 2
Avatar
Avatar
Kishikawa Katsumi
まあカタカナだらけになるならそのままStored PropertyやExistential Type、Invariantって書いた方が分かりやすそう。
結局、僕はそれに逃げてるんですが、かといって「クラス」や「プロパティ」はカタカナで書くわけだし、どの方法も微妙なんですよね。カタカナ語が定着してるものはカタカナで書き、そうでないものは英語のままにする(初出時に読み方をカタカナで書く場合あり)というのが僕自身は読みやすいと思うので、一貫性はないですが自分で書くときはそれで妥協してます。 (edited)
6:07 AM
ただ、今回のは和訳プロジェクトなので、英語のままは微妙な気もするんですよね。
Avatar
Kishikawa Katsumi 7/15/2022 6:12 AM
定着してるものはカタカナで書き、そうでないものは英語のままにする
っていうので私は特に違和感はないです(完全に訳が間に合ってないということで単に諦めて受け入れたとも言える。その点で中国語はだいぶがんばっていると思うのですごい。)。
ただ、今回のは和訳プロジェクトなので、英語のままは微妙
ここも用語についてはできるものは訳したらいいと思うのですが、無理することはないと思うんですよね。おっしゃってたように
invariantが「不変」と訳されてたけどimmutableとわかりづらいから「非変」と呼ばれること
みたいなのを無理してどっちか選択することもないと思うし。
Avatar
今回のは和訳プロジェクトなので、英語のままは微妙な気もするんですよね。
実はそこが一番悩んだところで、個人的には全部英語で認識しているのですが、日本語訳なので日本語にした方が良いのかと思ってなるべく日本語にしたんですよね…(なんとか日本語を使おうという強迫観念にとらわれていたかもしれないですw)
Avatar
Kishikawa Katsumi 7/15/2022 6:14 AM
最近だと正規表現のマニュアルを日英で見比べたりすることがあったのですが、 (原文・英) https://docs.microsoft.com/en-us/dotnet/standard/base-types/grouping-constructs-in-regular-expressions#balancing_group_definition (日) https://docs.microsoft.com/ja-jp/dotnet/standard/base-types/grouping-constructs-in-regular-expressions#balancing_group_definition 日本語訳はがんばってるけど、特に用語に関してもそんなに無理に訳さないほうがわかるんじゃないかみたいなことは思います。
.NET でグループ化構造体を使用する方法について説明します。 グループ化構成体は、正規表現の部分式を表し、入力文字列の部分文字列をキャプチャします。
Learn to use grouping constructs in .NET. Grouping constructs delineate subexpressions of a regular expression and capture substrings of an input string.
t_naruhodo 1
Avatar
omochimetaru 7/15/2022 6:15 AM
structを構造体として定着したのにclassは「クラス」だったり不思議だなあ
6:16 AM
「種別体」とかだったらかっこよかったんじゃないか
Avatar
struct も Swift の文脈ではあまり「構造体」と呼ばない気がする。
6:16 AM
ただ、英文で structure と言われたときに何と訳すか難しい。
Avatar
Kishikawa Katsumi 7/15/2022 6:16 AM
structはCから来てる感じで私も「構造体」は不自然だなあと思ったりしますね。 (edited)
Avatar
やっぱり一つ一つ見直して検討していくのが良さそうですねぇ...日本語にするか、カタカナにするか、英語のままにするか (edited)
Avatar
omochimetaru 7/15/2022 6:16 AM
僕は結構日本語読みが定義されるのはそれはそれで面白いから好き 初学者がわかりやすいのかどうかとかはわからん。
Avatar
感覚の話だとstored propertyはもうstored propertyでしかなく、格納プロパティないし格納型プロパティと言われると、「ん…?ん?」となるのが正直なところ
t_wakaru 1
Avatar
omochimetaru 7/15/2022 6:17 AM
実用上は線引が曖昧なのが気持ち悪いから一応全部日本語の定義があってほしい。 (edited)
Avatar
名詞は英語ママで、動詞は翻訳するでも良いんじゃないかと言う感覚はありますね。それが成り立つのも日本語なので。
Avatar
Avatar
omochimetaru
実用上は線引が曖昧なのが気持ち悪いから一応全部日本語の定義があってほしい。 (edited)
用語の翻訳一覧表があって、英語のままにするものは日本語サイドに英語のまま入ってるとか?
Avatar
Avatar
tarunon
名詞は英語ママで、動詞は翻訳するでも良いんじゃないかと言う感覚はありますね。それが成り立つのも日本語なので。
これ一回やってみたことあるんですけど、クラスを class とか書き出すと読みづらかったんですよね。
6:18 AM
変数を variable にするのかとかもありますし・・・。
Avatar
omochimetaru 7/15/2022 6:18 AM
指定イニシャライザとcovenience イニシャライザ(Designated Initializers and Convenience Initializers)
こういうの気になるな・・・
Avatar
Kishikawa Katsumi 7/15/2022 6:19 AM
クラスを class、変数を variableが読みづらいっていうのは定着している(?)ものまで原文ままにするからだと思います
Avatar
omochimetaru 7/15/2022 6:19 AM
指定イニシャライザは、なるほど!と思ったので、convenienceは簡便イニシャライザとか。てかイニシャライザは初期化子とかじゃあないんだ
Avatar
誰も使っていない「指定イニシャライザ」という言葉を広めることに意味があるのかわからないんですよね。
Avatar
Avatar
Kishikawa Katsumi
クラスを class、変数を variableが読みづらいっていうのは定着している(?)ものまで原文ままにするからだと思います
omochimetaru 7/15/2022 6:20 AM
「クラス」はSwift以前から定着しているので仕方ないですけど、可能なら歴史を巻き戻して和訳された世界にしたい
Avatar
もしこれで学習した初学者に「指定イニシャライザがよくわからないんですけど・・・」って質問されても、僕は「指定イニシャライザって何???」となると思います。
Avatar
Kishikawa Katsumi 7/15/2022 6:21 AM
クラスを class、変数を variableが読みづらいっていうのは定着している(?)ものまで原文ままにするからだと思います
これはルー大柴っぽくなるから読みづらい(不自然)っていうくらいの意味で書きました。
Avatar
イニシャライザは初期化子とかじゃあないんだ
initializationは初期化なので、今となっては初期化子だなあと思ってます。
指定イニシャライザって何???
ですよねw
(edited)
Avatar
Avatar
Kishikawa Katsumi
クラスを class、変数を variableが読みづらいっていうのは定着している(?)ものまで原文ままにするからだと思います
そうなんですよね。なので、クラスやプロパティはカタカナにして、 stored property は英語のままにするという妥協を受け入れてます。一貫性より読みやすさ重視。
Avatar
Kishikawa Katsumi 7/15/2022 6:22 AM
Designated Initializerはどうやっても難しいやつだなあ。
Avatar
今、トップページに原文と日本語訳の比較表を作成しようとしていて、ここに書いておけばわからなくても原文を参照して理解してもらえますかねぇ... https://www.swiftlangjp.com/#開発について (edited)
Avatar
Kishikawa Katsumi 7/15/2022 6:23 AM
指定イニシャライザはAppleのドキュメントでも使われてるし悪くないと思うけど何もわからんというのもある。
6:24 AM
Designated Initializerって書くとデザイネイテッド イニシャライザーって読む人がめっちゃ増えそうっていうのもある。
Avatar
Avatar
Kishikawa Katsumi
指定イニシャライザはAppleのドキュメントでも使われてるし悪くないと思うけど何もわからんというのもある。
omochimetaru 7/15/2022 6:24 AM
Appleのドキュメントでも使われてる
どこにあるんですか?
Avatar
Kishikawa Katsumi 7/15/2022 6:24 AM
Objective-Cのやつ
Avatar
omochimetaru 7/15/2022 6:24 AM
ああ〜
Avatar
Kishikawa Katsumi 7/15/2022 6:25 AM
Designated InitializerはObjCからの話だからそれであってると思う。
Avatar
omochimetaru 7/15/2022 6:25 AM
そういえばObjCのころは結構公式和訳いろいろありましたね
Avatar
Avatar
omochimetaru
「クラス」はSwift以前から定着しているので仕方ないですけど、可能なら歴史を巻き戻して和訳された世界にしたい
「クラス」すら書き換えたいというのは過激な意見だね😅 「不変」問題とかどうやってもニュアンスが失われるところがあるから、全部日本語にこだわるのは難しくないかなぁ。そして、そうやってこだわっても結局英語読まなきゃいけないから、全部対応を覚えることになるわけだし。
Avatar
Avatar
Kishikawa Katsumi
Designated InitializerはObjCからの話だからそれであってると思う。
omochimetaru 7/15/2022 6:25 AM
はい、概念はObjCから繋がってると思います
Avatar
Avatar
koher
「クラス」すら書き換えたいというのは過激な意見だね😅 「不変」問題とかどうやってもニュアンスが失われるところがあるから、全部日本語にこだわるのは難しくないかなぁ。そして、そうやってこだわっても結局英語読まなきゃいけないから、全部対応を覚えることになるわけだし。
omochimetaru 7/15/2022 6:26 AM
「構造体とクラス」って並べた時の違和感が一生消えないんですよね。
Avatar
Kishikawa Katsumi 7/15/2022 6:26 AM
まとまらないですね😅
Avatar
omochimetaru 7/15/2022 6:26 AM
構造体とXX体 であってほしかった・・・
Avatar
Avatar
omochimetaru
「構造体とクラス」って並べた時の違和感が一生消えないんですよね。
それはわかります。僕は「構造体」を「ストラクト」にしてほしいです。
Avatar
Kishikawa Katsumi 7/15/2022 6:26 AM
「構造体とクラス」って並べた時の違和感が一生消えないんですよね。
歴史を遡って、っていうのがそういう意味か。それはわかる。
Avatar
Avatar
omochimetaru
「構造体とクラス」って並べた時の違和感が一生消えないんですよね。
これはそうであっても別に問題には感じないなぁ。それに、クラスをXX体みたいな名前を付けて運用するのは、誰も幸せにならない
Avatar
omochimetaru 7/15/2022 6:27 AM
「関数とメソッド」もいつもモヤッとする
Avatar
Kishikawa Katsumi 7/15/2022 6:28 AM
関数とメソッドはこだわるのは宗教的なやつだから
Avatar
カタカナ語の優れてるところもあって、「メソッド」が「手法」みたいに訳されちゃうと、文章の中で一般的な日本語を指してるのかそれとも用語を指してるのかわからなくなってしまう。
Avatar
Avatar
tarunon
これはそうであっても別に問題には感じないなぁ。それに、クラスをXX体みたいな名前を付けて運用するのは、誰も幸せにならない
omochimetaru 7/15/2022 6:28 AM
今から付けても混乱しかしないのはそうだけど、最初に「クラス」って日本語を書いた人が歴史上にいるわけで、そこを過去に戻って直せたらいいのになあと思う (edited)
Avatar
Kishikawa Katsumi 7/15/2022 6:28 AM
そういう使い分けをしている言語や宗派もあるってことで全部関数かfuncでいいね。
Avatar
関数とメソッド
これFunctionsとMethodsで項目別れているんですよね...
Avatar
Kishikawa Katsumi 7/15/2022 6:29 AM
あ、そうか。
6:29 AM
読んでみよう。
Avatar
一般的に邦訳があるもの、Appleがドキュメント内で邦訳で言及したもの、それらについて日本語を使い、それ以外は原文ママで。 新しく見つかり次第置き換えていく、そんな感じが一番バランスが良い気がしていますね
6:30 AM
邦訳の対照表はあってよくて、まだ邦訳してないものは英英で書いておく。んでこのポリシーも並べておけば
t_naruhodo 1
Avatar
Kishikawa Katsumi 7/15/2022 6:30 AM
ああ、まあ確かにInstance Funcってあんまり言わないしなあ。
6:30 AM
Class FuncやStatic Funcはいけるのに。
Avatar
三方良しとは行かないまでも、ある程度人々は幸せになれるのでは
Avatar
Kishikawa Katsumi 7/15/2022 6:30 AM
そういう意味でFuncとMethodは区別されてるってことね。
Avatar
Avatar
koher
カタカナ語の優れてるところもあって、「メソッド」が「手法」みたいに訳されちゃうと、文章の中で一般的な日本語を指してるのかそれとも用語を指してるのかわからなくなってしまう。
omochimetaru 7/15/2022 6:30 AM
あーなるほど。元の意味と分離できるメリットはあるんですね。
Avatar
Avatar
tarunon
三方良しとは行かないまでも、ある程度人々は幸せになれるのでは
どこまでいっても完全な一貫性は実現できないので、それが現実的で良いと思います。
Avatar
omochimetaru 7/15/2022 6:31 AM
じゃあ英語の人は専門外の文章とか読む時そういうヒントが効かなくて難しかったりするのかな。
Avatar
Kishikawa Katsumi 7/15/2022 6:31 AM
それは気になってる。
Avatar
Avatar
omochimetaru
じゃあ英語の人は専門外の文章とか読む時そういうヒントが効かなくて難しかったりするのかな。
それ思うときあるんよね。しかも専門用語に結構一般的な単語使うし。
🥴 1
Avatar
Kishikawa Katsumi 7/15/2022 6:31 AM
importとかそういうのどう聞こえてるんだろう。みたいな。
Avatar
omochimetaru 7/15/2022 6:32 AM
輸入!
Avatar
Kishikawa Katsumi 7/15/2022 6:32 AM
そうそう。
Avatar
propertyとかも普通に使いそうですよね。
Avatar
Kishikawa Katsumi 7/15/2022 6:32 AM
基礎を輸入して、、、みたいなふうに聞こえてるのか、それとも
Avatar
omochimetaru 7/15/2022 6:32 AM
Avatar
Kishikawa Katsumi 7/15/2022 6:32 AM
Foundationをインポートして、と聞こえてるのか。
6:33 AM
私は後者だと思ってるけど。
6:33 AM
めっちゃ脱線してきた。
Avatar
まあでもよく考えたら、力学で「力」とか「仕事」とか言っててもあまり混同しないし大丈夫なのかも。
Avatar
初学者は苦労するぐらいの温度感だと思いますよ
Avatar
Kishikawa Katsumi 7/15/2022 6:36 AM
他の言語のドキュメントをよくやってる人に相談してみたいな。 ドキュメント翻訳ミートアップをするといいんじゃないか。
t_naruhodo 1
Avatar

小項目タイトルの変更

原文では Stored Properties of Constant Structure Instances のところ、定数の格納インスタンスのプロパティ と翻訳されていました。 定数の格納インスタンス定数に格納されたインスタンス という意味で通りそうですが、それでもPropertyにかかるStoredが抜け落ちているため、翻訳として適切でないと思います。 methods.mdからこの項目へのリンクがあったので、併せて修正しています。

コード中のコメント修正

原文では// this range represents integer values 0, 1, 2, and 3です。 3が抜けてコードと矛盾していました。
Avatar
一般的に邦訳があるもの、Appleがドキュメント内で邦訳で言及したもの、それらについて日本語を使い、それ以外は原文ママで。
これどういう所を参照すれば良いですかね?😅 Appleが邦訳出すことってあるのでしょうか?
Avatar
昔いろいろあったんですが最近ないですよね
Avatar
Kishikawa Katsumi 7/15/2022 7:23 AM
Appleが邦訳出すことってあるのでしょうか?
Swiftについてはわからないけど、各種SDKや機能については現在も和訳のドキュメントがあるものはありますね。 なんとかエクステンションとかウィジェットとか。そこでコードが出てくる場合は用語がわかったり。 あとはWWDCの字幕も機械翻訳じゃない日本語字幕が確かあります。2022もつき始めてるんじゃなかったかな。
(edited)
Avatar
ありがとうございますmm
あとはWWDCの字幕も機械翻訳じゃない日本語字幕が確かあります。
あ、そうなんですね。すごい不自然って思ってましたw
(edited)
Avatar
Kishikawa Katsumi 7/15/2022 7:26 AM
もしかして機械翻訳なのかな。。。?
7:27 AM
キーノートみたいな最初からついてるやつじゃなくて後からついたやつは違うんじゃないかと思ってるんですけど。
Avatar
日本語字幕はあまり見ないのでもしかしたら何か別のものと勘違いしているかもしれません😅 scriptとか色々見てみます。ありがとうございます!
Avatar
Apple公式から拾ってくるの、初動で頑張る必要は無いんじゃないかなと思っていて、それこそ気付いた人がURLとセットで持ってきてPR作るみたいな感じで漸進的に進めていけば良いんじゃないか、と考えています
👍 2
Avatar
そうですね。そうしていけると良いなと思いました。(やってみると言ったものの、結構途方もない作業になりそうだなあと感じ始めてましたw)
Avatar
大昔のものも、どこまで考慮すべきか微妙ですよね。今の慣例と違うかもしれないし。たとえば、大昔にAppleがattributeを「属性」と呼んでたとしても、今のSwiftではattributeと呼ぶのが主流ですし。
t_naruhodo 1
Avatar
こんなページあったんですね。知らなかった…. https://developer.apple.com/jp/documentation/
👀 2
Avatar
Appがサポートするアクティビティごとに、GroupActivity(英語)プロトコルに準拠した軽量のクラス/構造体を定義します。
https://developer.apple.com/jp/documentation/groupactivities/inviting-participants-to-share-an-activity/ 「クラス」とか「構造体」とか使われてるし、参考になる部分ありそうですね。 (アプリじゃなくて「App」なのか。)
(edited)
👍🏻 1
Avatar
結構バラバラなんですね👀例えば 英語のママ Extension -> Extension enum->enum … カタカナ表記 type -> タイプ(「型」のところもある) subscript -> サブスクリプト KeyPath->キーパス initializer->イニシャライザ retain->リテイン … 日本語変換 modifier -> 修飾子 attribute -> 属性 reference type -> 参照型 conformance->準拠 type inference->型推定(「推論」もある) … formattingは名詞的に使うと「フォーマット」で、動詞的に使うと「書式設定する」になっている。 (edited)
Avatar
「タイプ」はすごく違和感がありますね😅
Avatar
omochimetaru 7/16/2022 7:31 AM
えー型推論じゃあないのぉ
Avatar
このドキュメントが機械翻訳か、(プログラミングの)非専門家による翻訳なのかも。 (edited)
Avatar
怪しいのはWWDCの字幕ですね。場所によって訳が変わってますし、やっぱり機械っぽい気がします。 ここら辺もちょっと違和感がありましたw(WWDC字幕) semantics->意味論 actor->アクタ
Avatar
方針として、
  • 一般的に邦訳があるもの、Apple がドキュメント内で邦訳で言及したものについてはそれを採用
  • 見つからない場合は英語のまま
Avatar
読みやすくなるよう訳の文章に変更を施した Fix stzn#301 Closes #301
Avatar
#297 で指摘しましたが、このPRでは正誤対応の誤側を修正してしまっています。 該当箇所はtextlintで勝手に修正されてしまうようだったので、textlint-disableで無視するようにしました。
Avatar
これは公開されている HTML を基準にして、作業する Markdown ではバックティックを使うという意味であってますか?
Avatar
翻訳時のバックティックについて説明を追加する。 Fix stzn#312 Close #312
Avatar
こちらマージします。何かご意見ありましたらissueなどでお知らせくださいーmm
Avatar
  • Concurrencyがなかったので追加
  • if letの同名省略の記述を追加(Swift5.7からなのでコメントアウトしています)
  • その他翻訳の改善
判断に迷う箇所はコメントしていきます。
Avatar
元のままでも意味はわかるんですが、この文で 全て を それぞれ にしたい場合、各 を使うと引っ掛かりなく読める訳になるんじゃないかなぁと。
Avatar
@jollyjoester こちら進捗いかがでしょうか?お忙しければ引き取ります!
11:19 AM
@tsubasarc
元のままでも意味はわかるんですが、この文で 全て を それぞれ にしたい場合、各 を使うと引っ掛かりなく読める訳になるんじゃないかなぁと。
ここ自分の誤解が原因で元の文が変だと思って変更してしまっていました。 特定の列挙ケースの全てのインスタンス だと一つの列挙ケースにたくさんインスタンスがあるということになり、それは変じゃないかと思ったのですが、Swiftの列挙体は値型なので、別の変数に代入すればそれは異なるインスタンスになるのでした。ここは元の文に戻しておきます。
それと、Another choice for enumeration cases is to have values associated with the case の日本語訳がちょっと違うと感じたのでレビューしてみました。
レビューコメントが見えていないのですが投稿できているでしょうか? Suggestion送っていただければ共著コミットにします。
11:24 AM
@t-ae そうだったんですね。分かりました!
レビューコメントが見えていないのですが投稿できているでしょうか?
すみません、レビューという言い方が間違ってました。 たぶん、レビュアーにアサインされていない僕は suggestion できないと思うので、さっきのはコメントとして考えを書いてみた次第です。
11:28 AM
あれ?できないですか? 私は #309 で横からsuggestion出しているのでできないことはないと思いますが… 設定上私からレビュー依頼を出すことはできないようです。
Avatar
@t-ae ごめんなさい! 出来るにはできるのですが、アサインされてないのでロール違うかなという気持ちから出た言い方でした…。 Suggestion しますね。
11:40 AM
今、お二人Collaboratorに入れてみたのですが、これでreviewerに追加できるようなりますでしょうか?
11:42 AM
@stzn Reviewersの設定ボタンは出たのですが @stzn さんしか一覧に出ませんね。 assigneesのほうも設定ボタンが出て、こちらは @tsubasarc さんも設定できるようです。
Avatar
@stzn うわすみません!失念していました🙏この土日目処に実施させてください!
Avatar
すいません僕の説明の仕方が良くなかったです。関連値に関しては訳が決まっているので、初出時だけ「関連値(Associated Values)」として残りは関連値として欲しかったです🙇🏻‍♂️(変ですかね...?) suggestion もし列挙型が Raw Value を持つ場合、これらの値は宣言の一部として決定されます。これはつまり、特定の列挙ケースの全てのインスタンスは、必ず同じ Raw Value を持つということです。もう 1 つの選択肢は、列挙ケースに関連値\(Associated Values\)を持たせることです。関連値はインスタンス生成時に決定され、列挙ケースのインスタンスごとに異なる値を持つことができます。関連値は列挙ケースのインスタンスの格納プロパティのように振る舞います。例えば、サーバから日の出時刻と日の入り時刻をリクエストする場合を考えてみてください。サーバはリクエスト情報に応じたレスポンスを返すか、リクエストが間違っている場合は間違っているという内容を返します。
11:49 AM
ちなみにRaw Valueですが、WWDCでは「Raw値」となっていましたが...どうなんでしょう😅
Avatar
Raw値…実際使われてるのは見たことないですね。 公式翻訳を重視するのもいいですが、日本語コミュニティで広く使われている呼び方があるならそれを使うというのもありかなと思います。読者がコミュニティに流れてきたときに違和感なく溶け込めるので。 ところでREADME.mdによると
なお、英語のまま表記の大文字、小文字は、原文の記載に従います。 通常の英語と同様に文の開始は大文字、その他は小文字 例: 開始 -> Computed property、その他 -> computed property
とのことですが、Raw Valueでは守られていないようですね。 この文章はCONTRIBUTION.mdのほうに記載がないので、正規のルールならそちらに追加すべきかと思います。
2:28 PM
訳が決まっていたのでこれが良いですね。ありがとうございます。 Associated Values が複数形になっていますが、Raw Value が全体に単数形なので、そちらに合わせて単数形にしておきます。
7:04 PM
ありがとうございます! このルール最近決まったので逆にそうなっていない所を修正したいと思ってました。なので、もし可能であれば一緒に直していただけると嬉しいですmm
7:10 PM
英語表記ルールにマッチしていない既存の表記を修正したい。 通常の英語と同様に文の開始は大文字、その他は小文字 例: 開始 -> Computed property、その他 -> computed property
Avatar
  • [README] 記号の表現方法を変更
  • [README] リンクを修正 開発ガイド (CONTRIBUTION) のリンクが
別のブランチのものを参照しているのですが、 もしかしたら何かの手違いなのではと思います。 確認、お願いします 🙇
Avatar
subscript が英和対応表に書かれていません。 サブスクリプトという語彙は以下のドキュメントで決まっていますが、他の文書で使用されているのは subscript がほとんどのようです。 https://github.com/stzn/the-swift-programming-language-jp/blob/master/language-guide/subscripts.md 定数、変数、プロパティ、または subscript のようになっている文章が多く、サブスクリプトにしたほうが読みやすいかと思います。
2:05 AM
原文ではバックティックのついていない箇所ですが、ここでは半径と名前を指すと同時に引数名を指定していると考えられます。 コードについての指定になるため、バックティックで囲うのが適切かと思い付けました。
Avatar

訳をどうするか

この話の結論をすぐに出すのは難しいと思うので、 issue ではなく discussion を作りました。 Discussion だと、あとで人が探しやすいというのもあります。

現状

WWDC の字幕ではまだ訳されていないと思います。 日本語字幕の中でそこだけ opaque type となっていました。 これに対する訳は他の言語コミュニティでも定まっていなさそうで、 一番定着している訳というのもわからなかったです。 他方、データベースの型について調べると 簡単に変わることはないのではと思う例がありました。 IBM と Oracle は自社製品に関するドキュメントの中で 不透明型 という訳を使っています。
3:03 PM
僕はいつか Apple が訳すまでの間だけでも 不透明型 とするのはどうかなと思っています。
Avatar
僕個人としては、不透明型だとちょっと何を指しているのかがわからない印象がありますね😅opaqueはopaqueとしてみんな理解していると思っているので、やるとしてもopaque型ですかねー。protocolを契約、genericsを一般化とは訳さないのに近い感覚があります。 ただ、オペーク型...だとちょっと違和感ありますね。ここは他の方のご意見もお伺いしたいですね。
Avatar
protocolを契約、genericsを一般化とは訳さないのに近い感覚があります。
これ分かります! いやそうはならんだろですね。
オペーク型...だとちょっと違和感ありますね。
不透明型でない時はプロトコルやジェネリクスに倣ってオペーク型はどうかなと思ったのですが… 💧 妥当な訳がない時、読む側のことを考えれば翻訳しすぎない方が一番 contribution かも知れないですね。
8:14 PM
protocolを契約、genericsを一般化とは訳さないのに近い感覚があります。
これ分かります! いやそうはならんだろですね。
オペーク型...だとちょっと違和感ありますね。
不透明型でない時はプロトコルやジェネリクスに倣ってオペーク型はどうかなと思ったのですが… 💧 妥当な訳がない時、読む側のことを考えれば翻訳しすぎない方が一番 contribution かも知れないですね。
Avatar
Collection Types このページで開発ガイドの規則が守られていない箇所を直していきます。 例: 表記揺れがありました https://github.com/stzn/the-swift-programming-language-jp/blob/777b7d6f03b85e6de0000d0226c133f2b870d0c2/language-guide/collection-types.md?plain=1#L10 value の訳が ではなく バリュー となってしまっています。 GitHub の Projects 機能で管理してもいいのではないでしょうか。
Avatar
ありがとうございます! この部分に関しては、配列、セットにもかかっているので「値」で良いと思います。 考えどころなのは、辞書の場合「キーバリュー」という組み合わせで使っているため、「値」ではなく「バリュー」という表現が適している箇所があるのかなと思っています。(ここも他の方のご意見をお伺いしたいところです。)
GitHub の Projects 機能で管理してもいいのではないでしょうか。
こういう機能がベータであるんですね💡時間のある時に調べてみますmm
Avatar
辞書だけに触れている時の value は文脈による可能性ということですね。 要素 という語も浮かびましたが、適切なのか分かりません…。 とりあえず value の表記揺れは他の方の意見を待ち、 それ以外の部分をチェックしていきます 😃
Avatar
@stzn さんに確認です! 以前にも話に上がった store については、ドキュメント全体における統一という意味なのでしょうか。 https://github.com/stzn/the-swift-programming-language-jp/issues/301#issuecomment-1185332858
1:23 AM
キーバリューペアという語は定義があるので、key-value pair についてはキーバリューペアでいいと思います。 https://github.com/stzn/the-swift-programming-language-jp/blob/777b7d6f03b85e6de0000d0226c133f2b870d0c2/language-guide/collection-types.md?plain=1#L474 これを根拠として、辞書型ではバリューを使っていくというのでも良いんじゃないでしょうか。
Avatar
すいません、言い方が回りくどくてわかりずらいですね💦 @t-ae さんのおっしゃる通り「キーバリューペア」という決まった言い回しがあるので、辞書の場合はバリューを使った方が良いと思っています。 storeに関しては、決まった言い回しがないのですがわかりやすさという点で「格納」に統一した方が良いという話になりました。
Avatar
@t-ae さんのおっしゃる通り「キーバリューペア」という決まった言い回しがあるので、辞書の場合はバリューを使った方が良いと思っています。
分かりました、辞書の value については バリュー の訳になるよう気をつけます!
storeに関しては、決まった言い回しがないのですがわかりやすさという点で Stored propertyを「格納プロパティ」としているところから「格納」に統一した方が良いという話になりました。
ではここでも 格納 にして問題なさそうなところはそのようにしていきますね。
Avatar
@tsubasarc Approveして貰えればマージできる状態です。 subscriptの翻訳が残っていますが、これは後で他ファイル含め一括でやろうと思います。
1:54 AM
遅くなってすみません! Approval しました。 次回からは気をつけます… 🙇🏽
Avatar
subscriptサブスクリプトに翻訳します。 関連:#320
Avatar
現状ではキーパスKeyPathkey-pathkey pathが混在しています。 原文では型を指す KeyPath 以外では key pathkey-path が使われています。 関連して、identity key path(.self)の翻訳が識別キーパスとなっていますが、識別だと意味が違うような気がします。
9:19 AM
本当は 型が Sendable であることを示すことができます にしたいがlintで弾かれる。
Avatar
structured concurrency の翻訳が 構造同時並行性 になっていましたが、構造化された並行性 という翻訳が他言語でも広く使われているようです。 構造同時並行処理 のような形で出てきている箇所もありますが、これらも併せて変更しています。
9:40 AM
非構造タスク(unstructured task)構造化されていないタスク にすべきか迷ってとりあえずそのままにしています。 また、原文ではunstructured taskの初出は斜体になっているのですが、翻訳の際にルールはあるのでしょうか?
11:25 AM
構造化されていないタスクの方が、わかりやすい気がしますねー。 >原文ではunstructured taskの初出は斜体になっているのですが、翻訳の際にルールはあるのでしょうか? 基本原文に合わせようとしているので、なってなかったら間違いだと思います。ごめんなさいmm
11:27 AM
おそらく「です、ます調ルール」のやつですね。必要であれば別issueで検討しましょう。
11:31 AM
ありがとうございます。型はKeyPathで良いかなと思いました。残りは日本語訳が見つからなければkey pathが良いかなと思いますが、いかがでしょうか?
関連して、identity key path(.self)の翻訳が識別キーパスとなっていますが、識別だと意味が違うような気がします。
変ですね。self key pathで良いような気がしますねー。いかがでしょうか?
11:42 AM
個人的には 構造化されていない〜 という否定形が何度も出てくると読みにくいかなと感じました。 一方、少し上の方でunstructured child task独立した子タスクと翻訳している箇所がありました。 unstructured の翻訳として 独立した を使うのが正当なのかはよく分かりませんが、読みやすさだけなら 構造化されていないタスク より 独立したタスク のほうが上だと思います。意味的にもずれてはいないと思いますがどうでしょうか。
Avatar
以下の18:44から SE-0249 Key Path Expressions as Functions の話ですが、字幕では全体に KeyPath ですね。 https://developer.apple.com/videos/play/wwdc2020/10170 型の KeyPath と混在してしまうという問題がありますが…
変ですね。self key pathで良いような気がしますねー。いかがでしょうか?
下手に 自己参照KeyPath みたいにするより self KeyPath のほうがシンプルで良さそうですね。
Avatar
字幕では全体に KeyPath ですね。型の KeyPath と混在してしまうという問題がありますが…
そうですねえ...ひとまず公式に合わせて、もしわかりづらいなどの意見が出てきたら検討し直すが良いかなと思います!
12:48 PM
読みやすさだけなら 構造化されていないタスク より 独立したタスク のほうが上だと思います。
構造化された ⇄ 構造化されていない の対比で良いかなあと思ったのですが、確かに「独立した」の方が意味的にもわかりやすい気がしますね。
2:02 PM
unstructuredの翻訳を独立したに変更しました。
構造化された ⇄ 構造化されていない の対比で良いかなあと思ったのですが、
同様に思っていたので、カッコ書きでunstructured taskを残してみました。
3:29 PM
@stzn 遅くなりました!レビューをお願いします! 質問です! Localでの確認 or GitHub pagesのbranchでの確認ってどうされてますか?別ページのセクションのリンクが合っているかを動作確認したいのですが、うまい方法を知らず🤔
Avatar
僕はVSCodeのプレビューをクリックして確認してますね。GitHub pagesブランチはmainから自動マージしているのでmainが正しければ正しいとしています。(何か間違っていたらご指摘ください😅
7:16 PM
他と同じ表現で良いかなあと思いました。 * 正規表現の作成に関する情報を [正規表現リテラル](../language-reference/lexical-structure.md#lexical-structure-regular-expression-literals) セクションに追加しました
7:16 PM
* アクターとタスク間のデータ送信に関する情報を [Sendable Types](../language-guide/concurrency.md#sendable-types) セクションに追加しました。また、[@Sendable](../language-reference/attributes.md#sendable) 属性と [@unchecked](../language-reference/attributes.md#unchecked) 属性に関するセクションを追加しました
Avatar
了解です! 提案もありがとうございます。取り込みました!
Avatar
LGTMです👍🏻ありがとうございます!もう少し他の方の意見がないか様子見てからマージしたいと思います。
Avatar
  • キーパスの翻訳を KeyPath に統一
  • identity key path (\.self) の翻訳として self KeyPath を導入
Closes #325
11:29 PM
すいません。コメントしたと思っていたらpendingになってました🙇🏻‍♂️
11:29 PM
デタッチタスクも何か変えたほうが良いかなあと思い始めたのですが、「独立した」に合わせて「完全に独立した」がわかりやすいそうでしょうか?それとも区別がしづらいので「切り離され」とかの方が良いでしょうか?
Avatar
この Issue は Close します。 とても質が良かったので subscript syntax だけ翻訳していたのですが、 @t-ae さんによる先の PR で包括的に解消済み 🎉
Avatar
僕も @stzn さん支持で、 どちらも 独立 にまとめてしまうのは少し雑な気がします。
1:38 AM
原文だと To create an unstructured task that’s not part of the current actor, known more specifically as a detached task, で、detached task ⊂ unstructured task という関係が明示されています(翻訳では省略されていますね)。 なので独立したタスクの中に完全に独立したタスクがあるというのも一理あるかとは思うのですが、読みやすさでは切り離されたタスク のほうが良いと思います。
8:13 AM
ありがとうございます! そうしましたら「切り離されたタスク」にしたいと思います。
(翻訳では省略されていますね)
漏れていたのかもしれないですね...🙇🏻‍♂️もし必要だと判断されてお手数でなければ翻訳を追加していただけると嬉しいですmm
Avatar
切り離されたタスク こちらで書き換えました。 省略箇所は省略したままでも問題ないと思いそのまま残しました。 (省略しない場合は 現在のアクター上で実行されない独立したタスク となり、独立した の意味がブレそうなのが気になるのも一因です)
10:06 PM
現状、原文に記載のあるSwift5.7の更新は完了したので、バージョン履歴を追加しました。最後にマージされたPR日を記載しています。
Avatar
アクセスレベルの高低が逆になっているなどの誤訳があったので修正です。
Avatar
原文ではaccess contextaccess level context が出てきて、ここでは access context です。 使い分けがよく分かりませんが、とりあえず出てくるものに合わせました。
9:18 AM
原文 but whose conformance to an internal protocol can only be used within the internal protocol’s defining module. 準拠自体のアクセスレベルの話をしているようなので、プロトコルへ準拠した実装は は違うと思います。 ある型が InternalProtocol を実装しているとして、外部のモジュールからは InternalProtocol に準拠していることを認識できないというような意図ではないかと思っています。
Avatar
Closes #143 プリント文の翻訳をしました。 とりあえず一日の作業量なので3ファイル分です。 全部で33ファイルあります。 これで終わりではなくいくつかのパートに分けてpull requestを送りたいと思っています。
2:39 PM
John Appleseed 人名も翻訳したほうがいいですかね? 例えば「ジョン・アップルシード」に変えたほうがいいでしょうか?
2:41 PM
2:42 PM
2:47 PM
Customerクラスのnameプロパティなので、呼称を「さま」にしました。
Avatar
全てのタイプエイリアスは、アクセス制御の目的で別個の型として扱われます。タイプエイリアスは、エイリアスする型のアクセスレベルより制限の厳しいアクセスレベルを設定することができます。例えば、private タイプエイリアスは private、fileprivate、internal、public、または open 型のエイリアスになれますが、public タイプエイリアスは internal、fileprivate、または private 型のエイリアスにはなれません。
7:38 PM
ありがとうございます!間違いの修正、すごい助かりますmm細かい点についていくつかコメントしました。
7:38 PM
ここはat least as high as the enumeration’s access levelなので、「少なくとも同じレベル」で良いかなと思ったのですが、わかりづらいでしょうか?
7:38 PM
[Default Initializers\(デフォルトイニシャライザ\)](../language-guide/initialization.md#default-initializers)で説明されているように、Swift は、全てのプロパティにデフォルト値が提供されていて、かつ 1 つもイニシャライザが定義されていない構造体または基本クラスに、引数なしの_デフォルトイニシャライザ_を自動的に提供します。
11:39 PM
少なくとも同じレベル -> 同じかより高い -> 同じかより緩い で同じ気がしてきました… 頭の中で緩厳で認識していたので、少なくとも同じレベルだと緩厳どちら方向が許されるのか曖昧だなと思ったのですが、高低で考えると分かる箇所ですね。 元に戻します。
Avatar
suggestion 列挙型定義の Raw Value または関連値に使用される型には、少なくとも列挙型のアクセスレベルと同じ高さのアクセスレベルが必要です。例えば、private 型を internal アクセスレベルの列挙型の Raw Value 型として使用することはできません。 https://github.com/stzn/the-swift-programming-language-jp/pull/333#discussion_r939156980 このコメントで元の文を復元したのですが、元の文はレベルが複数回出てきて読みにくい気がします。 アクセスレベル自体が高低を持った概念なので、少なくとも同じレベル という言い回しより 少なくとも同じ高さで良いかと思いました。
4:16 AM
ありがとうございます!「さん」や「さま」が必要かどうかはちょっと悩みどころですね。。。いらないのかなという気もしていますが、他の方のご意見もお伺いしたいです。
Avatar
ありがとうございます!「さん」や「さま」が必要かどうかはちょっと悩みどころですね。。。いらないのかなという気もしていますが、他の方のご意見もお伺いしたいです。
「さん」や「さま」の敬称、気を効かせた意訳だったんですが、考えてみれば文脈に依存しすぎていて整合性取るのが難しいので一律なしにしたほうが良いかなと思ってきました。 この変更でもnameプロパティで3つも出し分けが必要でした。
  • Personnameプロパティ: 「さん」
  • Customernameプロパティ:「さま」
  • HTMLElementnameプロパティ:敬称なし
敬称なしで更新します
7:53 PM
ご指摘ありがとうございます!ここら辺あまりわかっていなかったのでとても助かりますmm
2:49 AM
原文The fallback logic to use “World” when name is nil has to be done inline using the ?? operator, インラインで実行する だと意味が通らないので 記述する に変更しました。
Avatar
@stzn approveありがとうございます! このprは @stzn sanがマージしますか? このPRがマージされた後に別PRとしてpart2のprint文翻訳をpull request送りたいなと思ったのですがどうでしょう? 分量はpart3ぐらいまでを考えています。(part3のpull requestで #143 の対応がすべて終わるイメージ)
6:31 AM
@SatoTakeshiX san すいません。他の方のご意見もあるかなと思って少し待っていました。明言せずに申し訳ございませんmm なさそうなのでmergeします! 今のところは、こちらで最終確認してmergeしようかと思ってます(やりにくければ再検討)。
Avatar
typoの修正くらいなら更新しなくてもいいかなと思ってましたが、この文書は一応翻訳も変えてるので更新しますね。 basic-operators.mdのほうはtypo修正だけなので更新しないでいいでしょうか。
Avatar
ありがとうございますmm
basic-operators.mdのほうはtypo修正だけなので更新しないでいいでしょうか。
はい、内容の変更がないのでいらないと思います。
2:36 AM
間違えてスペースが入ったのではと思うのですが、確認お願いします 🙇🏽
2:42 AM
これは改行のためのスペースです。 抜けていたので修正しました。 他のドキュメントもこの行はスペースで改行していますが、誤って消しやすいので全部二重改行に置き換えてもいいかもしれませんね。@stzn
2:56 AM
そうだったんですね。失礼しました! 僕が触ったファイルはこの箇所のスペースを消してしまっていると思います。 例えばよく知られている事柄に対して単なる己の無知が原因かも知れないですし、このままスペースを使う改行方法でいいと思いますが、方法をどうするかは @stzn さんからも何か意見を聞けたらと思います。
4:33 AM
>他のドキュメントもこの行はスペースで改行していますが、誤って消しやすいので全部二重改行に置き換えてもいいかもしれませんね。 そうですね。markdownのこの改行方法はわかりづらいので、二重改行に置き換えが良いような気がします👍🏻 これは別issueで対応しましょう!
4:34 AM
最終更新日と原文の間がスペース2つで改行する方法をとっているが、間違いやすいので二重改行に置き換える。 他にもあった場合は変更したい。
Avatar
@shiz このissueを対応中です。 https://github.com/stzn/the-swift-programming-language-jp/issues/143 ファイルの本文にかかれている「最終更新日:」はprint文の翻訳した場合も更新したほうがいいでしょうか? https://github.com/stzn/the-swift-programming-language-jp/pull/335 をマージしてもらったあとに気づきました。今part 2しているので、更新必要なら次のpull requestで対応します (edited)
Avatar
Avatar
Takeshi
@shiz このissueを対応中です。 https://github.com/stzn/the-swift-programming-language-jp/issues/143 ファイルの本文にかかれている「最終更新日:」はprint文の翻訳した場合も更新したほうがいいでしょうか? https://github.com/stzn/the-swift-programming-language-jp/pull/335 をマージしてもらったあとに気づきました。今part 2しているので、更新必要なら次のpull requestで対応します (edited)
はい、更新をお願いしますmm前回気が付かずすいません🙇🏻‍♂️
👍🏻 1
Avatar
Avatar
shiz
はい、更新をお願いしますmm前回気が付かずすいません🙇🏻‍♂️
ありがとうございます。次回のpull requestで前回分含めて更新しますね
👍🏻 1
Avatar
Closes #143 下記pull requestのpart 2です。 https://github.com/stzn/the-swift-programming-language-jp/pull/335

TODO

下記タスクが終わった後にpull requestをready for reviewに変更します。
  • [x] print文の翻訳
  • [ ] #335 を含めて最終更新日の更新
  • [ ] self reivew
9:48 AM
suggestion print("letters は \(letters.count) 個の要素を持つ Set<Character> 型です。")
9:54 AM
意訳しました。 「いい足で起き上がる」だと意味が通じないので。 FunkといえばJames BrownのOn The Good Footなので、それがわかるようにしました。 https://www.youtube.com/watch?v=VgGwI12zMJg
Avatar
suggestion print("ただ今 \(customerProvider()) を接客中!") servingは[飲食物を人]に配るという意味だから、 customersInLine に合った訳は「接客中」のほうがいいかもしれない
Avatar
手動でやるのは、面倒だし忘れる。変更があったら自動で更新できないか検討する。
11:05 AM
[self review] 意訳しています。 an axis を「ある軸上」と訳すよりは具体的な軸に言及したほうがわかりやすいかなと思いました。
12:22 PM
他の箇所で「Hello」を「こんにちは」で訳したので、ここは訳しました
12:25 PM
原文は以下のようです。 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の英文が抜けていたので、翻訳は原文を参照しました。
12:27 PM
原文は以下です。 https://docs.swift.org/swift-book/LanguageGuide/Generics.html 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の情報が現状抜け落ちていたので補いました
12:29 PM
line 210で「オートマ車」の単語を使いたかったので、ここで初出させました。
Avatar
この文脈だと xxx演算子 と訳すのが良さそうですね。 候補は下記がありそうですが、どれもググって正式に使われているシーンがちゃんと見つけられないです・・・
  • アイデンティティ演算子
  • 恒等演算子
  • 同値演算子
JaveScriptでは下記の日本語がよくヒットするようです。
  • 等値演算子(Equality operator)
  • 同値演算子(Identity operator)
c.f. https://so-zou.jp/web-app/tech/programming/javascript/grammar/operator/equality-identity.htm
Avatar
集められたという表現がややわかりづらいかなあと思いました。配列には今何個のprovider があります的なニュアンスを上手く表現したいですね。 print("\(customerProviders.count) 個のクロージャーが保持されています。")
7:30 PM
空港の一覧みたいなものがあるんですかね?airports も翻訳した方が良いかなあと思いました。 print("空港辞書には \(airports.count) 個のアイテムがあります。")
7:30 PM
関数名がsayHelloWorldなのでhelloままでも良いかもしれないですね。
6:22 AM
わかりやすくなったと思います。 保持されています良いと思います
6:36 AM
airports も翻訳した方が良いかなあと思いました。
この 「辞書リテラルを使った辞書の作成」章は 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#...
6:51 AM
「辞書(Dictionaries)」はずっと最初に 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/空港 辞書」で説明したところがいきなり「辞書」だけになると読者も同じものを指しているかが分かりくくなるかなと思いました。
6:53 AM
7:24 AM
あー、すいませんこれは完全に僕の勘違いですね🙇🏻‍♂️airportsのままで大丈夫です!
7:28 AM
すいません誤字の修正とちょっとだけ変えてみました🙇🏻‍♂️ suggestion print("予期せぬ自動販売機とは関係ないエラーが発生: \(error)")
5:21 AM
suggestion 上記の例では、`approximateCount` が `switch` 文で評価されています。それぞれのケースでは、1 つの数値または範囲で比較しています。`approximateCount` の値は、12 から 100 の間にあるので、`naturalCount` には `"数多くある"` という値が代入されます。実行後は `switch` 文から抜け出します。
Avatar
https://github.com/stzn/the-swift-programming-language-jp/pull/326#discussion_r931985009 ここで書きましたが、〜である〜と書きたい所を〜な〜と書いている箇所が散見されます。 textlint-rule-no-mix-dearu-desumasuのREADMEによると、オプションでstrict: falseと設定することで文中の〜である〜が弾かれなくなるようです。 問題なさそうならこの設定に変えても良いのではないでしょうか。
7:31 AM
箇所が散見されます。
こちらはtextlintのエラーが出ているということでしょうか? 全然変更大丈夫です。煩わしい設定をしていてごめんなさい。
Avatar
他で修正いただいた内容と合わせると、「一致する」という表現を使った方が良いかなと思いました。あと同じ表現が繰り返されていたので省略してみました。 これらの要件を定義するために、`Container` プロトコルは、コンテナが保持する要素の型を参照する必要がありますが、特定のコンテナでその型が何なのかを知る必要はありません。`Container` プロトコルは、`append(_:)` メソッドに渡される値の型、およびサブスクリプトによって返される値の型とコンテナの要素の型を一致することを要求します。
4:42 AM
@t-ae さん、提案いただいた修正、問題なさそうなのでそのまま取り込みました。 レビューお願いします
Avatar
LGTMです👍🏻ありがとうございます!何もなければ今日中にマージします。
3:00 AM
suggestion Swift の型推論のおかげで、`IntStack` の定義の中で `Item` が `Int` であることを宣言する必要は実際はありません。`IntStack` は `Container` プロトコルの全ての要件に準拠しているため、`append(_:)` メソッドの `item` パラメータの型とサブスクリプトの戻り値の型から、使用する適切な `Item` を推論できます。実際、上記のコードから `typealias Item = Int` 行を削除しても、`Item` に使用する型が明確になっているため、全てが引き続き機能します。
Avatar
あまり意識していなかったので混ざっている可能性がかなり高い。 parameter(パラメータ):関数の定義内の変数 argument(引数):関数に実際に渡される値
Avatar
計算科学だと日本語で仮引数と実引数とも言いますね。 実際に渡す、でも良いですが、関数呼び出し式の引数部分に書く値、と書くと捉えやすいと思います。
Avatar
ありがとうございますmm 調べた時に、最初に「仮引数」と「実引数」が出てきたのですが、言語ガイドを読んだ人に伝わるかなと思ったのと、「パラメータ」と「引数」もよく使われていたのでこっちの方が良いかと思いました。(ここはご意見をお伺いして検討していきたいです)
関数呼び出し式の引数部分に書く値
これわかりやすくて良いですね!ありがとうございます!
Avatar
細かい改善です。 Reference cycle の翻訳として循環参照と参照循環が混在しており、前者のほうが一般的なのでそちらに統一しました。
6:48 AM
原文:
You can mark an optional reference to a class as unowned. In terms of the ARC ownership model, an unowned optional reference and a weak reference can both be used in the same contexts. The difference is that when you use an unowned optional reference, you’re responsible for making sure it always refers to a valid object or is set to nil.
意訳っぽくなってしまいましたが、文意が間違っていないか確認していただきたいです。
Avatar
「がある」「があり」が続いているのがちょっと気になったので、以下のようにしてみましたが、どうでしょうか?「自分で」はわかるのでいらないようなきがしました。 suggestion Swift は、不要になったインスタンスのメモリへの割り当てを自動的に解除して、リソースを解放します。[Automatic Reference Counting\(自動参照カウント\)](automatic-reference-counting.md)で説明されているように、自動参照カウント\(ARC\)を通じてインスタンスのメモリを管理します。通常、インスタンスが解放されるときに手動でクリーンアップを実行する必要はありません。ただし、独自のリソースを取り扱っている場合は、追加のクリーンアップが必要になる場合があります。例えば、ファイルを開いてデータを書き込むカスタムクラスを作成する場合、クラスのインスタンスを解放する前にファイルを閉じる必要があります。
Avatar
「維持する」というよりも「確認する」の方が近いのかなと思いました。 suggestion クラスへのオプショナルの参照を `unowned` とマークできます。ARC 所有権モデルの観点から言うと、オプショナルの非所有参照と弱参照は共に同じコンテキストで使用できます。弱参照との違いは、オプショナルの非所有参照を使用する場合、それが有効なオブジェクトを参照しているか、`nil` が設定されているか、どちらの状態であるかを常に確認する責任が自分にあることです。
6:48 PM
ありがとうございます!Reference cycleをREADMEの英和対応表にも追加していただけると嬉しいですmm
12:03 AM
確認するというのはmake sureの日本語訳の候補の一つですが、実際の所unownedな変数が有効なオブジェクトを指しているかどうかを確認する方法ってあるんですっけ?(実際アクセスしてクラッシュさせるのは除く) そもそもweak変数がオブジェクト開放時にnilになる=有効なオブジェクトを指さなくなったことを容易に確認できる機能なので、optional unownedでも確認が必要ならweakにすればいいのでは?という話になってしまい、この文章の主張しているweakとunownedの差異について正しく伝えられないと思います。 unownedは存在チェックをするようなものではなく、指しているオブジェクトが開放されるタイミングまでにその参照を外すことをユーザーに要求し、どのタイミングでアクセスしてもクラッシュしない状態を維持することの責任はユーザーにある、というのがこの文章の意図だと私は解釈しています。 making sureの翻訳的には、これを意図しています。 https://ejje.weblio.jp/content/make+sure
(5) 必...
12:20 AM
確かに確認はできないですね。どちらかと「自分の中で確信を持つ」みたいな感じの意図にしたいなと考えてました。「nilを維持する」というのがどうもしっくりこないと思いましたが、「クラッシュしない状態を維持する責任が自分にある」とするとわかりやすいですね。 こうするとどうでしょうか? suggestion クラスへのオプショナルの参照を `unowned` とマークできます。ARC 所有権モデルの観点から言うと、オプショナルの非所有参照と弱参照は共に同じコンテキストで使用できます。弱参照との違いは、オプショナルの非所有参照を使用する場合、それが有効なオブジェクトを参照しているか、`nil` が設定されているか、クラッシュしない状態を維持する責任は常に自分にあります。
12:30 AM
suggestion クラスへのオプショナルの参照を `unowned` とマークできます。ARC 所有権モデルの観点から言うと、オプショナルの非所有参照と弱参照は共に同じコンテキストで使用できます。弱参照との違いは、オプショナルの非所有参照を使用する場合、いつアクセスしてもクラッシュしないように、それが有効なオブジェクトを参照しているか、`nil` が設定されているか、常にどちらかの状態を維持する責任があることです。 クラッシュしない状態を入れるならこちらのほうが分かりやすいかなと思います。
Avatar
制御文字が混入している箇所がいくつかあったので削除しました。 以後混入を検出できるようにtextlint-rule-no-invalid-control-characterを導入しました。 もともとtextlint-rule-detect-bad-charsが導入されていましたが、これはバックスペースしか検出しないようなので、完全に包含されるため削除しました。
Avatar
We’re happy to announce that "The Swift Programming Language" book is now an open source project. This new project will be the basis of publishing the book on Swift.org in the future (more details below), and will use the open source DocC tool. We’re excited to work with the Documentation Workgroup to take the project forward. We ask that you t...
👀 2
Avatar
ここにあるファイルと同じことすれば、DocC対応できるんですかね?(あやふや) https://github.com/apple/swift-book/tree/main/Sources/TSPL/TSPL.docc
The Swift Programming Language book. Contribute to apple/swift-book development by creating an account on GitHub.
Avatar
そろそろSwift5.7が来そうな感じですね👍🏻 https://github.com/apple/swift-org-website/pull/132
The content in this post has been gathered from various people who have contributed to Swift 5.7. All feedback is welcome!
swift 6
Avatar
Document Historyの日付が更新されていましたが、内容は変わっていないので、地道に変わったところを探していくしかなさそうですね😅 https://docs.swift.org/swift-book/RevisionHistory/RevisionHistory.html
Avatar
と思ったらもしかしたらまだ内容変わってないっぽいですね。
Avatar
こちらを追っていけばどこが更新されていったかがわかるので、更新箇所を見つけやすくなりましたね👏🏻 https://github.com/apple/swift-book (edited)
The Swift Programming Language book. Contribute to apple/swift-book development by creating an account on GitHub.
Avatar
Closes #368 辞書の説明に、配列の説明が混じっていました。 原文では存在していないことを確認しました。
6:23 PM
原文から欠けている・typoなどの修正を行いました。 Closes #373
Avatar
suggestion プロパティラッパを用いることで、複数のプロパティの get や set のためのコードを再利用できます。 他と合わせてひらがながよいかなと思います。
7:01 PM
ありがとうございます!二箇所だけコメントさせていただきましたmm
7:01 PM
suggestion タスクは、プログラムを分離された同時並行処理の断片に分割するために使用できます。タスクは互いに分離されているので同時並行に実行しても安全ですが、タスク間で何らかの情報を共有したい場合もあります。アクター\(_actors_\)を使用すると、同時並行処理をするコード間で安全に情報を共有することができます。 ありがとうございます。いくつか細かい提案です。
Avatar
指摘ありがとうございます! 了解です、そのまま取り込みました。
7:12 PM
LGTMです👍🏻ありがとうございますmm 他の方から何かご意見があるかもしれないので、明日まで待って何もなければこのままマージします!
Avatar
Swift 初心者として読み進めた中で、一回では腑に落ちなかった箇所について原文にあたりながら訳文を練ってみました。
1:18 PM
これは読み進めた中で書きためた、個人的な好き嫌いの範囲に入るような変更の提案です。 修正・却下など、見ていただけるとうれしいです。 Closes #378
5:37 PM
ありがとうございます。statementは「文」と一貫して訳しているため、ここだけ変更しても大丈夫でしょうか?(一部ステートメントが使われていますが、それは表記揺れなので修正する必要があるかなと思ってますmm) suggestion Swift は、これらの概念を単一のプロパティ宣言に統合しました。Swift のプロパティには対応するインスタンス変数がなく、プロパティの保存領域に直接アクセスされることはありません。このアプローチにより、様々なコンテキストから値にアクセスされてしまうことで起きる混乱を回避し、プロパティの宣言方法を単一の明確な文に単純化します。名前、型、メモリ管理の特性など、プロパティに関する全ての情報は、型の定義の一部として 1 つの場所に集約されています。
Avatar
レビューありがとうございます! 了解です。指摘された内容をコミットしました。
Avatar
LGTMです!ありがとうございますmm明日まで待って他にご意見なければマージします。
7:53 PM
ごめんなさい。バタバタしていてマージするのを失念していましたmm ありがとうございました!
Avatar
単語の使い方や書き方のルールが載っているページ。これを翻訳してこのルールに応じる形にしていきたい。 https://github.com/apple/swift-book/blob/main/Style.md
Avatar
Avatar
GitHub
Click to see attachment 🖼️
typo修正済 Style.mdh -> Style.md
8:18 PM
suggestion 最終更新日: 2022/11/25 原文: https://github.com/apple/swift-book/blob/main/Style.md
Avatar
suggestion プロトコルにオプショナルの要件を定義できます。これらの要件は、プロトコルに準拠する型によって実装される必要はありません。オプショナルの要件には、プロトコルの定義の一部として `optional` 修飾子が付けられます。Objective-C と相互運用するコードを作成できるように、オプショナルの要件が利用可能です。プロトコルとオプショナルの要件の両方が `@objc` 属性でマークされている必要があります。`@objc` プロトコルは、構造体や列挙型で準拠することはできず、クラスでのみ準拠できることに注目してください。 もう少しシンプルにできるかなーと思いましたが、どうでしょうか?
11:32 AM
ありがとうございます!ほぼLGTMです👍🏻1点だけ細かい提案があります。
Avatar
公式の言語ガイドがSwift5.8でDocC対応版をリリースする模様。それに合わせてDocC対応を進めたい(詳細は何も決まっていないので検討して追記する) やるとした場合、別ブランチで対応を進めていくのが良いのかなと。
Avatar
https://docs.swift.org/swift-book/ReferenceManual/Expressions.html#ID393 Writing throws or async in a closure expression explicitly marks a closure as throwing or asynchronous. { (parameters) async throws -> return type in statements } If the body of a closure includes a try expression, the closure is understood to be throwing. Likewise, if it includes an await expression, it’s understood to be asynchronous.
6:54 PM
Avatar
ありがとうございます!LGTMです。 他にご意見なければ明日マージします。
Avatar
現在このBranch検討中 https://github.com/stzn/the-swift-programming-language-jp/tree/docc 残りの課題:
  • [ ] DocCの不具合で日本語のAnchorリンクがうまく動作しない。https://github.com/apple/swift-docc/issues/458 修正後Anchorリンクを<doc:>形式にする
    • [ ] (優先度は高くない)doccコマンドを試してみたがうまくいかない。調べて導入方法を検討する
Avatar
ご意見なさそうなので一旦マージします。もしあれば別のPRなどでお願いします。
11:08 AM
ご意見なさそうなので一旦マージします。もしあれば別のPRなどでお願いします。
Avatar
PRが作成されてマージされたら反映していこうと思います。現状を把握するために先にissueを作成しました。 https://forums.swift.org/t/tspl-pitch-macros-and-parameter-packs/64339
7:24 PM
PRが作成されてマージされたら反映していこうと思います。現状を把握するために先にissueを作成しました。 https://forums.swift.org/t/tspl-pitch-macros-and-parameter-packs/64339
Avatar
冒頭のNoteにある以下のファイルへのリンクが404になっています。 Noteの項目は原文には存在しないのでどういう対応をすべきかわからないのですが、削除してしまってもいいのでは?と思っています。 適切な対応に誘導してもらえれば私が対応します。
Avatar
ありがとうございます!原文から消えていたことに気がついていませんでしたmm おっしゃる通り、NOTEの部分を丸ごと削除していただけるとうれしいですmm
NOTE より理解を深めるために、Xcode でこのチャプターを開いて遊んでみましょう。Playgrounds を使用すると、コードを編集して結果をすぐに確認することができます。 Download Playground
4:34 AM
原文に合わせた変更をしたい
  • コードの記載を画像からMarkdown方式に変更
  • Grammar of a ...の記述を原文の方法に合わせる
4:46 AM
原文に変更が入ったため、こちらの記載方法が新しくなっています。 他の箇所の記載に関しては、別のissueで対応します。 https://github.com/stzn/the-swift-programming-language-jp/issues/421
8:18 AM
suggestion プロトコルの名前は、他の名前が付いた型と同じように使用することができます。例えば、同じ 1 つのプロトコルに準拠した異なる型のオブジェクトのコレクションを作成することができます。ボックス化されたプロトコル型の値をそのまま扱っている場合、プロトコルの外側で定義されたメソッドを使用することはできません。
8:18 AM
suggestion * [Opaque 型とボックス化されたプロトコル型\(Opaque Types and Boxed Types\)](language-guide/opaque-types.md)
8:18 AM
suggestion プロトコルをジェネリック制約として使用することについては、[ジェネリクス\(Generics\)](../language-guide/generics.md)を参照してください。Opaque 型とボックス化されたプロトコル型については、[Opaque 型とボックス化されたプロトコル型\(Opaque Types and Boxed Types\)](language-guide/opaque-types.md)を参照してください。
Avatar
一定期間経過したのでマージします。修正など必要があれば別PRで対応します。
Avatar
他の修正と重複しているところがあるので一旦マージします。修正など必要があれば別PRで対応します。
6:38 AM
全体的に
  • コードの記載を画像からMarkdown方式に変更
  • Grammar of a ...の記述を原文の方法に合わせる
7:23 PM
一定期間経過したのでマージします。修正など必要があれば別PRで対応します。
Avatar
The Swift Programming Language(日本語版)を公式に合わせてSwift5.9(Beta)に更新しました。 主な更新内容は
  • if/switch式
  • マクロ
  • Box型プロトコル(any) (Swift5.8から)
  • ResultBuilderのbuildPartialBlock (Swift 5.7から)
詳細は各リンクをご参照くださいmm https://www.swiftlangjp.com/revision-history/document-revision-history.html ご指摘などございましたらPRやGIthubのissueを作成していただけるとうれしいですmm parameter packsなどまだないものもあるので、引き続き公式に合わせて更新を続けていきます!
👍 4
Avatar
どうなるかわからないので、Betaが終わるまで様子見でもよいかもしれません。 https://github.com/apple/swift-book/pull/156
Avatar
Closes #439, closes #440, closes #438, closes #437, closes #436, closes #435, closes #434, closes #432
11:25 PM
DocCの不具合で日本語のAnchorリンクがうまく動作しない。
これが入れば対処できそう https://github.com/apple/swift-docc/issues/345
11:27 PM
(優先度は高くない)doccコマンドを試してみたがうまくいかない。調べて導入方法を検討する
READMEの説明の改善がされて解決 https://github.com/apple/swift-book/blob/main/README.md#building
Avatar
Optional syntactic categories and literals are marked by a trailing question mark, ?.
必須ではない構文カテゴリとリテラルは、末尾に添字 opt がマークされます
optではなくクエスチョンマーク。
Literal words and punctuation
単語リテラルと句読点は、
変更ではないが、この場合のPunctuationは記号も含むので、 (参考) Oxford Style Guide https://www.ox.ac.uk/sites/files/oxford/media_wysiwyg/University%20of%20Oxford%20Style%20Guide.pdf Microsoft Style Guide https://learn.microsoft.com/en-us/style-guide/punctuation/ など、上記によるとPunctuationは各種カッコやハイフン、ビックリマーク、ク...
Avatar
Optional syntactic categories and literals are marked by a trailing question mark, ?.
必須ではない構文カテゴリとリテラルは、末尾に添字 opt がマークされます
optではなくクエスチョンマーク。
Literal words and punctuation
単語リテラルと句読点は、
変更ではないが、この場合のPunctuationは記号も含むので、 (参考) Oxford Style Guide https://www.ox.ac.uk/sites/files/oxford/media_wysiwyg/University%20of%20Oxford%20Style%20Guide.pdf Microsoft Style Guide https://learn.microsoft.com/en-us/style-guide/punctuation/ など、上記によるとPunctuationは各種カッコやハイフン、ビックリマーク、ク...
9:01 AM
代替案が長すぎて簡単に読めない場合、
簡単に読めない、は読みにくいが自然だと思いました。 また、それらは、というのは英語的で日本語では訳さないほうが自然に見えると思います。
9:47 AM
ありがとうございます。原文に合わせてクエスチョンマークをイタリック体に変更させてください。 <img width="712" alt="スクリーンショット 2023-08-18 18 46 43" src="https://github.com/stzn/the-swift-programming-language-jp/assets/35151927/c78f3306-7dd4-43ff-9895-1a3670f6b01d"> suggestion * 必須ではない構文カテゴリとリテラルは、末尾にクエスチョンマーク_?_が付加されます
9:47 AM
ありがとうございます。 太字の 等幅フォント は原文に合わせて↓に変更させてください。 <img width="978" alt="スクリーンショット 2023-08-18 18 45 13" src="https://github.com/stzn/the-swift-programming-language-jp/assets/35151927/2618a632-784d-4002-a89b-1883319cef5e"> suggestion * 単語リテラルと句読点は、**太字の等幅フォント**で示され、文法生成規則の右側にのみ現れます
Avatar
アンダースコアの前後にスペースがないため、多くのMarkdownの装飾が無効になっていて、アンダースコアがそのまま表示されています。
11:31 AM
アンダースコアの前後にスペースがないため、多くのMarkdownの装飾が無効になっていて、アンダースコアがそのまま表示されている表示上の問題を修正。 Closes #452
5:11 PM
ごめんなさい僕がスペース空け忘れてました🙇‍♂️ * 必須ではない構文カテゴリとリテラルは、末尾にクエスチョンマーク _?_ が付加されます
Avatar
まだマージされていないようですが、取り組んでもいいですか?
Avatar

問題の箇所

以下の場所で参照箇所の表記にズレがありました。何か意図があってこの表記にしているのであれば、解説をいただきたいです。 https://github.com/stzn/the-swift-programming-language-jp/blob/2b4d9ee290352719e00682fe70807e04bcef7000/language-guide/control-flow.md?plain=1#L341 問題ページ

修正案

以下のような表記が良いと考えます。 ```diff markdown + 使用できるため、 [型注釈(Type ...
2:19 AM
@TonTonbow さん ご指摘ありがとうございます。
何か意図があってこの表記にしているのであれば、解説をいただきたいです。
ただの間違いです。DocC対応を試している際に混入してしまったようです。大変申し訳ございませんmm 修正案の通りでよいと思います。
Avatar
Closes #456

変更内容

  • doc:TheBasics#Type-Annotationsの削除

変更によって期待されること

  • 文章に一貫性が生まれる
Avatar
コメントアウトされているテストコードはレガシーなもので今は動いていないので、追加しなくて大丈夫です!書いていただいたのに申し訳ないですmm 今後何か対策をするようなので、対応はその時にまとめてやろうと思ってます。まず日本語版もDocC対応しないといけなさそうですが😅 https://github.com/apple/swift-book/issues/5
10:40 AM
他に合わせて同時並行がよいかなと思いました。 同時並行コードを構造化するために、タスクグループ\(_task group_\)を使います。
10:40 AM
ありがとうございます!ほぼLGTMです!2点細かいコメントをしています。
Avatar
LGTMです。ありがとうございます! 原文の方に変更が入るかもしれないので、原文がマージされてからこちらもマージしたいと思います。
Avatar
急ぎでなければ、このissueを引き受けたいです。(誰もこのissueを引き受けていなければ。)
Avatar
ありがとうございます!よろしくお願いします! 作業を始める際はまずアサインすることになっているので、されていなければ大丈夫です🙆
1:11 AM
改善案:「nilの値を伝播させるには、nilを返すか、?を使用します。?演算子については[Optional Chaing]を参照してください。」
1:11 AM
ここの表現は以下のように編集します。 txt `??`を使用してフォールバック値を提供する方法の詳細については、[Nil-Coalescing-Operator\( `nil` 合体演算子\)]()を参照してください。
Avatar
ありがとうございます! すいません、ちょっと今週末は見る時間がないと思いますので少々お待ちくださいmm
Avatar
いつでも大丈夫です! 事情は重々承知しております。 自分もiOSDC参加組なので 変な気を使わせてしまい申し訳ありません 🙇
Avatar
ありがとうございます。ほとんどLGTMです。 一部細かいコメントをしています。主に既存の記載でも表記ゆれの問題があり、それに関する修正です。(「オプショナル」「オプショナルの値」を「オプショナル値」に統一など) ここら辺の表現方法は悩んでいるところもあるので、もしご意見あればいただけると嬉しいですmm
1:16 PM
「を」のほうがよいかなと思いました。 suggestion 冠詞を省略してください。"use an optional binding"ではなく、"use optional binding"を使用してください。
1:16 PM
1:16 PM
ditto suggestion このオプショナルと非オプショナル値を区別することで、どの情報が欠如しているか明示的にマークすることができ、欠如している値を取り扱うコードを書くのが簡単になります。オプショナルを非オプショナルとして誤って扱うことはできません。なぜなら、このようなミスはコンパイル時にエラーを生成するからです。値をアンラップした後、その値を利用する他のコードは `nil` のチェックをする必要がなくなるため、コードの異なる部分で同じ値を何度もチェックする必要がありません。
1:16 PM
ちょっとこの機会に表記ゆれを直したいと思いまして、「オプショナルの値」を「オプショナル値」にしようかなと思いましたがどうでしょうか? suggestion この種のコードはとても一般的で、短いスペルを使用してオプショナル値をアンラップできます。アンラップする定数または変数の名前だけを記述します。ラップされていない新しい定数または変数は、オプショナル値と同じ名前を暗黙的に使用します。
1:16 PM
ditto suggestion オプショナル値にアクセスするとき、コードは常に `nil` の場合と非 `nil` の場合の両方を処理します。値が欠如しているときにできるいくつかのことがあり、次のセクションで説明されています。
Avatar
「オプショナルの値」を「オプショナル値」にしようかなと思いましたがどうでしょうか?
問題ないと思います! しかし、「オプショナルの値」と表記されている箇所が何点か見受けられます。 これは後に変更が加えられたら修正するという方針でしょうか? それとも、新しくIssueを立てて、編集する感じですか?

参考

https://github.com/stzn/the-swift-programming-language-jp/blob/b9e0d15e18c8e9197a72f31d3bef501cf249ae8a/language-guide/generics.md?plain=1#L217 https://github.com/stzn/the-swift-programming-language-jp/blob/b9e0d15e18c8e9197a72f31d3bef501cf249ae8a/language-guide/generics.md?plain=1#L281 https://github.com/stzn/the-swift-...
Avatar
@stzn 編集完了したので、確認お願いします 🙇 また、コメントも1つ追加しました。
Avatar
@TonTonbow さん 修正ありがとうございます!
しかし、「オプショナルの値」と表記されている箇所が何点か見受けられます。 これは後に変更が加えられたら修正するという方針でしょうか? それとも、新しくIssueを立てて、編集する感じですか?
別で対応しようかと思っていたのですが、このOptionalに関するものですし、できればまとめて直していただけるとありがたいです🙇🏻‍♂️
Avatar
@stzn わかりました🫡 一旦、draftした方が良さそうですかね?
12:05 PM
@TonTonbow さん ありがとうございます! いえ、このまま続けていただいて大丈夫ですー。
Avatar
原文の方がマージされたのでこちらもマージします。ありがとうございました!
11:46 PM
https://github.com/apple/swift-book/pull/181 ※ DocC対応はまだ行なっていないため、以下のようなDocC表記のものはタグを使う必要があります。 swift ; ``
Avatar
  • 初期化(Initialization)ページのタイポの修正。
    • (誤)covenience
    • (正)convenience
12:11 PM
Closes #468 初期化(Initialization)ページのタイポを修正しました。
Avatar
原文では
- The AST passed to a macro implementation contains only the AST elements that represent the macro, not any of the code that comes before or after it. - The macro implementation runs in a sandboxed environment that prevents it from accessing the file system or the network.
となっている部分が、日本語訳では
- マクロの実装に渡される AST は、マクロを表す AST 要素のみを含み、その前後に来るコードは一切含まれない - マクロ実装に渡される AST は、マクロを表す AST 要素のみを含み、その前後のコードは一切含まれない。マクロ実装は、ファイルシステムやネットワークにアクセスできないサンドボックス環境
となっています。 原文と異なり、2文目の冒頭が1文目と内...
Avatar
@stzn 遅くなりました💦 修正したので確認お願いします!

変更内容

1. ”optional value” を全て「オプショナル値」に編集しました。 2. 一部、"non-optional value" は「非オプショナル値」に修正しました。 3. "optional value" が原本にはあるのに記載がない箇所は、文全体を修正しました:3c950db, cc06e33
Avatar
ありがとうございます! いくつか追加したいところがあったのでコメントしています。お時間のある時にご確認ください🙇🏻‍♂️(全然急がなくて大丈夫です!)
9:40 AM
すいません既存ですがここの「値」は不要かなと思ったので削除したいです🙇🏻‍♂️ suggestion > Any 型は、オプショナルの型を含む任意の型の値を表します。`Any` 型の値が期待されているところにオプショナル値を使用すると、Swift は警告を出します。本当にオプショナル値を `Any` として使用する必要がある場合は、下記に示すように、`as` 演算子を使用して、オプショナルを `Any` に明示的にキャストします。
9:40 AM
suggestion オプショナルチェーンが `nil` 値で呼び出される可能性があるということを反映するために、照会しているプロパティ、メソッド、またはサブスクリプトが非オプショナル値を返した場合でも、オプショナルチェーンの呼び出しの結果は、常にオプショナル値になります。このオプショナルの戻り値を使用して、オプショナルチェーンが成功したか\(返されたオプショナル値に値が含まれているか\)、`nil` が存在して失敗したか\(返されたオプショナル値が `nil` か\)を確認できます。
9:40 AM
suggestion `nil` ではない場合に呼び出したいオプショナル値のプロパティ、メソッド、またはサブスクリプトの後に疑問符\(`?`\)を配置して、オプショナルチェーンを指定します。これは、オプショナル値の後に感嘆符\(`!`\)を配置して、その値を強制アンラップするのによく似ています。主な違いは、オプショナル値が `nil` の場合、オプショナルチェーンが失敗するのに対し、強制アンラップは実行時エラーを引き起こすことです。
9:40 AM
suggestion このコードは、前の例のコードと同様に、`myNumber` に値が含まれているかどうかを確認することから始まります。`myNumber` に値がある場合、`myNumber` という名前の新しい定数の値がその値に設定されます。`if` 文の本文内では、`myNumber` は新しい非オプショナルの定数が参照されます。`if` 文の前後で `myNumber` を使うと、元のオプショナルの定数 `Int` が参照されます。
Avatar
@stzn ありがとうございます。 編集したので、確認お願いします 🙇
Avatar
色々とご対応ありがとうございます! 最後に既存のコードでいくつか修正したいところがあったので提案をしています🙇🏻‍♂️ そこに問題なければ取り込んでください。その後マージします。
7:46 PM
suggestion 以下で定義される `Counter` クラスには、`CounterDataSource?` 型のオプショナル値の `dataSource` プロパティがあります:
7:46 PM
suggestion _オプショナルチェーン_は、`nil` になる可能性のあるオプショナルのプロパティ、メソッド、およびサブスクリプトを照会して呼び出すためのプロセスです。オプショナル値に値が含まれている場合、プロパティ、メソッド、またはサブスクリプトの呼び出しは成功します。オプショナル値が `nil` の場合、プロパティ、メソッド、またはサブスクリプトの呼び出しは `nil` を返します。複数を一気にチェーンさせることができ、ある地点で `nil` が返ってきた場合、オプショナルチェーン全体が失敗します。
7:46 PM
suggestion オプショナル値が値を含んでいる場合、`nil` と「等しくない」と見なされます。
7:46 PM
suggestion 次は、`findIndex(of:in:)` と呼ばれる、`findIndex(ofString:in:)` のジェネリックバージョンを示しています。この関数は配列のオプショナル値ではなく、オプショナル値のインデックスを返すため、この関数の戻り値の型は引き続き `Int?` であることに注目してください。ただし、次の例の後に説明する理由により、この関数はコンパイルできないことに注意してください:
Avatar
素晴らしいドキュメントをありがとうございます。 サイト全体をレスポンシブ対応していただけないかと思い、Issueを立てました。 閲覧する端末がスマホの場合、文章が画面の外まで伸びでしまっているため、常に画面を左右にスライドされなければならず、読みづらさがあります。
Avatar
ご連絡ありがとうございます。 honkitというフレームワークを使っているのですが、そこでどう対応できるか調べてみます(もしくはどなたか調べていただける方がいれば嬉しいです。) すぐには対応できないと思いますのでお待ちいただけましたら幸いですmm よろしくお願いします。
Avatar
色々とご対応ありがとうございます! 最後に既存のコードでいくつか修正したいところがあったので提案をしています🙇🏻‍♂️ そこに問題なければ取り込んでください。その後マージします。
Avatar
@stzn すみません。確認お願いします 🙇 9331a3fは取り入れようとしたら間違ったボタン(Add Suggetion batch)を押してしまいました💦
Avatar
ありがとうございます!大丈夫だと思うのでマージしますね!
10:51 PM
@tez3998 san ありがとうございます!見ていただけると助かります🙇🏻‍♂️
Avatar
Closes #476 スマートフォンの画面幅にも対応するために変更を加えました。 下記のデモ動画では、iPhone SEの画面幅での動作を確認しています(動画27秒あたりからiPhone SEの画面幅になります)。 https://github.com/stzn/the-swift-programming-language-jp/assets/90051826/668e7e1e-5ddc-4f2a-98fc-6449d260d1f6
Avatar
ありがとうございます! webサイト用のcssを指定すればよかったのですね。 とても助かりました🙂
Avatar
@stzn さん さっそくデプロイしていただきありがとうございます! これで通勤中のSwiftの学習も進みそうです!
1:07 AM
すいません。だいぶ昔の話になってしまったのですが...w ここは「同値演算子」でいきたいと思います。もしご意見ございましたら教えてくださいmm
5:06 AM
@NiwakaDev さん お疲れ様です! こちらですが、もう始められていますでしょうか? もしまだでしたら僕の方でやろうと思っています🙂
5:08 AM
@KaitoMuraoka さん お疲れ様です! こちらですが、もう始められていますでしょうか? もしまだでしたら僕の方でやろうと思っています🙂
Avatar
@stzn すみません。対応がもう少しかかりそうなので、Assignees を外していただいても構いません。 🙇 ご迷惑をおかけして、申し訳ないです 🙇
Avatar
いえいえー。そうしましたら一旦僕の方で引き取りますね! ありがとうございます!
Avatar
修正ありがとうございます! 何点か確認させてください。
7:24 PM
こちらも原文の↓に対応するのかなと思います。 Note: To check whether a task has been canceled from outside that task, use the Task.isCancelled instance property instead of the type property. https://github.com/apple/swift-book/blob/main/TSPL.docc/LanguageGuide/Concurrency.md#task-cancellation
7:24 PM
ここは原文の After each call to addTaskUnlessCancelled(priority:operation:), the code confirms that the new child task was added. If the group is canceled, the value of added is false --- in that case, the code stops trying to download additional photos. 対応する箇所だと思いますが、どうでしょうか? https://github.com/apple/swift-book/blob/main/TSPL.docc/LanguageGuide/Concurrency.md#task-cancellation
Avatar
理解しました。 docs.swift.orgの方は5.10の完成バージョンで そこから次の段階に進んでいるのがgithub.comの方ですね。
Avatar
マクロの名前に付いている #@ は原文に合わせました。
Avatar
ほぼLGTMです。いくつかコメントしました。(個人的に修正したい部分も含めていますmm)
7:06 PM
表記揺れの修正です。 suggestion `attached` 属性は、この宣言で 2 回、各マクロの役割のために 1 回ずつ、現れます。最初の使用である `@attached(member)` は、マクロがそれを適用する型に新しいメンバを追加することを示します。`@OptionSet` マクロは、`OptionSet` プロトコルで必要な `init(rawValue:)` イニシャライザと、いくつかの追加メンバを追加します。2 つ目の使い方である `@attached(extension, conformances: OptionSet)` は、`@OptionSet` が `OptionSet` プロトコルへの準拠を追加することを示しています。`@OptionSet` マクロは、それを適用する型を展開し、`OptionSet` プロトコルに準拠します。
7:06 PM
原文に合わせてリンクをつけました。 あと「走らせて」は「実行して」のほうがよいかなと思いましたがどうでしょうか? suggestion 最初の行で、`#function` は Swift 標準ライブラリから [`function()`](https://developer.apple.com/documentation/swift/function()) マクロを呼び出します。このコードをコンパイルするとき、Swift は、`#function` を現在の関数の名前に置き換えるマクロの実装を呼び出します。このコードを実行して `myFunction()` を呼ぶと、"現在実行中 myFunction()" と表示します。2 行目では、`#warning` は、カスタムコンパイル時の警告を生成するために標準ライブラリから [`warning(_:)`](https://developer.apple.com/documentation/swift/warning(_:)) を呼び出します。
7:06 PM
すいません。僕のミスを修正させてくださいmm suggestion `#fourCharacterCode` マクロは、4 文字の文字列を受け取り、その文字列の ASCII 値を足し合わせた符号なし 32 ビット整数を返します。ファイルフォーマットによっては、コンパクトな一方でデータをデバッガで読めるという理由から、データを識別するためにこのような整数を使用することがあります。以下の[マクロの実装](#マクロの実装)のセクションで、このマクロを実装する方法を示します。
7:06 PM
不要な文言削除させてくださいmm suggestion 上の図は、このコードの構造が、メモリ上でどう表現されるかを示しています。AST の各要素は、ソースコードの一部に対応しています。「定数宣言」 AST 要素には、その下に 2 つの子要素があり、定数宣言の 2 つの部分、つまり名前と値を表しています。「マクロ呼び出し」要素には、マクロの名前とマクロに渡される引数のリストを表す子要素があります。
10:17 PM
Avatar
ほとんどがBox プロトコル型だったので、Box 型、ボックス型プロトコル型、はBox プロトコル型に統一しました。
Avatar
修正ありがとうございます。いくつかコメントしましたので、お手隙の際にご確認くださいmm
7:50 PM
ちょっと訳に違和感のあるところがあったので、変えてみたのですが、こうするとどうでしょうか? suggestion Opaque 型の戻り値を返す関数の中に戻り値を返す場所が複数ある場合、返す可能性のある戻り値は全て同じ型にすることが必要です。ジェネリック関数の場合、その戻り値の型に関数のジェネリック型パラメータを使用できますが、それでも単一の型にする必要があります。例えば、正方形の特殊なケースを含む、形状反転関数の無効なバージョンを次に示します:
7:50 PM
型が抜けていましたmm suggestion ## Opaque 型とBox プロトコル型の違い\(Differences Between Opaque Types and Box Protocol Types\)
7:50 PM
なぜここだけ"Boxed Type"になっているのかが疑問に感じたので、元のリポジトリのほうにPR出して確認していますので、少しお待ちくださいmm https://github.com/apple/swift-book/pull/297
Avatar
This reverts commit 3e7ae1a308ac2f64f36a4a251db6b6b3189629f7, reversing changes made to f8c4c20b98b40bb48c2c8b5550cb9db630e3ba78.
7:35 PM
原文に修正が入ったので、それに合わせましょう! suggestion # Opaque 型とBox プロトロコル型\(Opaque and Boxed Protocol Types\)
Exported 1,093 message(s)
Timezone: UTC+0