Readouble

Readouble ( ≒ Read + able × double )

livewire v3の翻訳中です。
当サイトは、川瀬の個人運営サイトです。継続のため、寄付・広告の掲載にご協力をお願いしています。（下記詳細）

提供和訳ドキュメント

以下はアクセスが少ないため、対応でき次第順次再リリースします。

スポンサー

ネコカリ様

みんなシステムズ様

ユアスク様

認識している当サイトの不具合

コードハイライトに使用しているhighlightjsが生成するspanが行ごとに処理をしなくなったため、[tl! ...]による追加／削除／ハイライト表示の範囲が乱れている箇所があります。（特にLivewireドキュメントで顕著）

その他の表示などで不具合を見つけた方は、Xで`@hirokws`か、メールでhirokws@gmail.comまでお知らせください。順次、対応します。特にLivewireドキュメントに対応するために加えたコードがLaravelドキュメントに影響しているかもしれません。全体を確認してみましたが、作業が大量のため、見落としている部分があるかもしれません。気づかれた場合、ご指摘をいただくとありがたいです。

変更点

・「ページネーション」と「スカフォールド」の訳語選択機能を削除し、新たにスペース区切りで対象語と置換語を指定する仕様を追加しました。最大５ペア指定できます。

・ バージョン11から、テストコードがPestとPHPUnitの２ブロック例示されるようになりました。本家ではこれを各コードブロックに表示しているタブで切り代えられるようにしています。当サイトでは両コード表示かPest／PHPUnitのどちらかだけを表示するかを設定から指定できるようにしました。片方だけの表示の場合でも、コードブロックの上のPest／PHPUnitの表示をクリックで、切り替えられます。

・10月中旬にmacOS、Windows、Linuxごとのコードも本家ではタブ切り替えとして提供されるようになりました。当サイトでは上記テストコードと同様に、設定で全OS表示か、一つのOS向けコードだけを表示するかを切り替えられるようにしました。一つのOS向けコードだけの表示時でも、OS名クリックで切り替わります。

・トップバーの固定表示は止めました。右上に表示しているページタイトルにマウスをホバーさせると、表示します。これに伴い、アイコンはすべて右側に寄せました。

・キーボード操作のサポートは止めました。Escキーのみ、パネルを閉じるために利用できます。

・ダークモードをサポートしました。ライトモードとダークモードそれぞれで、コードハイライトに利用しているHighlight.jsのテーマを選択できるようにしました。

・日本語翻訳中から原文の英語を直接確認できるようにしました。非表示・常時表示・一行ずつ表示の３モードを選べます。一行ずつ表示の場合は、行末のアイコンをクリックすると原文が表示されます。

・本文中のリスト項目の並びは、旧バージョンは横向きでしたが、今回のバージョンでは本家と同じく縦向きに並べました。

・Laravel本家が提供しているAPIページへのリンクを章（ページ）移動パネルから削除し、設定パネルの移動項目へ移しました。本家APIページのデフォルトURLページ（バージョン指定なし）へリンクしています。

全文検索は、検索ワードを直接指定するようになりました。前バージョンでは指定した単語を全部AND条件で取り扱いましたが、今バージョンからMySQLの全文検索の形態で指定してください。デフォルトのブール全文検索では、単語の先頭の+はAND、記号なしはORです。詳しくは、MySQL8.0ブール全文検索を御覧ください。

・ドキュメントのコード中にコメントとして存在する、[tl! add]（追加行）、[tl! remove]（削除行）、[tl! highlight]（ハイライト）をサポートしました。追加と削除は背景色だけで区別する方法、行頭のプラスとマイナス記号で区別するdiffツールでおなじみの方法、一般的な文章で使われる消去線（削除）と「追記」の注記による区別の3通りを選んでいただけます。

サンプルコード

挿入行 [tl! add]
削除行 [tl! remove]
ハイライト [tl! highlight]

利用ツール・サービス

サイトを調べるためにデバッグやテストツールで通常とは異なるアクセスを行った結果、CloudFlareが攻撃とみなし、アクセスが遮断された利用者がいらしゃいました。以下の通り、特別なサイト、特別なことを行っているサイトではありません。使用しているパッケージ／サービスは公開しています。

以下のパッケージ／サービスを利用して構築しています。

• ・Laravel10.x
• ・Tailwind CSS
• ・Highlight.js
• ・MySQL全文検索機能
• ・Vite
• ・CloudFlare

２０２４年２月にサイトを更新しました。以前のバージョンは、LinuxコマンドをBashシェルで組み合わせ、Pandocを利用し、MarkdownをHTMLへ変換していました。全文検索は別システムで、MySQLの全文検索を利用し、ルーティングと表示のみLaravelを使用していました。CSSはFoundation CSSフレームワークを利用していました。

２０２１年末から２０２２年年頭にダークモードのサポートなど、UIのみ強化する予定で作業を始めましたが、持病が増悪し中断しました。２０２３年年末から本格的に作業を再開し、変換システムや全文検索も作り変えることにしました。

新しいReadoubleは変換作業・全文検索にLaravelを利用しています。Laravel Folioがリリースされたことが採用理由でした。残念ながら、Laravelドキュメントの表示に使用するとバグが有り、結局Bladeをレイアウトのテンプレートとしてのみ利用しています。Laravelが取り入れたCommonMarkを文字列ヘルパから使用し、HTMLへ変換、最後にpublicへ書き出しています。

全文検索は以前と同じく、MySQLの全文検索をmecabパーサーで使用しており、Laravel Scoutは使用していません。Laravel Scountはいまのところ、日本語の全文検索まで面倒を見てくれません。（オープンソースでは、誰かが貢献しないと実現されません。）

CSSなどのリソース周りは、Foundation CSSが廃れたため、Laravelのエコシステムに合わせ作り直しました。取り掛かった当時はTailwind CSSフレームワークで作り始めましたが、開発が進むにつれTailwind使用部分は少なくなり、最終的に通常のCSSとViteを利用し開発しました。

詳細は、後述のデザインノートを御覧ください。

デザイン・ノート

画面配置や利用するツールの選定、構築方法には絶対的な正解・正義はありません。しかし、特定のシステムでなぜそうなっているのか／そうしているのかというデザイナー／設計者の考えを理解することは、特に初心者にとって勉強になります。（ベテランになるにつれ、だんだんいちゃもんを付けるようになり、そのあと無関心になっていく人が多いようです。）

そこで、このシステムについて、私の考え方を書き残しておきたいと思います。当サイトは万人向け、一般向けのデザインとは毛色が異なるので、あらかじめガードを張っておく目的でもあります。（実際、前バージョンでは「ボタンの位置が～」とか、「デザインが～」とか、学習したばかりであろう若いデザイナーと思われる人たちからディスられました。時代背景として、スマフォが十分に普及し、業界大手がページデザインの指針を発表しはじめ、それに影響された人達が増え、Web業界的にデザインオンリーの人が淘汰されつつあり、プログラミングスキルも身につけようといきなりLaravelを学ぶ人達が増えていた時期でした。）

