cocoatomo

Workaround として Google で「site:docs.python.org/ja/2.7 リスト内包表記」や「site:docs.python.org/ja/2 リスト内包表記」といった文言で検索してください.

一般的な話として, issue の文面は起きている問題やどうして欲しいかを整理して書くものとなっています. これまで, そういう形式を明示的には強制はしていなかったのですが, これからは強制するものとしていきたいと思います. これは, issue の作成者以外の人にも問題の内容が分かるようにするためと, issue を閉じる条件を厳密にするためです.

構成案は以下の通り。 1. python-docs-ja への PR をトリガーとして、CI サービスで PR ビルドを走らせ、決まった場所にビルドしたドキュメントを公開する。 2. そのドキュメントを見て確認ができたら、何らかの方法で承認/却下の判断を記録、次の処理へ伝える。 3. 却下の場合は PR にその旨を表示し処理は終了。PR の改善を行い更新することで「1」の手順を起動する。 4. 承認の場合は PR にその旨を表示し、PR のマージを行い、変更のあった .po ファイルを Transifex へアップロードする。 5. 数日待つとドキュメントが docs.python.org に公開される。

主に課題となるのは、レポジトリの認証まわりになる。 1. PRビルドで作成したドキュメントファイルをどうやってpushするか? - 対応策: 秘密鍵をsecretファイルに追加しておく 1. PRおよびPR更新後の承認/却下はどう行う? - 対応策: 承認/却下は普段のPRと同じように行う。 - 対応策: push, PR, PR-Mergeの3パターンで別々の処理を動かす 1. Transifexへのアップロードはどうする? - 対応策: 秘密鍵があるので`tx`コマンドでアップロード - 対応策: git diffで変更があったファイルだけをアップロード

PRビルドをTravis CIという外部のCI/CDサービスで行ったとき、設定してあったsecretが使えない（恐らくsecretが漏れるのを防ぐため）問題に引っ掛かっており、なかなかいい構成方法が思い浮かばなかった。 GitHub Actionが出てきてくれたおかげで一時的なGH_TOKENが扱えるようになり、ビルド後にドキュメントをpython/python-docs-jaのgh-pagesにpushできるようになった。 現在、実装が済んでいるのは、次の機能。 1. PRが出されたときに、そのPRをマージしたソースコードでドキュメントをビルドし、GitHub Pagesに公開する。さらに、PRページドキュメントが公開されている場所のURLをコメントする。 2. PRを閉じたときに、ビルドしたドキュメントを削除する。 次の機能が実装が済んでいない。 3. PRがマージされたときに、ビルドしたドキュメントを削除する。

2019/08/07にcocoatomoがIPAの担当者と電話でやり取りをし、以下について合意。 ※ 免責事項の掲示は翻訳チームのTODOとした - [ ] 免責事項の掲示 - [x] IPAへ、こちらに責任が無いことの確認 - [x] (問題とは直接関係は無いが) ドキュメントのバージョンはどんどん上がっていくことをIPAへ説明

いくつか訳文を修正してみてパターンが見えてきたので, 修正方針と一緒にここに列挙する. * 単なる文法ミス * 正しい文法に直す * 飜訳の都合上, 参照 (term, ref, etc.)の数が食い違うもの (代名詞の展開, 訳注, etc.) * 日本語の文章としては正しいので, 今のところは据え置き * たいていは代名詞を展開したパターンなので, 数が同じになるように該当する部分は参照にしないという方法も考えられる * (おそらく親切のため) 原文には無い term や ref などを追加したもの * 読み手にメリットがありそうなので,...

> * 単なる文法ミス > * 正しい文法に直す ここに関してはだいたい直せました. 文章量は膨大なので, 焦らず少しずつやっていきましょう.

メモ - c:func role - `()` が末尾に追加され見た目が変わり過ぎるのでいったん据え置き, :c:func: を付けたままにする - c:macro role - こちらはフォントが変わる程度なので :c:macro: は外す

https://github.com/python-doc-ja/python-doc-ja/issues/804#event-3490008358 からの派生