lean-ja / fp-lean-ja Goto Github PK

@Seasawher

現在の翻訳ルールには

句読点には , . を用いる.

と(半角のカンマとピリオドを使うように)書かれています。
しかし、実際の翻訳の大部分では全角のカンマとピリオドが使われているため、少なくとも現在の句読点ルールは変更が必要だと思われます。
そして、カンマとピリオドの使用には、

• 半角と全角が目視で区別しにくく、混在のおそれが高い。
  (実際に現行の翻訳で混在が生じています。)
• 半角のカンマあるいはピリオドが混入した場合、コメントアウトされた原文にもカンマやピリオドが含まれるために、置換によって一括修正をはかる場合に工夫を要する。

という(単に慣習の違いによらない)デメリットがあると思います。
そこで、

• 少なくとも翻訳作業中は句読点に、と。を用いる
• 翻訳終了時点で、、と。をそれぞれ，と．に一括置換する

とすると、句読点に関するミスを防ぐことができると思います。

ただ、もし可能なら、と。をそのままにしておき、mdbookに(文字列置換による)「句読点切り替えボタン」を実装できれば、よりユーザフレンドリーだと思います。

現行の全翻訳に影響の出る大きなルール変更提案で恐縮ですが、ご一考いただけると幸いです。

「公用文作成の考え方」 を改めて確認したところ，句読点には 、 と 。 を使うのが原則だと書かれていました．（昔はカンマとピリオドだった気がします）

エディタ上でも 、 と 。 の方が判読しやすくて統一しやすいというメリットがあるので，この機に句読点を変更したほうが良いかと思いました．

訳を付けるにあたり、すべての演習問題に解答を用意する

対訳表への変更提案はこちらにお願いします。
提案の際は、

* 提案対象の用語
* 提案内容
* 提案理由

の3つをお書きください。
マージコンフリクトを避けるため、レビュアー以外の方が対訳表にPull Requestを出すことはお控えください。

対訳表への変更提案がある際は、「New issue」ボタンを押した後、issue template「対訳表への変更提案」をお使いください。

原文のライセンスを確認
原文のどのバージョンの訳なのか明記
翻訳は非公式のものであり、lean-jaが管理するものであると明記

現状、「翻訳の際のルール」や「対訳表」がリポジトリのファイルとして管理されていますが、これらを Github の wiki で管理するとよいのではないかと考えました。
参考: ウィキについて - GitHub Docs

メリット

• ルールや対訳表の更新をリポジトリにコミットすることなく素早く更新できる。
  • 例: ある PR で和訳作業中に新規に対訳表に追加したい単語があったとき、別の PR でも同じ単語が出てきた場合に wiki で対訳表を管理すればその単語の扱い方の共有がすぐにできる。

デメリット

• リポジトリだけでなく wiki の管理も発生する。

一章が結構長いので

プレビューするのには mdbook と Lean だけでなく Python も必要で，バージョンも指定しないといけない

クラウド開発環境をセットアップしておくのが良いと思われる

他のリポジトリと同様にできるはず

linter の導入を検討する。

案（上にあるほど優先度高）

1. CI で lint をかける
   • それぞれの環境に linter を導入する手間が省ける
   • コミット後に lint がかかった差分チェックが必要
2. Gitpod で linter が入った環境を作る
   • ローカルで開発環境整える必要がない
   • ブラウザで作業するのがやりやすいかどうかわからない
3. devcontainer で linter が入った環境を作る
   • 開発環境を整える手間が省ける
   • PC のスペックによっては devcontainer の起動が重いのがネック

試してみて使えそうなら導入し、そうでないなら見送る。

String.dropRightWhile は IO アクションではなく，通常の文字列関数であるため，:= ではなく ← を使用しています．

↑ 逆になってませんか？

structure S を定義すると、S.rec も自動生成されている