一般的な話として、デザイナーの性格やクセ、嗜好や価値観がシステムに反映されるのが多いことを理解してください。私は、必ずしも最善最速の開発手法を求めていませんが効率は重視し、リソースが有効活用されることを好み、かつ無駄なリソースを消費するのが嫌いです。派手な色彩を好みますが、目に染みる配色は好みません。操作や入力で、キーボードやマウス、タッチパネルを混ぜて利用することは少ないです。デバイスを切り替えるときは、頭のスイッチ／モードも切り替えるときだと思っています。基本は設計指針に沿うことを好みますが、ユーザーに押し付けるのは好みません。シニカルな面があります。

フルブラウザ優先

前バージョンを作り始めた頃は、スマフォサイズの画面優先でUIを作ることが推奨されていました。当サイトはこの逆で、スマフォでの閲覧をさほど考慮していません。スマフォで読まれている方は約１％しかいません。レスポンシブですが、フルブラウザ優先で開発しています。

アニメーション

まず、前提としてReadoubleを利用する人は、ある程度開発経験・能力がある技術者だと想定しています。（この前提は翻訳時の訳語選択にも影響しています。）以前のReadoubleのUIでは、アニメーションを認識可能な最短時間（0.3秒弱）で使っていました。動きを確実に認識できるスピードでのアニメーションを理想とするのは、使い手に何らかのイメージを伝えたい場合です。しかし、プロの開発者はシステマティックに考える人達でしょう。一般向きのゆっくりしたモーションでなくても、最短でシャキッと動くアニメーションで意図は組んでもらえるだろうと前バージョンでは想定していました。（この点も一般向けのデザイン指針しか知らない人からは反感を受けました。）

今回のバージョンではこの考えをさらに進め、時代には逆行しますがアニメーションは無くしました。当サイト閲覧者のほとんどが表示域がスマフォと比べれば広い、ＰＣのブラウザを使用しています。アニメーション云々のデザイン指針は元来、表示領域の狭いスマートフォンなどのデバイスを使用する一般ユーザー向けのもので、ブラウザアクセスがほとんどで、プロ向きの道具としてのサイトとしては、アニメーションは無い方がキレも、使い勝手も良いだろうと判断しました。

トップメニューバー

前バージョンでトップバーを採用したのは、読んでいるドキュメントのタイトルがどこかに表示されるべきであるという判断からです。ブラウザの共通仕様としてのタブは、多少の情報は出せますが、タイトルを確認してもらうには視線がページから外へそれてしまいます。そこで、ページ内にもタイトルの表示が必要だと考えました。人はいつもベストな状態ではいられないものです。認識力が下がっているときもあります。自分が何を読んでいるのか、失念するときもあります。ですから、目立つページの一番上の中央にページタイトルとして、ドキュメントのH1タグの内容を表示していました。

ただ、文章を読むエリアがトップバー固定表示の分だけ狭くなる点が気にいりませんでした。少しでも広く読ませたいと思いました。そこで現行バージョンでは、文章の最上部を閲覧しているときだけバーを表示し、ページをスクロールアップしたらタイトルを小さく表示することにしました。

この縮小したタイトルは、当初左上への表示を考えていました。ページタイトルを確認するには見やすい場所が適しています。メタファーである紙の書面における習慣からみても、左上か上部中央がページタイトルとしては収まりが良い場所です。しかし、日本語を含め大抵の言語は左から右へ記述します。左から書き始めるため、左側は情報量が多い、つまり文字が存在する確率が高い場所です。タイトルを左に表示するということは、文章を隠してしまう確率が増えるということです。これはよろしくありません。中央はマウスポインターをそれに合わせるために、操作の手間が多少多くかかります。端にある要素にポインターを移動する時のようには簡単には移動できません。そこで、情報を隠す確率が少なく、ポインタの移動操作が単純になる右上へ表示する選択をしました。右上ならずっとポインターを目で追わなくても、右上へマウスを移動し、ポインターの姿が視界から消えたら、少し左下に戻せばヒットします。中央ではポインターを目で追いつつ、操作に多少のコントロールが必要です。

縮小表示時のタイトルを半透明にしたのは、もちろん下の文字がある場合、その存在に気がつけるようにです。必要であれば、スクロールして読んでもらうためです。タイトル自身は読みにくくなりますが、そこはトレードオフというものです。タイトルが常に目立ちすぎて、視線を奪ってしまっては、逆効果ですから、大人しくさせる意味合いもあります。

前のバージョンでトップバー固定表示にしていたときは、左側をジャンプ系機能のアイコン、右側に検索と設定アイコンと分けていました。今回は固定トップバーの代わりに、デフォルトのタイトルボタン表示位置が右上です。展開時、左側へアイコンを配置するとカーソルの移動距離が大きくなり、操作性が下がります。そこで、アイコン全部を右に配置しています。アイコンの並びは以前のバージョンと同じです。

当初はタイトルクリックでトップバーを展開していましたが、自分で試しているうちに、1.タイトルクリック、2.アイコンクリックの２段階操作を煩雑だと感じたため、マウスカーソルオーバーで展開するようにしました。これで自然で使いやすくなりました。

章（ページ）移動パネル

他のドキュメントサイトでは、主に左ペインをメニューとして使用するものが多いです。Laravel本家も、左がメニューです。そして、大抵が折りたたみ形式になっています。（実は、もともと本家は折りたたみ形式でありませんでした。その当時、私がドキュメントを公開していたサイトでは先んじて折りたたみ式メニューでした。）

フレームワークとその構造にあまり親しんでいなかった頃、ページの移動・選択は左右のメニュー形式よりも現在のReadoubleのようにパネル表示のほうが個人的に好きでした。パネル全体の場所で「この機能はこの場所」というようにリンクの場所で覚えていました。調べたい機能→それを含む概念を思い出す→必要なページのリンクを押すというのは、一通り全体の概念をつかめないと難しものでした。折りたたみ式のメニューは同じカテゴリーのページへのリンクをまとめてあります。しかし、全体／個別のページの概念がまだつかめていないときは、構造も理解できず、求めている情報を見つけるためにどのページを読んだら良いか、すぐにわかりません。

パネルに全体の項目を広げて表示する方法は、その項目（ページ）を場所で覚えておくことができます。当サイトはレスポンシブ対応で、表示カラムは横幅により代わりますが、大抵お気に入りの文字の大きさがすぐに決まります。一度決まると、しょっちゅう変えるものでありません。そうすると、パネル内のリンクの表示位置は固定されます。私は、コレクションやヘルパ、文字列ページをよく見るため、これらのページのパネル上の位置を覚えています。（バージョンが上がるとページが増え、場所も変わりますが、すぐに覚え直します。）場所による記憶を使いやすい利点のため、階層メニューではなく、パネルに全章／全ページ広げて一覧表示しています。

ヘッダー移動パネル

