エンジニアの知的生産術英語化プロジェクト
エンジニアの知的生産術を英語化するプロジェクト
翻訳完了
(完了=図版内の文言と、文法チェックはまだ)
2022-02-09
翻訳終わったのでページを分けた
ネクストアクション
Scrapbox Readerで読めるようにする
読めるか読めないかで言えば今でも読める
ドメインを確定してincoming linkが無駄にならないようにする
さっさとそれをしないとTweetできないしね
目次を作る
Scrapbox上で、かな？？
次のコンテンツへ、のリンクをつける
Scrapbox上で？
それともReader上で？
「前のページへ」のリンクがコンテンツ冒頭にあって欲しい
ブレッドクラムがあると良い
だけどもこれをScrapboxでやるのはいまいち
6,7章に第4刷に向けての修正差分を反映
6,7章にGrammeryでの文法チェックを掛ける
6,7章の組版
さほど重要ではないがdoneにしてひと段落したい気持ちはある
このプロセスでリンク切れなどの機械的チェックができるメリットも。
加筆したいって原稿がいくつかある
出版社が「ページ数が変わるような変更は入れられない」と断っている
それは英語版の方で勝手に加筆していく
ScrapboxとKeichobotとKozanebaの話を書く
Scrapbox上でのより良いネットワーク構造へ
これは興味ある、ただし完了の定義が不明瞭
明日Keichobotに相談しよう
2022-02-10
ネクストアクション
Scrapbox用の目次を作る
ただし手作業で作るのではなくePub生成スクリプトからフォークして機械的に生成可能にする
Q: スクリプトはどこ？
チャットボット実験リポジトリの中にあった
その配置はどうなんだ、見つけるのに手間取ったぞ
過去にも書いてた
>get_scrapbox/scb2leanpub.pyって名前は微妙 src
チャットボットがScrapboxを読むためのコードを流用してるせいだな
>ページを追加した場合: print_sorted_titles()
うーむ、これはプロジェクト内の直近更新1000件をとってタイトルを辞書順に並べるコード
翻訳が別プロジェクトで行われてた時は全てのページが基本的に書籍収録対象だった
一部だけignore listで無視してる
このプロジェクトにマージしたことで他のものも大量にあるがどうしたものか…
キーワードの解説などのページが問題
まあいいか？(いいのか？)
どっちみちこのプロジェクトにマージしたことで新しく接続されたキーワードがあるはずだし、それはAPIを叩いて内容を取得してenアイコンがついてたら収録ってことで。
>ドメインを確定
あっさりできた
URLにnishioが入るのは冗長だ
他のプロジェクトまで静的ホストの対象にすべきではないし
どうするのがよいか
言語特定情報がなければ英語？言語特定情報がなければ無変換？
機械翻訳はまだ運用に投入できるレベルの実装になってない
オリジナルが英語で書かれてる時にjaが無変換なのもおかしいよな
前後のコンテンツへのナビゲーションの自動付与、できた
とりあえずURLは確定したのでこれをツイートしてGoogleクローラに拾ってもらおう
2022-02-13
NEXTエンジニアの知的生産術つくった
執筆時には紙の付箋を通勤時に書いたりしていたが、新型コロナで通勤しなくなったし、Kozanebaとか作ってんのに今更紙の付箋を使うメリットないだろーということ
通勤の紙の付箋に相当するものは散歩しながらスマホでScrapboxに書き込む、だと思った
ランダムな順番で出力されたまだ構造化されてない断片を散逸させずに溜めておく場所が明示的に必要
これ、直接Kozanebaに入れられるのが理想なきがする
たくさん書き出してから、よっこらしょとKozanebaにインポートするんじゃなくて一旦書き出したら、それを一旦Kozaneba上で整理して、それこらその刺激でさらに思いつく
これは違うかも、早く出てきた付箋は既に構造化されていて、それだけを見て構造を作ると既存の構造の再生産になってしまうかも
可用性バイアス
今はまだスマホから使うのに向いてない、仕方ない
エンジニアの知的生産術 全階層目次に番号がついてないと不便なのでつけ始めた
コラムにも一意な番号があるべきだな
このページは引き続き時間的スキーマでつらつらと書いていく
日本語版の目次も英語版同様に番号をつける
英訳版をScrapbox上で作成する過程で「見出しに一意な番号を振ろう」と考えました。理由:
紙の書籍ではなくデジタルな形だと、ページ番号で参照するのはやりにくい
見出しをタイトルにするのが自然だが「まとめ」などの複数回出現する見出しが存在する
これが便利だったのでこの日本語版の目次も同様にしました
Scrapbox上で言及がある時には青リンクになります
書籍版に含まれてない加筆記事は追加コンテンツとして目次の中に置くことにしました
1.3.3.2
ソースコードを読む
一次元化されてないドキュメントの読解
目次を作り終わったら、このScrapbox上でページ指定で言及してるところにリンクをつけていく
3.1
VRの発展によってマインドパレスを作りやすくなった話
マイクラ上でのこの書籍のマインドパレス
4.1.1.4
一次元化の話、ここで書いてる
4.3.1.3
フォトリーディング
手順通りにはやってないけど、守破離な感じだな
守破離はどこかに入れたい
4.3.2.1かどこかにまず計測の話、書いてたっけ？
> 誰が顧客かわからなければ、何が品質かもわからない 209
> 何を検証すべきかは目的によって異なる 210
日本語では目次に出てるが英語では出ていない
>(7.2.1.1) 探索範囲を広くする
これも英語では出ていない
目次ができたので、このScrapbox上の言及をこの番号を使ったものに変えていく
過程で気になったものメモ
エンジニアの知的生産術では個人一人の知的生産にフォーカスしていた
メリットが追加された形
加筆案をどこに入れるか 2022-02-14
ネクストアクションリスト
✅Scrapbox Readerで読めるようにする
ブレッドクラムがあると良い
6,7章に第4刷に向けての修正差分を反映
6,7章にGrammeryでの文法チェックを掛ける
6,7章の組版
さほど重要ではないがdoneにしてひと段落したい気持ちはある
加筆したいって原稿がいくつかある
ScrapboxとKeichobotとKozanebaの話を書く
NEXTエンジニアの知的生産術にまとめた
Scrapbox上でのより良いネットワーク構造へ
これは興味ある、ただし完了の定義が不明瞭
(追記)複数あるのに「ネクストアクション」と書くのはおかしい気がしたので「ネクストアクションリスト」に書き換えたが、そもそもこれ「アクションリスト」なのでは
2022-02-14
加筆案をどこに入れるか これらが、どこに入れるのか明確でないまま散らばっている
これも番号付き目次を使ったリンクにすると良いのではないか
2022-02-15
Scrapboxの記事は(5.4.3-2) Scrapboxに、かなり簡素に書いてある
著者本人による「エンジニアの知的生産術」のKozanebaがあればいいのではないか。
僕の頭を整理する上でも、読者のためにも、Kozanebaのデモンストレーションとしても。
整理
加筆案をどこに入れるか 断片を適切な位置に配置してこのページは消滅
断片を分配し、目次に出すものは出した
このページはハブとして残した
2022-02-24
Tasks
英訳の過程で書き換えた文章のログを見て、第五版に向けた修正のリストを作る
5章以降にGrammeryで構文チェックをする
memにブレッドクラムをつける
memに宣伝欄をつける
「英訳を優先するために中断」した機械翻訳プロジェクトを再開
✅memにブレッドクラムをつける
✅memに宣伝欄をつける
✅2ホップリンクがない時には見出しを表示しない
✅関連ページを表示しないページを指定できるようにした
コラムはいまのところ前後関係にも階層構造にも参加してない
>「英訳を優先するために中断」した機械翻訳プロジェクトを再開
英語フラグのついているものは翻訳しない
フラグのついてないものに関して
全部翻訳する？
コードリージョンなどを除く？
変更時に全体を再翻訳する？
リンクの訳語指定したい？？
タイトルやリンクが決まらないといけないから事前に翻訳が必要
あるページが表示された時に、それのリンク先に翻訳済みのページと元々英語のページが出なければならない
2022-02-25
価値を感じているのは「つながり」
二種類がある
僕が考えていく上での助けになるつながり
読者が読んで理解していく上での助けになるつながり
前者の「自分のためのつながり」が、より価値のある「つながり」
後者の「読者の理解のためのつながり」は、大量に機械生成されたのでは目的を達成できない。
著者によって取捨選択を経た少数の有益なリンクでなければならない。
前者の自分のためのつながりは、後者のつながりの選択肢を見落とさないようにする上で有益
そう考えると、著者のためのつながりの提供という意味では、Scrapboxプロジェクトをマージした方が良い
この前回の議論を踏まえると
機械翻訳結果をFirebaseにキャッシュしてmemがリンク結合表示するのではなく、機械翻訳結果がScrapboxに入るべき
Scrapbox翻訳プロジェクト、Keichobotとの会話を見返して考えたら「機械翻訳したものもScrapboxの同じプロジェクトに入れた方が良い」という結論になって「ほんとでござるか？」と思って保留している
同じプロジェクトに全部放り込んだものを別途作って試してみるとかどうでしょう
確かに
全部エクスポートして見積もって見たら24M文字あるので全部翻訳すると6万円掛かることがわかった
最近更新されたページから1ホップとかにするかな…
ドミニオンの話ばっかりだw
妻に「6万円？安いね」と言われた
まあでもやってみて「失敗したー」となると辛いからスモールスタートしたい
記事Xを訳したとき
異なるタイトルY
Xに翻訳クエリを出した時に、既に翻訳済みでそれがYであることがわからなければならない
Yの翻訳時刻よりXの最終更新時刻が前なら訳し直す必要がない
同じタイトル
Scrapboxは同じタイトルの複数のページを持つことができないのでマージされたページになる必要がある
どこまでが機械翻訳でどこからが日本語かわからなければならない
とりあえず人力でDeepLに入れていくつかサンプルを作ってみよう
このリンクの表示され方ではクリックしてみる気になりにくいだろうな
Twitter Cardの実装を優先すべき
DeepLから反応が返ってこなくなったので今日はもうおしまい
参考
Twitter Card表示されるようになった
関連ページを右に出すようになった
このプロジェクトもついでにそうやった
カードUIにはなってない
これらの作業が翻訳コンテンツの改善作業より優先されるのは植物的成長のメタファー
少しだけど検索流入が発生し始めている
それを注視していてもしょうがないので勝手に育つ状態にしてから放置をする
most viewedを眺めて日本特有だったり一時的なバズだったりするものを取り除いてリストにしてみた
意外と長いものが多いなぁ
盲点カードや二人が違うことを言う絵のシリーズを訳すのが良いかなと思ってたが…
まあ両方やって実際のアクセス量を観測する
翻訳したものをみてちょっと直したくなった時が問題
全体を手直ししてないとenにするほどの気持ちにならないがjaenのままにしているとja側を更新したら上書きされる
たぶんこれ抽象的に考えてないで具体的な問題が起きるのを観察すべき
タイトルが元々英字であることで翻訳結果が同一タイトルのケース
併記することにした Memex
機械翻訳が上か日本語が上かは悩ましい
読み手の属性によって正解が異なる
理想としては読み手が英語話者か日本語話者か識別して出し分けるのが良いがScrapboxにそんな機能はない
画像が出せるようになったのでツイートし直した
Cache clear