フォーラムへの返信

15件の返信を表示中 - 1 - 15件目 (全48件中)
  • これらが足を引っ張るというのなら、廃止もやむを得ないでしょうね。

    以前とは違い、現在では wp-config.php と readme.html を参照する方はほとんどいないと思われるのですが、

    昔もそんなに見てもらえなかったですが、現在ではなおさらそうなのでしょう。僕自身も、日本語版作成チームを外れてからは滅多に見てませんでしたし。

    今更ですが、readme.html にある「オンラインの資料」は有用なのでこの readme.html がすぐ見られるようになっていればいいのに、と思っていたことがありました。今ではダッシュボードの「ヘルプ」などからたどれるようになりましたし、IRC はここ何年ももうほとんど使われていません。もう役目を終えたでしょう。

    wp-admin/about.php からの5つめのリンクとしてでも入っていればまだ日の目を見たのになあ。

    個人的にはちょっと思い出はある
    https://pasero.net/~mako/blog/s/583
    のですが、そんなことは関係ないので、より不都合の少ない方向に進めるのがいいと思います。

    ウェブのどこかに置いておくのはいいと思います。

    フォーラム: バグ報告と提案
    返信が含まれるトピック: [提案] 抜粋の説明

    「語」というと、英語のような分ち書きをする言語での単語数、を思い浮かべてしまい、では日本語では何を指すのだろう、と思ってしまいました。

    最近ちゃんと追いかけてなくてわかっていませんが、実際は「110文字」でしょうか? すみません。

    フォーラム: 使い方全般
    返信が含まれるトピック: タイトルにHTMLタグを入れると
    トピック投稿者 Mako

    (@mako09)

    えーと、何が問題なんだっけ? ;p

    再現手順は昨晩のコメントに書いたとおりで、

    記事タイトルに「HTML の <ruby> に思うこと」と書いたとします。
    WordPress の RSS の XML を見ますと title タグのところでこれが「HTML の <ruby> に思うこと」と、数値文字参照になってます。

    で、RSSリーダー(いま試してるのは Linux の Liferea)で読むとこれが「HTML の に思うこと」と表示されます。

    前のコメントの例だと、WordPress で「条件 a<b かつ c>d の場合」の記事タイトルは、RSSリーダーでは「条件 ad の場合」になります。

    です。記事を書く際に生で書いても(編集:生だとそもそも保存できないかな)<でも数値文字参照の10進でも16進でも、結果は同じです。ご説明いただいたような関数で処理されるので(私も昨晩ソースを見てみました)。

    繰り返しになりますが、WordPress の RSS 出力の段階では数値文字参照の形になっています。nobitaさんの例示のように16進ではなく10進ですが。

    > ちゃんと動くってところが理解できないんです。

    ほんとトピックの題を変えてしまいたいくらいなんですが、記事タイトルにHTMLタグを入れたら、と考えないほうがいいです。
    「条件 a<b かつ c>d の場合」みたいな例のほうが誤解がないです。

    これでいうと、WordPress の通常の表示や、管理画面の投稿一覧やダッシュボードのアクティビティのところではちゃんと「<b かつ c>」が表示されて意味がとおります。RSS の出力は上述のとおりです。いずれも山括弧(不等号記号)は文字参照表記に変換されてるんだと思います。

    で、最後に RSSリーダーで見たら「<b かつ c>」の部分が消えて意味不明になってしまう、ということです。

    ※このコメント文中の&はぜんぶ半角英数だと思ってください。

    • この返信は4年、 2ヶ月前にMakoが編集しました。
    • この返信は4年、 2ヶ月前にMakoが編集しました。
    フォーラム: 使い方全般
    返信が含まれるトピック: タイトルにHTMLタグを入れると
    トピック投稿者 Mako

    (@mako09)

    このトピックの題を変えてほしくなってきた。

    途中で結論のようなことは出てるんですが、
    まず「タイトルにHTMLタグを入れると」は私の検証不足でした。ぜんぜん関係ありませんでした。申し訳ありません。

    もし問題があるとすれば、タイトルに山括弧(不等号記号)を入れる場合(生で入れようが文字参照にしようが数値参照にしようが)です。

    でも、これも WordPress の範疇では問題ありません。記事タイトルにはふつうに表示されるし、たとえば管理画面の投稿一覧やダッシュボードのアクティビティに表示されるときにも問題ありません。
    RSS として吐き出されるものにもちゃんと含まれていますので、これも WordPress としてはちゃんと仕事してます。

    なので、このトピックはそもそもまったくこの場にふさわしくなかったということです。ほんとによく試しもしないで書き込んでごめんなさい。

    たまたま私の使っている RSSリーダーが(そのほかでどうなるかは見てません)、このような文字列を正しく解釈しないということのようです。あと Jetpack 経由の Twitter も。こっちはぜんぜん追ってもいませんけど。

    いずれにしろ WordPress は無罪でした。ほんとすみません。

    nobita さんご指摘のようにやってみても、結果は同じでした。WordPress の範囲では正しく残っていて、RSS リーダーのところで消えます。

    • この返信は4年、 2ヶ月前にMakoが編集しました。
    フォーラム: 使い方全般
    返信が含まれるトピック: タイトルにHTMLタグを入れると
    トピック投稿者 Mako

    (@mako09)

    山括弧(不等号記号)を直接書くんじゃなくて文字実体表記で書けば、ということですね。
    それでもだめでした。

    記事タイトルに「HTML の <ruby> に思うこと」と書いたとします。
    WordPress の RSS の XML を見ますと title タグのところでこれが「HTML の <ruby> に思うこと」と、数値文字参照になってます。

    で、RSSリーダー(いま試してるのは Linux の Liferea)で読むとこれが「HTML の に思うこと」と表示されます。

    前のコメントの例だと、WordPress で「条件 a<b かつ c>d の場合」の記事タイトルは、RSSリーダーでは「条件 ad の場合」になります。

    ※このコメント文中の&はぜんぶ半角英数だと思ってください。

    フォーラム: 使い方全般
    返信が含まれるトピック: タイトルにHTMLタグを入れると
    トピック投稿者 Mako

    (@mako09)

    いくつか試してみて、自分の勘違いに気がつきました。ごめんなさい。

    RSS と Jetpack の自動投稿と、ちょっと違うものの結果が同じになったので、てっきり送出側の段階で消失していると思いこんでしまいました。RSS の XMLを見てみて、送出されているものには、いま問題にしているものはちゃんと存在していることを確認しました。

    ということで、RSS リーダーなり twitter なり受け手の段階で消えているようです。すみませんでした。

    それから、記事タイトルに HTML タグがある事自体は問題なくて(記事の h1 以外に使われるときには WordPress が the_title_attribute() あたりで無害化するので)、今回引っかかったのは山括弧(たとえそれが実体参照の表記になっていても)のようです。

    だからもし、「条件 a<b かつ c>d の場合」なんていう記事タイトルだとしたら、今回と同様に WordPress そのもので見るときには問題なくて、RSS ではそれを受け取った側で変なことになります。
    (ほんとうにこんなタイトルの記事を書く必要があるときはどうすればいいんだろう?)

    お騒がせしました。

    フォーラム: 使い方全般
    返信が含まれるトピック: タイトルにHTMLタグを入れると
    トピック投稿者 Mako

    (@mako09)

    なるほど。

    見た目をコントロールするのはスタイルであって、タグは“意味”なので「タイトルに用いる意味がない」は違うと思うんですよね。

    今回は code でしたが、WordPress の記事のタイトル中に、強調だろうが abbr だろうが ver だろうが、意味を付けたいときはあると思うんですよね。それこそ ruby を振りたいときだってある。どうなるか試してみてませんが。

    タグだけを無視してそれが囲んでるものは残してくれればいいのですが、それが囲んでいるものもひっくるめて無視するのはどうなんだろうか、と思ったのです。

    フォーラム: その他
    返信が含まれるトピック: WordPressというネーミングについて

    検索すればすぐに出てくるとは思いますが、たとえばこんなの。
    http://ascii.jp/elem/000/000/409/409338/index-2.html

    フォーラム: その他
    返信が含まれるトピック: GPLライセンスについて(販売テーマ等)
    Mako

    (@mako09)

    まず、WordPressのテーマ(のPHPコード)はGPLでなければなりません。
    https://ja.wordpress.org/2009/07/03/themes-are-gpl-too/

    さて、GPLとはどういうことか、というと、WordPressの管理画面で左上のWマークをクリックして見ることができる「自由について」というページに簡潔に、0,1,2,3 の4項目にまとめてあります。

    そこでは主語が「ユーザーは」で「…の自由を有します」と書かれています。同じことを主語を「配布者は」にして考えてみると「ユーザーの…の自由を制限してはなりません」という意味です。

    したがって、1番めのご質問の答えはそのとおりで、配布者はそのような制限をしてはなりません。

    2番めのご質問もそのとおりで、ユーザーはプログラムを自由に利用する権利を有します。ただし素材やCSSにはGPLは及びませんので、お考えのとおりです。

    最後に、たいへん細かなことですが、GPL の L は「ライセンス」ですので、「GPLライセンス」というのは変だよなあ、とこの表記を見るたびに(とてもよく目にするのですが)私は思っています。

    今夜のミーティングは参加できないかもしれない(できたとしてもこんないっぺんに発言できない)ので、ここに書いておきます。ただのメモみたいでまとまりがなく読みにくくてすみません。

    中長期的課題としてひとつ、

    貢献者層を厚くする

    を挙げたいと思います。

    そもそもこの層? を何と呼ぶのでしょうか。末端ユーザーでもなくコア開発者(能力のある人は直接向こうの開発に参加すべし)でもなく。
    日本語圏のこの層の担うべき役割のひとつは「翻訳」だと思うので、それについて考えてみます。

    フォーラムの概要はデフォルトで WordPress のダッシュボードに表示されるので、たとえばこのトピックも題名だけは数万人?の目に触れるでしょう。しかしその大部分の人は何も感じないか、あるいは特別の人たちが何かやっているらしい、程度にしか認識されないでしょう。

    特別な人たちじゃなくて自分もと思ってもらうにはどうすればいいのでしょう。そのギャップを縮めるにはどうしたらいいのでしょうか。

    コアと言われる部分だけでも Translating WordPress でわかるようにすごく増えてきています。このリンク先から誰でも簡単に参加できるという割にはやってくれる人はとても少ない。

    とは言え、これを全部見る validator は大変。増やすべき。そこで問題となるのは質(「日本語の質」も含む)の維持。どうしたらいいのでしょう。

    具体的な数値目標として言うなら、翻訳について議論できる人 —Slack なら #translate で活発に話ができる人— が30人くらい。

    熱意の再配分

    一方でやりたいことがたくさんあるのに体がひとつしかない。一方で手伝いたいと思っているのにどうすればいいかわからない。その再配分。

    Slack はちょうどいい入り口になれるでしょうか。

    「翻訳」で言うと……
    Translating WordPress で翻訳を突っ込んでくれる人、いまの10倍くらいいてもいい。validator は2,3倍いてもいい。ただし質の維持が大事。

    Codex も10倍くらいいてもいい(と思ったら2014年にアカウント作った人はかなりたくさんいるんだな。でも最近30日の更新を見たらあまり多くない)。英語だけではなくて WordPress の中身もちょっとはわからないとならない。日本語も上手であってほしい。なぜいまの水準なのか。入り口がわかりにくい? 見返りがないから?

    そのほかの翻訳(ドキュメントやビデオ)は、今どうなんでしょう。入り口がわかりにくいんじゃないでしょうか?

    横の連携も大事。

    tenpura さんの意見

    問題(Priority: high)が山積しています。この洗い出しと、担当者の割り当て、進捗状況の管理ができれば

    「問題」そのものが広く共有されていないのかもしれません。まずここで列挙したらどうでしょう。

    横の連携というのか、たとえば日本語作成チームと Codex 関係とその他ドキュメント翻訳者それにユーザー(ベータテスター)が新機能の訳語について話し合う、などは Slack のような場がふさわしいように思います。

    ここまで書いて、「人数を増やすこと」を目標とするのはほんとうは変で、本末転倒のような気もしてきました。

    やるべきこととやっていることがすっきり見とおせるようになっていれば、そして誰かが動いている(あるいは動いていない)様子が見とおせれば、おのずと人も集まってくるようになるかも。

    そのためにも、課題の整理と提示、割振りと進捗管理ができればいいですね。

    WordSlack について

    ついでなので、ここにちょっと書いておきます。

    フォーラムよりも手軽な感じのだと思っています。古いメディアにたとえれば手紙に対する電話のような感じ(多対多なところは違うけど)。

    nukaga さんの

    WordPress プロジェクトに関わりたい日本語話者の、気軽な情報共有場所になると良いなと思っています。

    自分自身が何かをしたいと思った時に、どこから入ったら良いのかわからない部分があったので、“気軽に”発言できる場所があると良いと思っています。

    あたりに共感します。道具あるいはとして大いに期待します。

    いずれにしろ、そこに参加する人たちによって「なるようになる」のだろうし、フォーラムと Slack との主従関係もそのうち変わるかもしれない。前にそれを規定することはないのではと思います。

    まずは多くの人に参加してもらうことですね。その広報というか宣伝というか、を何かやるべきかもしれません。

    フォーラム: その他
    返信が含まれるトピック: 特殊なアクセス制限を設けたい

    確かに特殊ですね。

    一般にありがちなのは「特定IPアドレス以外からのアクセスにはBasic認証をかける」ですが、ちょうどその逆の「特定IPアドレスからのアクセスにBasic認証をかける」というのでどうでしょうか。その特定IPアドレスは自分にする。で、自分はパスワードを知っている、と。

    とはいえ、存在していること自体は知られますし、外に出かけてアクセスされたらそれまでかと。いずれ万全ではないと思いますが……。

    フォーラム: 開発版
    返信が含まれるトピック: wp-config.phpのWPLANGについて

    管理画面の「設定」の「一般」のいちばん下あたりに、「サイトの言語」という設定項目が増えています。

    いま試してみましたら、

    wp-config.php で WPLANG を en_US にしていると、この設定オプションで、日本語/英語を切り替えできます。wp-config.php で WPLANG をまったく設定しない状態でも同じです。

    wp-config.php で WPLANG を ja にしていると、この設定オプションをどちらにしても日本語のままです。

    という状況でした。わかりにくいですね。

    これについてどこかに何か書かれていたかはちょっと覚えていません。まだ検索していません。とりあえず。

    フォーラム: バグ報告と提案
    返信が含まれるトピック: WordPress日本語版ローカライズ

    見落としていました。ご報告ありがとうございました。

    修正します。
    http://translate.wordpress.org/projects/wp/dev/ja/default?filters[original_id]=2672

    フォーラム: バグ報告と提案
    返信が含まれるトピック: WordPress日本語版ローカライズ

    ご報告ありがとうございます。
    %s に入るメッセージによってはおさまりが悪いかもしれないので、とりあえず

    エラーのためプラグインの削除に失敗しました: %s

    と変更しようと思います。
    もしまたおかしいようでしたら、お知らせください。

    フォーラム: プラグイン
    返信が含まれるトピック: 日本語化に関係するファイルは他にある?

    日本語化に関係するファイルを知りたい。プラグインのpoファイル以外に日本語化に
    関係するファイルが他にあるのでしょうか?

    po から生成される mo 以外には、基本的にはありません。

    akausagiさんの状況に即して、ざっと説明します。時間的には逆のほうから説明します。

    (1)
    WordPress が最終的に参照するのは moファイルです。これはプログラムが実際に利用しますが人間が読める形ではありません。moファイルは poファイルから生成されます。Poedit でできます。

    (2)
    poファイルは、人間が読める形で、原文(英文)と翻訳文(日本文)が1対1に並んでいるものです。翻訳作業者が使います。雛型となる potファイルから作って(Poedit でできます)、翻訳作業は人間が行います(Poedit を使って)。

    (3)
    potファイルは、ソースコードのあちこちから、翻訳作業を行うべき文をピックアップしてひとつにまとめたものです。通常、ソースコードの作者がこれを用意します。

    (4)
    ソースコードは当然、作者が編集します。翻訳すべき箇所にはそのための印を付けておきます。

    以上からわかりますように、生成物の最終編集時刻に着目してみると、ソースコードの変更をしたら、それからpotを作るのでpotのほうが新しくなっているべきです。同様にpo, mo の順になっているべきです。

    そこで、WP-Members の現状を見てみましょう。

    https://plugins.trac.wordpress.org/browser/wp-members/trunk?order=date&desc=1#lang

    作者はソースコードのあちこちを修正しているのに、もう15か月もpotファイルを新しくしていないようです。さらに、日本語の翻訳(wp-members-ja.mo)はそれよりも古いままです。

    というわけで、何が起こっているかというと、
    機能が拡張されたり修正されてメッセージが変更されているのに、翻訳がそれに追い付いていない
    という状況です。

    では、どうすればいいかというと、akausagiさんの実施事項というのは、翻訳文に合わせてソースコード側を古いのに戻す、という作業なので、本末転倒ということになります。

    そこで正統な対応は次のようになるでしょう。

    1. まず作者に「翻訳作業をするので、potファイルを最新のものに更新してください」と連絡して、それをやってもらいましょう。(自分でもできますがちょっと道具が必要)
    2. Poedit で 古い日本語の wp-menbers-ja.po を新しいpotファイルと突き合わせます。すると未翻訳がだいたい60個ほど(全体の3分の1ほど)あるでしょうから、これを Poedit で日本語訳を埋めていきます。
    3. 作者に「新しい日本語訳をやりました」と、そのpoファイルを送ってください。
    4. 作者は次の更新のときにきっとそのpoファイルと、それから生成したmoファイルを同梱してくれるでしょう。

    もちろん、この4.を待たずして、自分の手元でpoファイルからmoファイルを作って(Poeditでできます)適切な場所に置けば、自分だけ先にその効果を享受できます。

15件の返信を表示中 - 1 - 15件目 (全48件中)