前バージョンから変えていません。LaravelのオリジナルのドキュメントはMarkdownで書かれています。そして、ページの最初にTOCがあり、H2とH3の内容がまとめられています。（追記：２０２５年４月現在、右ペインに変更になるようです。）今は、エディターのプラグインで自動的に作成してくれるものがありますが、少なくともこれが採用された当時は手作業でメンテしていたものだと思います。当時も今も時々間違いがあるため、未だに手作業でメンテしているのでしょう。

私は、ページの最初という一番目立ち、本文で重要な部分である書きはじめにTOCを持ってくるセンスが納得できません。私の感覚からすると、あり得ません。もちろん書籍でTOCと本文のページが分かれていれば、最初に目次を用意するのは自然で合点がいきます。（他のドキュメントでは、ペインを３つに分け、左ペインは各ページ、右ペインはTOCとしているものも多いようです。これは、納得できるページ配置です。追記：前記のように本家のドキュメントもそのように変更されます。）

さらに、TOCを手作業で用意しているというのも、気に入りません。事実、間違いが多い箇所です。そんなもの、人間がいちいちやるべきではありません。そうした不満があり、ではどうすればよいかを示すために実装しています。

Markdownの変換時にTOC部分を検知し、削除しています。表示時にLaravelのドキュメントに使用されているH2～H5までをJavaScritpで集めて、内部リンクで移動させています。

設定パネル

設定パネルと呼んでいますが、前半の項目はページの切り替え機能、後半が設定項目です。正直、前バージョンでこの構成を迷った部分です。今回のバージョンでは、前バージョンをそのまま踏襲しました。

機能的にはページ切り替えを独立させ移動パネルを増やすほうがきれいです。しかし、さほど使用されないだろう移動機能のために、パネルを増やすのはさらに納得いきません。最終的に、設定項目とまとめる決断をしました。意味合いとしては「普段は使わないが、利用開始時とまれに使う項目が集まっているパネル」です。ですから、使用頻度を考え、このサイトを利用していくうえで、一度設定したら使わなくなるだろう設定項目は後ろ、設定よりは多少頻繁に使われるだろう移動リンクは前半に配置しています。

前バージョンでは決定ボタンを押すまで設定内容を反映しませんでした。今回のバージョンでは、すぐに反映しています。いつくかの設定項目は、変更するとページをリロードします。ページリロードをパネルを閉じたタイミングで行うようにするのは、将来の改修時に行います。

パネルのクローズ

前バージョンもスマフォサイズ以上の画面サイズでは、パネル外をクリックで閉じるようになっていました。パネルを開くアイコンと同じ位置、上部の左端か右端に閉じるボタンを配置し、間違えて開いた場合でもすぐに閉じられるようにしていました。

ただ、これも当時のツイッターでディスる人がいました。まあ、閉じるボタンを配置するなら、一般的に下側が定番で中央に配置が多いかと思います。そのため、上部ボタンが右や左によっているのが、気に入らなかった様子でした。

今回のバージョンでは、上部の閉じるボタンは廃止しました。その代わり、パネル自身を上部を少し開けて表示しています。ポインタを動かさなければ、間違えて開いても、その場所でクリックして閉じられるようにする配慮です。パネル下部の閉じるボタンは、中央配置にしました。これで、うるさがたデザイナーの人から投稿されずに済みます。

配置と余白調整

今回は、前パージョンほどヘッダーや段落など要素間の余白調整していません。（それでも作業時間の五分の一以上は、表示の調整です。色々設定で変更できますから、ページデザインの調整に手間がかかりました。読みやすさを強調しているサイトなので、ある程度の配置調整作業をしています。）適当と思える余白間隔はフォントにも関係します。当サイトは独自にフォントを本文とコードへ指定できます。さらに利用者の方はブラウザの設定を使い、好みのフォントを使用してる方も多いでしょう。フォント変更で雰囲気も読みやすさも変化します。そのため、特定のフォントに対して微調整を行っても無意味だと判断しました。

APIページ

章（ページ）移動パネルから本家へのAPIページを削除したのは、原文のドキュメントでAPIへのリンクの場所やカテゴリーの分けかたがバージョンで違っており、統一されていないことが一つ目の理由です。もう一つは、Laravelがコード自体をIDEやエディターの自動補完フレンドリーに改善してきており、普通の開発環境では補完が働き、コードの定義元を参照するのもIDEの機能により容易になっている現在、わざわざAPIページを参照しようとする人は少ないだろうからです。実際、APIページを読むのであれば、コードを直接読んだほうが得られる情報は多いでしょう。さらに、AI系のプラグインを入れたり、サービスを利用したりすれば、コードを説明してもらうことも簡単にできる世の中に、この１年でなりました。

ドキュメントの変換

MarkdownからHTMLへの変換をlinux系のコマンドツールから、Laravelを使ったPHPへ変更したのは、Laravel Foiloがリリースされ、最低限度のルート定義でURLとディレクトリーへの配置を一致させることができるようになり、これを使えば旧システムの改修が容易だろうと判断したからです。実際に取り掛かってみると、LaravelのドキュメントでBladeのドキュメントページが上手く処理できませんでした。いろいろ試し、結局難しく、対応するために手間を掛けるならば、自前で変換し各ページをpublicディレクトリーへ書き込んでしまう方法が、閲覧時にPHPが動作せず、サーバーの負荷が減ると判断しました。もちろんWebサーバー側で、URIに該当するファイルが存在している場合は、Laravelを通さずにそのまま送信する設定にします。（一般にどのサイトでも、画像やJavaScript、CSSなどのファイルがフレームワークを通さずそのまま送れるように、普通は存在するファイルをサーバーが直接レスポンスする設定をします。）

コードハイライター

コードハイライターは、ドキュメント中で使用されている"[tl! add]"などの挿入／削除行記法をサポートしたものを探しましたが、当初見つからず、ならばと使い慣れており、シェアも大きく、テーマの数も多いHighlight.jsを選択しました。前バージョンではサイトで用意したテーマに合うコードハイライトのテーマをあらかじめ選択し、CSSへ取り込んでおきました。現在のバージョンは、コードハイライトのテーマをHighlight.jsが提供しているものから選べるようにしました。好みが分かれる配色は、できるだけ利用者に選んでもらいたいからです。ただし、Highlight.jsのテーマは多いため、ユニファイしたCSSに直接取り込まず、動的に毎回読み込んでいます。そのため、ページの描写が多少遅くなり、ちらつくこともありますが、お気に入りのテーマを使える利便性のほうが大きいと判断しました。

差分表示

コードハイライターを組み込み、実装し終えたあとに、"[tl!～]"記法をサポートするハイライターを見つけましたが、サポートしているテーマの数が十分でないため、Highlight.js使用のまま変更せず、挿入行と削除行の背景色は手作業で実装しました。

最初、背景色はベタ塗りでした。このノートを書いているうちに、色弱の方が読まれる時に判読が難しい可能性に気づき、背景を色に依存せずとも見分けがつく斜線を加えました。これは、黒一色で印刷するときにも助けになります。

