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です👍🏻ありがとうございます!何もなければ今日中にマージします。