更に、このノートを書いている間にアイデアが湧き、表示形式を選択できるようにしました。背景色のみ、diffでおなじみ行頭の＋と－、一般的な文章で見られる消去線と追加の追記の３形式にしました。

原文表示（表示）

和訳の原文を英語ページへジャンプしなくても確認できるように、和文の下に原文を表示する仕様です。この機能を取り入れた理由は、私自身が和文を読む時に（特に機械翻訳された和訳）、原文を確認する機会が多いからです。言語切替を提供しているドキュメントサイトもありますが、一部は勝手に日本語ページに移行され、原文ページに行き着くのが困難なサイトもあります。

当初は、対象行へマウスカーソルを乗せたら原文を表示する実装でした。ただ、当サイトでは、内部リンクホバーでその内容を表示する仕様がすでに存在しているため、それと混同させてしまう可能性がありました。次に試したのは行末にアイコンを表示し、それをクリック、もしくはカーソルオンで原文を表示するというものです。現状の「１行毎に表示する」設定の機能です。ホバーで表示は、マウスカーソルの移動中に意図せず原文が表示されることもあり、読み手の意識を引いてしまうことがあるため、クリックにしました。

英語が嫌いで、できるだけ目にしたくない利用者もいれば、逆に、常に原文を参照したい人（私です）、もしくは英語学習のため表示しておきたい利用者もいるでしょう。その中間で、気になった箇所のみ表示したい人もいます。そこで、無表示、常に表示、指定箇所のみ表示する３つの選択肢を用意しました。最初は和文の下に、同じフォントサイズで表示していました。

和文と英文を並べると、どちらも同じ強さの意味合いに捉えられ、和文だけを読みたい時に注意が逸れます。アルファベットは日本語より単純な形です。そのため、フォントを小さくしても文字を読み取れます。そこでまず、英語を小さく表示しました。それでも視覚的には和文だけを読みたいときに、まだ邪魔になりました。ですから、英文の背景色を目立たない程度に変えました。「和文を読んでいるときには無視すべきところ」を逆に多少目立つようにしました。人間の頭脳は高機能です。ここを無視しろとわかりやすくしておけば、簡単に情報を飛ばすことができます。

原文表示（変換）

続いて、和文に原文を取り込む内部実装の話です。今回の回収作業で一番苦労した機能はこれです。readouble.comにホストしている原文と和文は、行の構造を変えないようにメンテしています。和文へ原文変更の差分適用を自動化するため、さらに、誤訳や翻訳抜け、タイポに対応する時に、原文を見つけやすくするためでもあります。

LaravelがStr::markdown()などを実装するため内部で使用しているのは、CommonMarkです。これに限らず、変換パッケージが吐き出す結果は、ファイルの構造が一致していても、同一構造になるとは限りません。今回の場合、英文と日本語（UTF-8）では、Markdownの構造を一致させているため、出力で吐き出されるHTMLタグは同じでも、改行の入り方が異なっていました。

最善手を考えましたが、最終的に改行の出力が異なるパターンを拾い出し、正規表現で変換し、原文と和文の出力htmlを統一しました。さらに、和文を取り込むべきところ、取り込まなくて良いところなどを分けて処理していくうちに、ほぼ構文解析のようになりました。今思えば、最初からMarkdownからhtmlの変換は自前で書いたほうが簡単だったでしょう。次回の改修時は、自分で書きます。事前調査が甘かったと言われればそのとおりですが、Laravelのドキュメントの場合、バージョンごとのhtmタグ埋め込みなども変化が多く、Markdown以外にHTMLタグが混在している点を考慮しても、トライ＆エラーで開発していくほうが無難でしょう。全部を事前に調べるのは理想ですが、手間がかかりすぎます。（本来は、Laravel側がシンプルに原文からMarkdown以外のタグを外し、バージョン間で記述を統一してもらうことが望ましいです。ドキュメントをシンプルにするのが一番です。）

訳語選択機能（2024/04/04削除）

ペジネーションとスカフォールドの訳語を選択できる仕様は、前バージョンのまま残しています。この機能を実装した理由は、SNSや掲示板でこの２語の訳語の選択でおおいにディスられたのが原因です。（信じられないほどにです。）それに対する皮肉で実装したものです。私も若いときは似たような考えを持っていたので気持ちはわかります。何かを批判するのはお手軽な自分の知性の承認欲求を満たす手段です。「俺のほうが優秀だ…俺のほうがよく知っている…俺のほうが正しい…」

当時はSNSがなかったため、私はその欲求を世間へ発信するなんて真似をしなくて済みました。若い時にSNSが流行っていたら、私も間違いなく似たようなことをやっていたでしょう。（その分、今、年を取ってからやっています。）ただ、私が学んできたことは、オープンソースは黙っていても誰もやってくれず、批判だけする行為は嫌われるということです。自分で行うか、貢献する。批判するのではなく、自分の考えを実装で示し、世間の評価を受けろということです。

和文置換機能

前述の訳語選択機能に代えて、置換機能を追加しました。テキストエリアで置換対象文字列と置換語を空白区切りで指定できます。最大数を設けたのは、５つもあれば十分であろうと言うことと、無制限にした場合、保存に使っているローカルストレージを満杯にしてしまう可能性があり、そのような場合のブラウザ動作は各ブラウザで独自なため、対処できるものでありません。そのため、溢れさせないため、ペア数を制限しています。

各文字列長も１０文字までに制限しています。それ以上長い訳語はありませんので、１０文字までで十分でしょう。

リスト表示の並び

本文中のリスト項目の並び（原文はアルファベット順）は１画面に収まる項目数であるなら、縦に並べるほうが便利でしょう。しかし、Laravelのドキュメントでは項目が多い場合がほとんどですし、固定カラム数の本家と異なり、当サイトではページ幅に応じて横に並べる項目数を調整しています。そのため、１ページ内に全項目が収まらずにスクロールする事が多いため、前バージョンでは項目を横に並べていました。今回のバージョンでは本家と同じく縦向きに並べました。縦横どちらも一長一短があります。ロジカルな理由ではなく、前回は横だったため、今回は縦並べにして見ました。使ってみて、次回の更新時に使い良い方に決定したいと思います。（数年先のことです。）

全文検索

利用者が技術者と仮定するならば、全文検索は前バージョンのような簡易検索というよりは、利用者に自由に検索してもらうほうが便利に使ってもらえます。そこで、直接全文検索のSQLを指定してもらうように変更しました。このほうが技術者向けサイトとしては筋が良いですし、全文検索初心者には検索の勉強になるでしょう。

前バージョンでは、ブール全文検索のみでしたが、今回は自然言語全文検索とクエリー拡張全文検索 もできるようにしました。ただ、両方ともにわずかな語で検索する目的のものですので、当サイトではあまり活用できないでしょう。そういう機能があり、当サイトのコンテンツで使ってみると、どうなるかという勉強で使っていただく目的です。

２０２４年５月１８日、パーサーをMeCabへ切り替えました。利点は、検索スピードが上がることです。欠点は、和文として意味のある語単位での検索のため、たとえば翻訳に含まれる「ユーザー」はヒットしますが、「ユーザ」ではヒットしません。

検索時に使用するSQLを表示しています。もちろん、検索SQLの表示はセキュリティ的にバッドノウハウです。当サイトでは入力をプレースホルダーに埋め込み、インジェクションを防いでおり、SQLをダイレクトに呼び出させているわけでないため、問題はないだろうと考えています。

テストコードブロックの表示

バージョン１１から、テストコードに今までのPHPUnitに加え、Pestのコードも列記されるようになりました。Markdownのレベルでは、｀３文字に続け、コードの言語を示すPHP、その後にtab=Pestかtab=PHPUnitで指定してあります。本家ではやたら長いコードが生成されているようなので、なにかCommon Markに拡張機能でもあるのかと探してみましたが、見つかりませんでした。

一度、Common Markを通すと、このタブの指定は削除されてしまいます。そのため、事前に置換で`<tab>Pest</tab>`の形式に変換しています。Common MarkはHTMLをそのまま通過させるからです。

本家のlaravel.comでは、タブ切り替えでコードブロックの表示を切り替えていますが、読むときにタブが目立ちすぎていると感じました。読みやすさを売りにしている当サイトにはそぐわないので、デフォルトは列記、設定からどちらか一方を表示できるようにしました。

どちらか一方だけを表示する場合でも、tab要素で囲んで表示している部分をクリックすれば、もう一方へ表示を切り替えるようにしてあります。ただし、目立つ形でそれを強調していません。見落とされる可能性はあります。カーソルを乗せてもらえば、クリックできると気がつく人もいらっしゃるでしょう。そもそも、デフォルトは両方列記で、設定で切り替えてから初めてどちらか一方だけなので、切り替え機能を見落としても、問題にはならないでしょう。

寄付のお願いと広告の募集

当サイトは私、川瀬の個人運営です。サイト継続のため寄付と広告、スポンサーになっていただける方を募集しています。

GitHubとreadouble.comで提供しているLaravel公式ドキュメントと関連ソフトウェアの日本語翻訳ドキュメントが役に立っていると考えてくださる方で、この翻訳プロジェクトの継続に金銭面で支援しても良い方、企業団体がいらっしゃいましたら、無理のない範囲でご協力お願いします。

個人の寄付

GitHub Sponsors

https://github.com/sponsors/HiroKws

GitHubの支援サービス、GitHub Sponsorsを利用しています。

PayPal個人間送金

https://paypal.me/HiroKws

GitHub SponsorsのUIは英語です。GitHubのUI言語は変更できません。日本語訳を提供している当サイトへの寄付に英語が必要なのは筋がよくありません。そこで、PayPalも用意しました。

PayPalはカスタマーサービスへ問い合わせ、利用者やブラウザの言語設定に基づいて利用者の設定言語で表示されると回答を得ております。当方で確認した結果も同様でした。

スポンサー（ロゴ表示）

当翻訳サイトの継続スポンサーになっていただける個人・企業・団体を募集しています。（広告費として落とせるのであれば、寄付していただけるという声にお答えしたものです。祭りでの寄付と同様に、実際に経費と判断されるかは税務官の裁量です。）

１枠、月５千円で最大１２社／団体／サービスまで募集します。（内、１枠は広告スペース利用者様）

無料公開の全ページの最後に「スポンサー」としてロゴを表示いたします。指定URLへリンクします。

表示順は毎時、ランダムで変更します。

基本は、お預かりした画像のまま表示しますが、視覚的に目立ちすぎる場合や、サイズが大きすぎる場合は、こちらで加工する場合があります。（通常は事前のやり取りがありますので、私が加工することはまず起こりえません。）

ロゴは幅200pxで表示します。極端でなければ、縦長でもかまいません。読みやすさを提供するサイトですので、極端に目を引くデザインや色使いはお避けください。ダークテーマ、ライトテーマ両方で表示に支障がないよう、確認してください。

ロゴ画像、リンク先URLはこちらで確認後、掲載いたします。altは社名／団体名／サービス名（敬称略）の末尾に「ロゴ」をつけたものにします。

お支払いはStripeの専用サブスクリプションリンクから、カードでお願いします。毎月払いです。（画像、リンクURL、掲載開始日を確認後、お知らせします。）

問い合わせは、hirokws@gmail.comまでお願いします。

私は、適格請求書発行事業者ではありません。ご了承ください。

広告スペース

現在、㈱ネコカリ様より、ご利用いただいております。利用終了まで、レンタルできません。

現在、各ページ上部に表示していますGoogle Adsenceの広告スペースをそのまま一月あたり３万円でレンタルいたします。（１ヶ月単位）

広告表示のコードは当方では用意しません。お預かりしたコードを現在アドセンスの広告を出している位置に置き換えます。広告以外のコンテンツに影響を与えないようにお願いします。

レスポンシブでの表示をお願いします。読みやすさを特徴の一つにしているサイトです。そのため、ページ遷移時の広告（インタースティシャル広告）の組み込みや必要以上に広告スペースを広げないようお願いします。また、配色やデザインにもご配慮ください。

公序良俗に反する内容はお断りいたします。また、広告の又貸し、もしくは他社の広告表示はお断りします。

利用されるシナリオとして、Laravelを利用して開発している会社などの宣伝／社員募集や、Laravelを教えている学校の宣伝を兼ね、授業の一環として生徒にデザインさせる、コードを書かせてみる状況などを想定しています。もしくは、当サイトの読みやすさに協力するため、社名のみの小さなバナーを掲載し、オープンソースへの貢献を示す方法もあるでしょう。

私は適格請求書発行事業者ではありません。ご了承ください。

Laravel本体への貢献

翻訳プロジェクトではなく、Laravel本体に金銭面で貢献したいのであれば、Laravelのファースト・パーティー・サービスを利用してください。

書籍執筆時、開発者のTaylor Otwell氏にコンタクトを取り、金銭面で貢献するには直接寄付したほうが良いか、それとも彼が運営するサービスを利用したほうが良いか尋ねたことがあります。答えはサービスを利用してほしいそうでした。

実際、VPSサーバーを管理してくれるForgeなど、便利な機能が提供されています。開発側も利用者側もwin-winになります。常勤の開発者を雇えていることが、Laravelを開発持続できている理由です。

経緯詳細

readouble.comの広告収入を生活基盤としてどうにか２０２２年まで続けて来ましたが、コロナのあおりを受け落ち込み、さらに私の持病が再発したため、継続が難しくなりました。そこで、多くの方のお声を受けて、募金を集めることにしました。更に寄せられたアドバイスの声を受け、２０２４年現在、スポンサーと広告スペースの募集も開始しました。

説明は長くなります。募金を募るからには、正確に詳細を発信すべきでしょう。実際、SNSや掲示板では詐欺扱いの声もありました。非常に不思議ですが、無料のフレームワーク自身を使い、自分は有料で稼いでいるのに、ドキュメントの翻訳を無料で公開しつつ、寄付を募ることにはなぜか風当たりが強いのです。

近々の状況（２０２４年記述）

募金を開始し２年経ちました。おかげさまで、広告収入と合わせ治療費、検査費はどうにかなり、小康状態を保っています。ただ、募金も広告収入も減少傾向が続いています。

病名は突発性拡張型心筋症です。状態は心不全です。現在の心不全の標準治療の薬がこの病気には効果が大きく、それに近い薬を服用しています。

最近は心不全に限らず、肝臓病、腎臓病、糖尿病などでも運動をして筋肉を落とさないことが各疾病の学会よりリハビリとして推奨されています。そこで、私も運動を持続しています。週に何回かは軽く走り心拍を上げ、歩いて維持しを数十分から一時間行い、体調を保っています。

心不全の場合、運動による増悪の防止は、服薬と同等かそれ以上の効果があります。（論文レベル）

以前は、薬の影響か心不全そのものの症状により頭の働きが良くありませんでしたが、薬の調整で最近は思考力の低下を防げています。

集中力は長時間続きませんが、一日数時間はコードを書けるため、以前やりかけていた当サイトの改修を再開しました。今回は広告とスポンサーの募集を行ってみます。

近々の状況（２０２２年記述）

今年、２０２２年に入り、１月の中頃から咳が止まらなくなりました。現在、コロナのオミクロン株が猛威を振るっている最中であり、その可能性もありますので、おとなしく自宅で療養していました。２週間経っても治らないため、かかりつけ医を受診し、心不全増悪の可能性を指摘され、専門医へ紹介されました。

近年は調子が良かったですが、もともと拡張型心筋症を患っていました。通院は受診時の検査が多く、費用がかさみます。この病気は難病指定されており、現在の制度では入院するとその後１年間、補助が受けられます。（以前は入院は条件でありませんでした。しかし、透析患者が増えてきて、財政が足りなくなり、難病の補助の条件が増えました。病人間でお金の引っ張り合いをしているのです。透析は同じ病院で長時間過ごすため患者間の関係が強い団体を作っており、人数が少なく、ばらばらで通院している他の特定疾患の人達は、政府との交渉で勝ち目がありません。）

現在、私はreadouble.comの広告収入をメインに生活していますが、こちらもコロナの影響を受けて芳しくなく、通院の費用を支払うとなると、使える時間と体力をドキュメント翻訳以外の仕事に回すしかありません。これは、翻訳作業を大幅に縮小するか、より理性的には翻訳を止める選択肢を選ぶ状況です。（実際、体力が持つならば、コンビニやスーパーのアルバイトなどに時間を使ったほうが、より収入は得られます。）

ただ、Laravelは人気のあるフレームワークに育ちましたし、readouble.comへのアクセスは多い状況です。利用していただいている方がたくさんいらっしゃいます。いきなり、翻訳を止め、メンテナンスを中断してしまうと困る方（開発者だけでなく、Laravelの人気持続を期待している出版社や教育機関の方々）も存在すると思いましたので、個人・法人・団体からの寄付を募り、翻訳プロジェクトを持続する可能性を探ることにしました。

専門医（循環器内科）の診断は、しばらく心臓を休めろという指示でした。かかりつけ医が処方した利尿剤がよく効いており、肺の水分が抜けて快方に向かっているため入院はしなくてもよいという判断になりました。（入院しないかとも勧められましたたので、入院するか、しないかのちょうど基準の状態でした。ただ入院しても、心臓の拡張を治す薬はありませんので、心不全の処置として利尿剤を投与され、ベッドで寝て回復を待つだけです。）

ドキュメント翻訳を始めたきっかけ（２０２２年記述）

約１０年前、東京に住んでいるときに発病、入院し、拡張型心筋症と判断され、担当医から「よくなる見込みはない。これから少しずつ悪くなるだけ。」と宣告を受けたので、ある意味死ぬ覚悟で故郷（新潟）へ戻りました。

ただ、この診断は間違いでした。田舎へ戻ってから心筋症を専門としている先生にかかったところ、当時でも「薬がよく効けば（７年後の予後で３割）良くなる見込みはある。（逆に当時で３割は死亡）」という診断でした。

戻ってきた当初は、自分でWebサービスを作り収益化を目指す予定でした。体調がどのように変わるか将来が読めず、どの程度の作業できるのかもわからずでは、務めたり、仕事を受注したりするのはリスクが高いし、悪化したときに相手に迷惑をかける可能性もあったからです。

自前の開発のため、言語やフレームワークを選定するためいろいろと試していくうちに、Laravelを見つけ、ブログで紹介しました。バージョン２から３になった頃です。当時のLaravelは現在と異なり、シンプルで初心者が学習しやすいものでした。今も変わらないのは、良いコミュニティーがあることです。

Laravelは英語圏で人気を得はじめたばかりでした。日本でも人気と利用者を増やしたいと思いました。経験則から、日本で人気を得られるソフトウェアは、日本語ドキュメントが存在することが必須だと信じていました。機械翻訳がまだ一般的でなく、精度も発展途中でした。私自身、英語より日本語ドキュメントがないと、活用しずらい人間ですので、自分で使うついでにドキュメントを翻訳し（当時のLaravelは、まださほどドキュメントの量もありませんでした）、必要な他の方々にも利用していただくことにしました。これが、翻訳を始めたきっかけです。

収益化の経緯（２０２２年記述）

体調の不調や入院で、東京から戻るときには財政的な余裕はなくなっていました。ですから、何かの形で収入を得る必要がありました。

翻訳の維持を含め、作業できる時間が体調に左右されるため、可能な時に集中し作業できるスタイルの収益化方法を取ってきました。

最初は電子書籍生成サービスである、Leanpubを利用し、ドキュメントの日本語翻訳を安価な電子書籍版として発売しました。同時にWebでも公開しました。定期的に翻訳し、Leanpub版を先行して更新しました。これはLeanpubが厳密に日本語に対応しておらず、適切な折り返しや禁則処理のため、空白で調整するなど手間を食う割に、手にできる金額は小さいものでした。この頃一度、お金が足りなくなり、寄付を２万円ほど集めたことがあります。

Leanpubでは有名Laravelユーザーや開発者のOtwell氏が関連電子書籍を出版し始めました。Laravelのまとまった情報は少なかったですし、コンセプトを説明してくれる書籍は貴重でした。そしてLaravel開発者の教育という面でも必要でしたので、何冊か翻訳しました。この売り上げにより、生活できるレベルの収入は確保できましたが、長続きはしませんでした。

理由は２つあります。ほとんどの原書では「将来のアップデートには、無料で対応」と宣言しているのに、実際は更新される書籍がないため、翻訳者の私としては詐欺の片棒を担いでいるような気分になったことが、一つです。

もう一つは、日本でLaravelの実際の書籍、つまり電子書籍ではなく、紙の書籍が発売されたことです。日本人が書いた紙の書籍があれば、わざわざ外人の書いた単一テーマの書籍を購入する読者はなくなります。その書籍には、著者として私も参加しましたが、原稿を書いていた当時から、私が翻訳した電子本の売り上げは将来下がっていくだろうと、予想していました。

当時、ツイッターでつぶやいた覚えがありますが、それでも紙の書籍が必要だったのは、ある種の権威付けでした。Laravelが認知され、人気が出てきて、最新のフレームワークであるという権威付けです。Laravel開発側もバージョンが上がり、大型プロジェクトでも使えると言い出した時期です。本一冊も出されていないものを次期フレームワークとして開発者が推薦しても、日本では決定権のある会社の偉い人には採用してもらえません。紙の書籍がいくつか出されていればある種の権威付けになり、フレームワーク採用に納得してもらいやすくなります。

書籍の内容には個人的に満足していません。私が主筆ではありませんが、購入していただいた方には謝罪するしかありません。今も、最初にオファーをいただいた時点の、不参加の決意を固辞すべきだったのではないかと、後悔しています。ですか、Laravelが日本で広く人気を得る過程で、紙の書籍は必要で、ちょうどよい時期に発売されたのは間違いありません。

その後は、readouble.comの広告収入も少しずつ増え、十分ではありませんが、ぎりぎりで生活していました。それが、コロナの影響を受け不調となり、それから２年間ずっと低迷し、今回（２０２２年）のタイミングで持病が再発しました。

将来の見通し（２０２４年記述）

Laravelに限らず、ドキュメントを読む人が減っています。特にこの一年、AIの進化で、ドキュメントを読まなくてもコードを自動生成してくれるようになりました。今回の改修で私自身試してみて、その進歩を感じました。AIの進化によるコーディング支援と自動コード生成の進化も、ビュー数が減っている一因でしょう。

サイトのビューを上げるため、Laravel周辺パッケージを翻訳する予定はあります。しかし、広告収入は下がるでしょう。２０２２年の頃は、クリックによる収入が多かったのが、今では広告を観てもらうことで入る収入のほうが多くなりました。こちらでは一切操作していませんので、Google側の変更です。Googleに同業他社が増えれば、Googleの収入は減ります。しかし、Googleは歩合を公表していないのですから、彼らはそれを内部的に変えて利益を確保できます。結果、アドセンスから入ってくる収入も減少しています。

それが、ページ上部の広告スペースをレンタルしていただきたい理由です。ページ最後の広告は、アドセンスがページ内容に基づいたリンクと広告を提供する機能を廃止したため削除し、月５千円のスポンサー契約をされた個人／団体のロゴを全ページに表示することにし、収益につなげたいと思っています。

有料会員限定コンテンツも実現しようと考えています。しかし、残念ながら最近のAI提供サービスを超えるようなコンテンツが今のところ見つかっていません。

将来の見通し（２０２４年記述）

この一年、開発における大きな話題は、AIによるコーディンのサポートであることは間違いありません。AIがコードを自動生成できるには、ソースコードを十分に取り込む必要があります。

Laravelは中心となるフレームワークも便利ですが、その周辺のエコシステムも便利です。ただ、周辺パッケージ／サービスはUIもドキュメントも英語です。それらは日本語に訳されることもなく、利用される方は比較的大規模な開発を行っている企業の方々になるでしょう。英語でもドキュメント以外の情報が少ない部分です。

そのため、そうしたエコシステム周りでは、オープンにされるソースが少なく、AIのサポートも弱いでしょう

Laravelの人気は、その周辺の便利さが広がれば、持続されるでしょう。現在のローカル環境のセットアップのように、似たようなファーストサービスを提供しつづけてしまうと、混乱が増え、新しいユーザーの獲得に苦労することになるでしょう。人気を持続するには、サービスの整理がたぶん必要です。

将来の見通し（２０２２年記述）

これも先にツイートしましたが、後１０年程メンテナンスを続けたいと思っています。なぜ１０年なのかという理由を説明します。

まず、私の寿命を考えての判断です。さすがに病気を何一つしていない人よりは、長生きする確率は低いでしょう。私の心臓は右が伸びやすくなっているようで、右側の心不全だと肺に水が溜まります。利尿剤が効くうちはいいですが、効かなくなり、再度拡張してしまうと、また呼吸困難になります。肺の中に水がたまるとは、ゆっくりと溺れていくということです。多分、肉体的にも、精神的にも耐えきれません。

１０年でくたばるという意味でなく、１０年くらいは翻訳し続ける体力と気力が持つだろうと予測しています。さすがに、２０年は無理ですが。

そして、機械翻訳サービスの品質向上も素晴らしく、この数年間の発展は驚異的でした。特に、翻訳サービスのDeepLは自然に読めるレベルの和文へ翻訳してくれます。未だ、意味を真逆に訳すなど、クリティカルな間違えを時々起こします（この点は人間でも同様ですが）ので、今のところ原文の確認は必要ですが、荒訳として十分に使えます。あと１０年もすればさらに良くなり、人手で翻訳する必要もなくなるでしょう。

最後に、LaravelとPHPの人気がどの程度継続するかという予測です。プログラミング言語もフレームワークも、流行り廃りがあります。１０年たてば、シェアは変わるでしょう。たぶん、低くなるでしょう。私の予感では、Laravel自体は他の言語で再構築される可能性があるかと思います。作者のTaylor Otwell氏がうまいことマネタイズしましたし、開発も他の人を入れて組織化に成功しています。複雑化したとは言え、利便性の良いフレームワークですので、将来のある時点でエポックメーキング的な言語へ移植し、彼のビジネスを継続していくだろうと思っています。（プログラミングという職業がまだ存在すればの話です。）

言語という点で、あくまで私の個人的な考え方ですが、PHPはお手軽さが受けていたのだと思います。しかし、今やほかの言語の先進的な部分を取り入れ、言語としては立派に成長しましたが、いかんせん複雑化しました。現時点でプログラマーを目指す人が第一に選択するような言語ではありません。コロナの影響かもしれませんが、複雑化するにつれ、Googleトレンドでは、下がり目になっているように見えます。

ですから、言語としてのPHPとフレームワークとしてのLaravelは、あと１０年くらいは持つだろうが、そのころには別の形態になっているだろうと予想し、１０年という数字をあげました。

体調面の見込み（２０２４年記述）

現在、小康状態です。人間、誰しも寿命が尽きる寸前まで長生きすれば、心臓も弱くなり、心不全状態を経験することになります。私はそれをちょっと早く、そしてかなり長く経験しているわけです。

広がった心臓も、今回は１年でもとのサイズに戻ったようです。肺の鬱血（鬱水）もとれ、心エコーの診断でも、医者がこの病気だとわかっているので動きがおかしいところがあると気がつくが、もし知らなかったら気が付かないくらい動きは良いと説明を受けています。

以前よりは頭の回転が鈍くならずに済んでいるため、コーディングや翻訳、文章をかける時間が長くなっています。体調と環境が整えば、半日くらい続けられます。

心不全状態から回復するには、まず心臓の負担を軽くするため、今も昔も利尿剤を使い体の中の血液量を少なくします。それから、様々な薬を使用し増悪や入院をできるだけ防ぐのが、世界的なスタンダードな治療になっています。心不全になると飲む薬の種類が増えます。

心不全については、この１０年で薬と活用法のブレークスルーがどんどん起き、私がこの病気にかかったときより、とても進歩しています。最近の話題はSGLT2阻害薬で、もともとは糖尿病の薬です。これが心不全や腎臓・肝臓病にも進行を遅らせる論文が出てきており、特に心不全では１年前に海外で他の既存の薬よりもエビデンスが強い推奨薬になりました。私は、全部を新しい薬にすると薬代が高くなるので、SGLT2阻害薬を除いて、ほどほどにしてもらっています。

そうした薬は、状態の増悪を防ぐ効果があるものです。拡張型心筋症は、薬では心不全の対処しかできません。心不全は一般に増悪と回復を繰り返して段々悪化していきます。増悪を防ぐことが、悪化を防ぐ方法です。

悪化して他の手段が取れなくなれば、治す手段は心臓移植のみです。対処としては、心臓を小さくする手術方法もあるようです。

多分、あと１０年くらいするとIPA細胞で作った心筋細胞を心臓に注射する治療方法が確立され、治る可能性は出てくるでしょう。（一昨年あたりで実験段階でした。）

体調面の見込み（２０２２年記述）

私が罹患した突発性拡張型心筋症の突発性とは、複数の原因が重なり発病すると考えられており、そのため原因の特定が難しいことろから、突発性という言葉が使われます。

左心房の働きが弱くなると、肺に水がたまるようになります。結果、水を排出するため咳も出ますし、呼吸困難にもなります。

これが治らないのであれば、正直体力があるうちに安楽死したいと思います。少しずつ溺れ死ぬのは拷問です。

しかし、私の場合血圧の調整や心不全の改善に特に利尿剤がよく効くようで、回復の見込みは十分にあると思います。（２０年ほど前に塩分を３グラムまで減らす生活を続けたら、血圧が下がったので、塩分がたまりやすい体質なのかもしれません。）

２月中旬まで、椅子にきちんと座り続けるのが難しい状態でしたが、現在は一日数時間キーボードに向き合えます。

ここから、心臓がしぼむまで年単位の時間はかかるでしょうが、翻訳を続ける時間は確保できると考えています。（医者からは２回目の拡張なので、前よりは戻りづらいかもしれないとお茶を濁されています。私は医者の見込みよりも、高い確率で戻せると思っています。）

理想を言えば今年の秋ぐらいまでは、軽く走れるくらいに戻りたいと思っています。（ある程度改善したら、心臓病患者は歩くことも、心臓の負担を下げるため、勧められます。）ですから、リスクは抱えながらも、あと１０年は体が持つのではないかと楽観視もしています。

ツイートの意図と反応に対する見解（２０２４年記述）

公開するのは２０２４年になりましたが、２０２２年の時点の状況です。

２月９日に次のツイートを行い、バズりました。

「http://readouble.com でLaravelと周辺ソフトウェアのドキュメントを翻訳しています。半分以上の方が広告ブロックを使用されているため、収入も半分以下になりました。体調を崩してしまい、これ以上訳し続けるのが苦しい状況です。広告ブロックの使用をやめてもらえませんでしょうか。」

今まで何度か似たようなツイートを行ったことがあり、これが初めてではありませんが、バズったのは初めてです。

他のツイートでも説明しましたが、私自身は広告ブロックは使用していませんが、他の人の広告ブロック使用に対して批判したわけではありません。

Googleアナリティクスとアドセンスで表示される、ビュー数を比べると、アドセンスが１／３程度の数になります。全部が全部ブロックしているわけではないでしょうし、この比較で広告ブロックの使用量が正確にわかるわけでもありません。そこで少なめに、「半分」という表現をしました。

このツイートに対するリアクションは色々ありましたが、返答やリツイした後にすぐブロックする方もいらっしゃるため（その行為も責めません。私も凸られたときにやりますから）、全部を追えていません。似たような意見もありました。その中の一部に関して見解を残しておきたいと思います。

中には、単にもっとマネタイズすれば良いとか、やめてしまえば良いという意見もありましたが、たいていはオープンソースや翻訳プロジェクトをよく知らない方々が、広告ブロックへの批判だと思い込み、自分が責められているように感じた結果、批判で返したものだと思います。この種の意見へいちいち反論するのは大変ですし、それをする気力もありませんでしたので、この種の意見は無視することにしました。

寄付を募集したら良いのでは。GitHub Sponsorsを利用したら…、クラウドファンディングを活用したら…

ありがとうございます。そうさせていただきました。寄付いただいた方、ありがとうございました。

最初は日本語で寄付いただけるサービスを数日探しました。しっくりくるものがありませんでした。

GitHub Sponsorsは存在を知っていましたが、詳しい内容は理解していませんでした。調べると当プロジェクトにぴったりでした。欠点は英語のUIで変更できないことでしょう。

次に、日本語UIで寄付できる方法を探し、PayPalの個人送金が使用できる、PayPal自身が寄付には個人間送信を使用しろと説明しているのを見つけ、カスタマーサポートにUIの表示言語を尋ねたところ、OSやブラウザの設定に合わせて表示されるという回答が確認できたため、PayPal.MeのURLを取りました。

現在は、Stripeを利用して、個人事業者、企業・団体、メインスポンサー向けの寄付の募集の準備を行っています。ここまでやると、オープンソースプロジェクトと言うより通常のビジネスに近くなってしまいますが、お金を集めて安定させるには必要なことだと、納得しています。しかし、これ以上の手間をかけるつもりはありません。翻訳が進まなくなります。

広告ブロックをやめてもらったところで、クリックしないだろうから意味がない

直後、ビュー数が３０％アップしました。（２０２４年現在、広告を目にしてもらう数を元にしていただく金額が、クリックでいただく金額より大きくなっています。）

広告をGoogleに任せるから、落ち込むんだ

Google以外ですと、読みやすさを壊してもらうものもあるため、任せられません。（２０２４年現在、この広告スペースを直接１社へお貸ししようとしています。）

広告ブロックをやめると、不快な広告が表示されるからやめられない

不快な画像が表示される広告は、アドセンスの設定で個別に表示・非常時を設定できます。当サイトでは見つけしだい表示しないようにしています。

そもそも、広告はサイトの内容に合わせて表示する・されるのが基本です。当readoubleのコンテンツと、こうした不快な画像の広告は合わないため、一般的には表示されづらいでしょう。

ブロックしている人たちは、ホワイトリスト機能を知らない

そのとおりです。ブロック拡張を入れても、readouble.comをホワイトリストへ追加していただけば、readouble.comだけで広告が表示されます。