コンテンツにスキップ

Wikivoyage:水茶屋

話題追加
提供:ウィキボヤージュ
2023年11月12日 (日) 06:06時点におけるTmv (トーク | 投稿記録)による版 (記事の進捗を示すテンプレート: コメント)

最新のコメント:1 年前 | トピック:記事の進捗を示すテンプレート | 投稿者:Tmv

水茶屋(みずぢゃや)はウィキボヤージュ日本語版での、運営や方針、新しいアイディアや作業の仕方、その他様々なことで質問や提案、議論、意見交換を行なう場所です。

水茶屋以外に適切な議論の場所がある場合、投稿がそちらに移動されることがあります。あらかじめご了承ください。

過去ログはWikivoyage:水茶屋/過去ログから探して下さい。

また、以下の検索ボックスから過去の水茶屋の議論を検索できます。


発言する際には、非生産的な争いが起こらないように、以下の点に注意してください。

  1. エチケットに留意して、誹謗や中傷などは避けてください。議論が白熱しても冷静に
  2. 発言の最後に署名を忘れないでください。--~~~~と記入すればOKです。
  3. その他、他のウィキメディア・プロジェクトでの議論スタイルと要領は同じです。概して礼儀正しく発言すれば問題ありません。

ユニバーサル行動規範調整委員会による憲章の査読について(お願い)

皆さん、こんにちは。

僭越ながら、ユニバーサル行動規範をめぐる作業の次の段階をご紹介します。ユニバーサル行動規範調整委員会(U4C)による憲章草案を整え皆さんに査読をお願いできるようになりました。

施行ガイドライン※1には設定委員会※2による憲章の草案のまとめが求められ、これはグローバルな委員会の手順と詳細を概説するもので、その名称が ユニバーサル行動規範調整委員会(略称U4C)※3, 4になります。本日まで2、3ヵ月にわたりU4C 設定委員会では協議を重ね、U4C 憲章草案をまとめました。U4C 設定委員会では2023年9月22日を期日として憲章草案に関する皆さんのフィードバックを募集しています。期日を迎えたら、当 U4C 設定委員会では必要に応じて憲章の改訂に取り組む所存で、そのすぐ後にコミュニティによる承認投票にかけるよう計画しています。(※:1=施行ガイドライン、Enforcement Guidelines。2=設定委員会、Building Committee。3=憲章草案、draft charter。4=ユニバーサル行動規範調整委員会、Universal Code of Conduct Coordinating Committee。)

までの間に、対話の時間もしくはメタウィキのページにてこの協議にご参加くださいませんでしょうか。

よろしくお願いいたします。

RamzyM (WMF), on behalf of the U4C Building Committee, 2023年8月28日 (月) 15:35 (UTC)返信

スコットランドのmarker地図(不具合)

済み

スコットランドの記事で作業中なのですが、テンプレート:marker の地点を、地図画像上に表示するはずがエラーが出ます。エラー文は地点の数だけならぶので、システム上の障害と思われます。エラーメッセージは赤字だし、数行にわたって並ぶとかなり目立ちます。

提案、marker から地図を呼びに行かない処理は可能でしょうか?
問題の影響範囲がわからないため、もしもテンプレートを除去するなどの方法が必要でしたら教えてください。対処してみます。

情報 英語版 Scotland で非表示にしてあるのを確認しました。日本語版だけじゃなさそうです。--Omotecho (トーク) 2023年8月29日 (火) 08:22 (UTC)返信

対処 @Omotechoさん エラーを修正しました (差分). どうやら{{mapshape}}の中で{{仮リンク}}を使うと壊れるようです. この点に気を付ければ, 地図を表示しても問題ないと思います--Tmv (会話) 2023年8月29日 (火) 09:01 (UTC)返信
@Tmvさん、ご多用のところ早速に措置をしていただき、誠にありがとうございます。エラー告知が消えて安心しました。では現状、マーカーの載った地図が表示されない状態であり、これはそのまま進めて良い。認識はあっていますか? 
そうですか、原因は仮リンクですね、しっかり覚えておこうと思います。引数ごとに改行すると回避でのか、いやいや、仮リンク内のラベル引数の位置のせいか? 
_φ(・_・。
結論は様子見にさせてください。地図が見えない状態は、ひょっとして作業途中のせいと感じるからです。
  • 全文訳せていない。未訳で原文転記のママ、コメントアウトした部分あり。
  • その箇所には、{{tl|テンプレート名}}か{{tl:テンプレート名}}に替え、無効化した箇所が多い。
まずはお礼まで。重ねて感謝申します。--Omotecho (トーク) 2023年8月29日 (火) 11:01 (UTC)返信
@Omotechoさん 結論は様子見で, と言っている矢先に口出しして申し訳ないですが, 問題解決の手助けをさせてください.
地図が表示されないのはそもそも地図を表示するテンプレートが使われていないからです. 地図は{{mapframe}}を利用して表示しますが, 見たところ日本語版にも英語版にもこのテンプレートが貼られていません. 「地方」にある{{Regionlist}}の|regionmapsize=350pxの下に|mapframe=yesと書けば地図が表示されると思います. テンプレート:Mapframe/docも参照
余談 : 英語版ではしばしばmapframeが貼られていないことがあります. 個人的には内容の多い, 長い記事でよく貼られていないと感じます. Wikimaniaで上記のDerFussiさんが仰っていたのですが, ウィキボヤージュのページは比較的wikidataから読み込むデータ量が多く, 重くなってしまうことがよくあるそうです. mapframeも外部から情報を取っていますし, 重くなる原因になるため長い記事では除去されているのかもしれません. 今のところ日本語版では除去の必要はなさそうです--Tmv (会話) 2023年8月29日 (火) 11:11 (UTC)返信
ご教示に感謝します。そうか、これなんですね、ドイツ語版で工夫をしたという案件。
ウィキデータとの整合性と処理の重さを天秤にかけること、これは古いスマホなどを使う人を圧迫しそうな課題でしょうか(想像)
すると、スコットランド域内の小規模空港の名称にウィキデータへリンクを付加したので、そのリンクを付け替えようかと思います。
質問 ところで、文中のリンク付き文字列は日本語版で未立項だと、赤色表示(赤リンク)になります。それを補いたい場合、サーバの負担を意識した方が良いでしょうか? 基本線を決めることはできそうかどうか、具体的には、例えば以下の2点からましな方があるなら、覚えておきたいです。
赤リンクを姉妹プロジェクトなどにリンクするとき(=見た目は青リンクになる)。
  1. 他言語版のウィキボヤージュにリンクさせる。(将来の翻訳作業には便利)
  2. 日本語版ウィキペディアへリンクさせる。(読者に便利、日本語で読めるから。)
ムキになって赤リンクに英語版ウィキボヤージュへのリンクを貼ってしまったし、猛省中。--Omotecho (トーク) 2023年8月29日 (火) 11:30 (UTC)返信
@Omotechoさん リンクは基本的にはあまり負担になりません. 大きな負担になるのはwikidataから座標を取って来る{{marker}}や{{mapframe}}, {{mapshape}}などです (特にmapframeは地図が移動する度に情報を取るから重い).
赤リンクを補う方法ですが, どちらもサーバーの負担は同じです. そのため, 機能性を考えて選んでいただければなと思います. 個人的には, 編集中には他言語版へのリンク, 編集が終わったと思ったらウィキペディアへのリンクとしています. 第3の選択肢としてリンクを張らない, というものもあります (見た目はこれが一番スマート). お好みでどうぞ--Tmv (会話) 2023年8月29日 (火) 12:41 (UTC)返信
@Tmvさん、おかげさまでモヤモヤがすっきりしました。いつもありがとうございます。個別の地名は吟味してウィキ間リンクにしろ仮リンクにしろ、絞ろうと考え中です。赤リンクが多いリンク元を作るか記事さえあれば良いか次元は異なるとして、まず乗り継ぎの国際空港のあるアムステルダムを訳し始めました。--Omotecho (トーク) 2023年9月2日 (土) 06:03 (UTC)返信
アムステルダムの街並みも綺麗ですよね. 行ってみたいとは思いながらついぞ行けておりません. --Tmv (会話) 2023年9月2日 (土) 08:59 (UTC)返信

おすすめの旅行先のアイコン

済み

皆様台風は大丈夫でしょうか? ページバナーの右上に表示されるアイコンのうち, おすすめの旅行先のアイコンが未定だったので決めようと思います.

コルシカ島などをみると, バナーの右上に画像の無い黒い枠があると思います (モバイル版では, 他の画像が設定されているものでも画像が見えないのでデスクトップ版でご確認ください). 本来はここに画像を入れるのですが, おすすめの旅行先のアイコンがまだ決まっていないので画像が入っていません. そこで, アイコンをここで決めましょう.

参考までに: 注目の旅行先注目の旅行先, 今月の旅行先今月の旅行先

いくつか案があります:

1は, 英語版で使われているアイコンを登用したものです. 日本語版ウィキペディアの秀逸な記事で使用されているもので, おすすめの旅行先はそれにあたるのでいいと思う反面, ウィキペディアと比べるとやはりクオリティが下である点が気にかかります. 2は, 背景が黒いため目立つと思われる, 2の銀色バージョンです. 3は, 星が付いていて黒い背景に目立つ画像を選びました. 別名「スター記事」なのでやはり星は大事かなと思って選んだものです.

以上3つが現状私の中で候補として浮かんでいるものです. 他の画像も大歓迎ですし, その他意見もよろしくお願いします--Tmv (会話) 2023年9月8日 (金) 05:23 (UTC)返信

返信 どれもすばらしいイラストですが、個人的には円で囲まれたデザインに統一したいので、3がいいんじゃないかなぁ、と思います。-- 愛知特区トーク|投稿記録2023年9月13日 (水) 08:51 (UTC)返信
@愛知特区さん 統一感からいうと私も3がいいと思います.
ただ, 注目の旅行先や今月の旅行先の画像をみると, (その記事が) よくできている, 輝いている, といったようなことをあまり感じないのですよね. 今回の案3についても (悪い言い方をしますと) 少しだけ安っぽさが出てしまっているような印象もあります. しかし1, 2にするとして他の2つを変えるかというとそちらも悩ましい所です...
このまま他の案が決まらなければ3を実装しようと思います. --Tmv (会話) 2023年9月17日 (日) 08:11 (UTC)返信
Tmvさんへ とりあえずは3にして、後に別件としてすべての旅行先のアイコンをそれぞれ決めるのもいいような気がしますけどね...話を広げてしまってすみません。-- 愛知特区トーク|投稿記録2023年9月17日 (日) 13:36 (UTC)返信
対処 そうですね. 全体の一新は別に行うとして, 画像を追加しました. キャッシュの関係でまだ表示されていませんが, 時間の経過により反映されると思います. --Tmv (会話) 2023年9月26日 (火) 11:14 (UTC)返信
感謝 ありがとうございます。-- 愛知特区トーク|投稿記録2023年9月26日 (火) 12:41 (UTC)返信

Info-Button, VCard

Hi Tmv and all Wikivoyagers on Japanese Wikivoyage. Time to start new projects. You asked for the nice info-button as we use it on WV/de. Yeah. Its possible. But its part of our VCard-Module and Template. Its widely complatible to your listings but much more powerful. Besides it can use Wikidata and takes all information from Wikidata, from address to entry fee. I would recommend to use the vcard instead of the old listngs templates. You can just change the name on existing templates. It includes an editor as well. There are a lot of modules to be installed and I need admin rights because some parts are in the Mediawiki Namespace. If you want this feature. Is it possible to apply for admin rights here? I am admin/beaurocrat on 3 other Wikivoyage wikis. If not, I will need somebody I will send the scripts to and instructions what to do till it works properly. And I need your help with translation. The editor and the maintaining categories need translations. We could do it step by step.

So if you make a decission and want to introduce this feature here, drop me a line. -- DerFussi (トーク) 2023年9月22日 (金) 21:13 (UTC)返信

Hope to visit Japan one day and say hello. I planned a two month trip in 2020 but then a virus stopped my plans. Many greetings from the far Germany. -- DerFussi (トーク) 2023年9月22日 (金) 21:13 (UTC)返信

(Japanese translation/日本語訳)Tmvと日本語版ウィキボヤージュのみなさん、こんにちは。新しいプロジェクトを進める時がやって来ました。WV/deにあるような素敵なインフォメーションボックスが欲しいということですが、はい、それは可能です。しかし、それは私たちのVCardモジュールとテンプレートの一部になっています。これは貴方たちのListingテンプレートと広く互換性がありますが、よりパワフルです。加えて、ウィキデータを使ってそこから全情報(住所から値段まで)を持ってくることが出来ます。そのため、古いListingテンプレートに代わってVCardを使うことをお勧めします。今のテンプレートの名前を変えるだけです。そこにはエディター(訳者註:Listing Editorに当たるものだと思われる)も含まれています。インストールすべきモジュールはたくさんあり、いくつかはMediawiki名前空間にあるので、もしこの機能が欲しいなら私は管理者権限が必要です。ここで管理者権限を申請することは可能でしょうか?私は他の3つのウィキボヤージュで管理者/ビューロクラットを持っています。管理者権限をいただけない場合には、スクリプトを送る相手と、正常な動作までの工程の指示が必要です。そして、翻訳をして欲しい。エディターとメンテナンス用カテゴリの翻訳が必要になります。一歩一歩やっていきましょう。

もし、この機能を導入することが決まったら、その時に私に連絡をください。-- DerFussi (トーク) 2023年9月22日 (金) 21:13 (UTC), translated by Tmv (会話) 2023年9月23日 (土) 22:46 (UTC)返信

導入の議論

(English)Discussion on whether to introduce: The Japanese community will discuss whether to introduce this feature. Basically, the conversation will be in Japanese, and DerFussi will be notified when the decision is made.

(日本語)導入の可否についての議論:日本語コミュニティでこの機能を導入するか議論します。基本的には日本語で話し、結論が出たらDerFussiさんにお知らせします。

コメントこれまでの話を簡単に要約すると, DerFussiさんから「何かここで手伝えることはあるか」と聞かれ, 私が以前より気になっていた情報ボックス機能について尋ねたところ, ここでも使えるとの事で上記の話に至っています.
例えばこちらを見ると, 「世田谷 磯野」などの各リストの後ろに「info」というボタンが設置されており, 押すとそのリストの情報を見ることが出来ます.
日本語版では, リストが長くなる傾向にあり, トゥールーズ#トゥールーズ博物館などを見ると区切りが分かりづらいです. そのため, この機能を日本語版にも欲しいと思い, 話がここまで膨らみました.
VCardの導入に関しては, 全情報をウィキデータから取ってくるというのはかなり魅力的だと思います.
以上より, 情報ボックスとVCardの両方に 賛成します. --Tmv (会話) 2023年9月25日 (月) 00:38 (UTC)返信
  • 情報 ありがたいことに導入の方法が英語で公開されています。--Chqaz (トーク) 2023年9月25日 (月) 04:39 (UTC)返信
    返信 本当ですか, ありがとうございます. ただ, せっかく開発者本人がいらっしゃっているので, 少し我儘を言っても許されるでしょうか. そのページによると, type引数はseeやdoからrestaurantやcafeになっており, より具体的にされているようです. しかし, 現在の日本語版ではseeやdoでうまく回っていると思いますし, しばしば同じタイプでも色分けすることがあります (ex. 群馬県#高速道路). そのため, ここの部分に関しては同じ仕様でいいと思っているのですが...
    さらに, 日本語版ではいくつかの独自の仕様があります. 例えばlink引数であったり, 或いは地図上の「詳細」ボタンなどです. これらもi18n他で設定しなければなりません. --Tmv (会話) 2023年9月25日 (月) 13:26 (UTC)返信
    @Tmv 個人的には導入はしなくていいと思っていますがinfoのボタンは便利そうだなと思いました。--Chqaz (トーク) 2023年9月26日 (火) 03:30 (UTC)返信
    質問 @Chqazさん 導入の必要がないとお考えなのはVCardのことでしょうか? 出来ればその理由も知りたいです. --Tmv (会話) 2023年9月26日 (火) 09:31 (UTC)返信
    VCardのことです。listingで十分だと考えています。(区切りがわかりずらいのは改善すべきですが)--Chqaz (トーク) 2023年9月27日 (水) 00:17 (UTC)返信
    @Chqazさん 区切りがわかりずらいことに関しては, 情報ボックスで見やすく出来るので大丈夫です. ただ, Listingをわざわざ人の手で一々更新するのは, 人数が少ないこのプロジェクトでは少々非効率だと思います... --Tmv (会話) 2023年9月27日 (水) 08:08 (UTC)返信
    @Tmv listingに少し編集するとwikidataから一部データを取得できると思います。--Chqaz (トーク) 2023年9月29日 (金) 00:47 (UTC)返信
    @Chqazさん 単純にWikidataを呼び出すだけだと様々な問題が発生します.
    まず, 1記事で何度も呼び出されるListingテンプレートで複数のWikidataクエリをリクエストするとAPIの呼び出し回数が多すぎて非常に重くなり, 大きな記事ではタイムアウトすることがあります (Wikimaniaで紹介されていました). VCardは1回のクエリで予め全ての値を取得しているため, リクエスト回数が遥かに減ります. これには, Luaなど何らかのプログラミング言語で記述する必要があり, 1から作るには非常に労力がかかります.
    また, パラメータの確認も必要で, パラメータが間違って使われている場合はもちろん, 電話番号のフォーマットが間違っている ({{phone}}についての詳しい解説は日本語版にまだありません), directionとaddressの混同, さらに (私も幾度もやった覚えがあり直せていませんが) メニューを書く場所がバラバラで統一されていないなど, パラメータの曖昧さゆえに統一されていない部分が多々あります. これらのフォーマットを確認するためにはモジュールを使用する必要があります
    他にも, Listingテンプレートの詳細なカテゴライズなど, VCardの方が遥かにパフォーマンスがいい面がいくつかあります.
    とはいえ, タイプの変更などはしたくないからListingをそういった仕様にする, という案もあります. が, 情報ボックスを導入するならばListing用に書き換えないといけないなど, そちらの方が茨の道だと思います. --Tmv (会話) 2023年9月29日 (金) 09:40 (UTC)返信
コメント VCardの利点と不明点を整理しませんか? ウィキデータは多言語前提で、「水茶屋」の呼び名が「旅人の酒場」(Tavern)でもなんでも、同じ実体1個に集約される。その看板(Q番号)の下位に、バリエーションを束ねてある感じ。利用者の表示言語を反映して、それぞれの属性を表示するようです。
質問 VCardの仕掛けとは、以下の理解で正しいですか? (voy)ウィキボヤージュに「VCard」テンプレートを置いて属性を指定(Go/See/Doなど) → (wd)(voy)ウィキデータで情報が更新されると、ウィキボヤージュに自動的に反映される(複数ページだろうと予想)。
  1. 基礎情報ボックス(infobox)も、もしかしてVCard側の調整で自動生成されたりすると、データ関係が一意になるものでしょうか?
  2. 【例】(wp)フランス語版のウィキペディアで日本の姉妹都市の記事が立つ → (wd)ボットがその情報を拾ってウィキデータに反映。 →(voy)今のListingに似た表示になる。 →
  3. 利点=日本語版ウィキボヤージュで編集をしなくても、情報が更新される点(どの情報が? 利用料などは手作業が残る?)
  4. 不明点=ウィキデータの保守・不正行為対策がどれくらい信頼できるか。
@Tmvさん、ウィキデータから具体的にVCardが読み込む属性は、対応表があるとわかりやすいかもしれませんね。(Go/See/Doなどにどうやって割り振るのか?)
  • ウィキデータのQ番号=語彙素 → voy とのリンクの鍵?
  • wd の属性で voy に呼べるもの。
    • 位置座標 → 地図の描画に利用
    • 州、道、府、県、都市のデータ、その子項目
    • 世界遺産や記念物?
--Omotecho (トーク) 2023年9月27日 (水) 04:04 (UTC)返信
回答 えっと, まずVCardは現在の日本語版ウィキボヤージュでいうListingと同じものという点を確認しておきます.
その上で, 現在では観光地1つ1つに住所や電話番号などを書き込んでいたところを, 代わりにウィキデータの語彙素番号 (Qから始まるもの) を書くだけでそれらの情報が自動で表示される. これがVCardです.
  1. Infoboxに関しては, VCardとはなんらの関係もありません (VCardは目的地のリスト, 対してInfoboxは記事の概要を示す1度だけのボックス). Infoboxもウィキデータから情報を表示することは出来ます (現にそうなっている) が, それはVCardのウィキデータから情報を取得する機能とは関係ありません.
  2. いくつか確認を. まずなぜフランス語版ウィキペディアの話なのかよく分かりませんが, どのプロジェクトにしろ記事が作られてからその情報が反映されるまでは全て手作業です. 確かにBotを使うと非常に便利な箇所かもしれません. wd→voyについてはその認識で間違いありません.
  3. 利点:ウィキデータから自動で情報が表示され, 向こうの更新も勝手に反映されること. どの部分が自動かは私もよく知らないので後で確認します.
  4. 不明点:ウィキデータは利用者の数が非常に膨大ですから, 荒らしを確認している目もこちらとは比べ物にならないほど多いです. そのため, 荒らし等はむしろウィキデータの方が早く見つけてくれるでしょう. もし間違ったデータが表示されているなら, ウィキデータを編集すれば事は済みます. ウィキボヤージュから直接ウィキデータを編集するツールがあるといいかも?
上でも述べましたが, typeがより具体的になっているようです. より詳細にパラメータを定義するよりは, 今のままでいいかな, とは思っております. --Tmv (会話) 2023年9月27日 (水) 07:26 (UTC)返信
情報 もう一度VCardについての疑問点や懸念, そして利点等を整理したいと思います. 疑問・不明な点等ありましたらお気軽にコメントしてください:
vCardって?
  • 現在の日本語版でいう{{listing}}, つまり観光地やホテルなどのリスト1つ1つに使うテンプレートです. Listingの代わりにvCardを使っていくことになります.
vCardの利点は?
  • 日本語版ウィキボヤージュにデータを書くのではなく, ウィキデータにデータを書いてそれを取ってきます. これにより, 日本語版と同時にドイツ語版など他の言語版も逐一修正する必要がなくなり, ウィキデータを編集すればvCardを使用している全ウィキに変更が反映されます
※Omotechoさんの質問「どの情報が取ってこられるのか」は後述します
今までのListingと大きく変わるとついていけない
  • 編集者目線で目立った違いと言えば, typeの違いです. 日本語版はsee, doなどですが, ドイツ語版ではrestaurant, museumなど具体的になっています. これらは不要であれば除去できると思います.
今までのListingの修正が大変では?
  • 今までの{{Listing}}は{{vCard}}の別名となり, 編集せずともそのまま使用できます.
情報ボックスって?
  • ドイツ語版で, VCardに「info」ボタンを追加して「住所」「値段」等々の情報を全てポップアップで表示する機能です. 文章でだらだらと表示されているよりはるかに見やすい
Listing Editorはどうなるの?
  • vCard用に書き替えます. ドイツ語版のListing Editorに日本語版独自の機能を追加する形です.
他に質問がありましたら下でお願いします

また, 議論すべき点は以下です:
vCardを導入するかどうか
  • 根本的な部分になります. vCardなしでinfoボックスありだと少々プログラムが大変になります. 以下のvCardに関する詳細についての議論を踏まえて最終決定?
パラメータをどうするか
  • Omotechoさんの質問にあった, 自動で値を取得するパラメータは以下になります (参照):
・agoda ・Booking ・checkin ・checkout ・dav ・directions ・directionsLocal ・email ・expedia ・facebook ・fax ・flicker ・foursquare ・googlemaps ・histhotelsAm ・histhotelsEu ・histhotelsWw ・hostelworld ・hostels ・iata ・icao ・image ・Instagram ・kayak ・leadinghotels ・mobile ・oeav ・payment ・phone ・preferredHotels ・price ・pzs ・recreation ・relaisChateaux ・rss ・sac ・skype ・skyscanner ・subtypeAdd ・tiktok ・trip ・TripAdvisor ・twitter ・unesco ・url ・youtube
  • 多くが外部サイトとなっており, 他にemailやfaxと言った日本語版にもあるパラメータ, そしてiataなどと言った日本語版では別の部分に含ませているもの (IATAコードは日本語版ではaltパラメータに{{IATA}}を使用して記述しています) があります. これらを踏まえて, パラメータは何を使うのか議論していく必要があります.
typeを変更するかどうか
  • 現状の日本語版はseeやdoなどといった{{maplayers}}にあるものを採用しています. 一方, ドイツ語版はrestaurantやcafe, museumやcastleといったより詳細なタイプを使用しています. おそらく詳細な方が, そのリストに合ったパラメータを利用できる (airportのリストにだけIATAを有効にするなど) ためでしょう.
  • こちらを見てもらえればわかるように, seeやdoなどは「group」に名前を変えて存在しています. typeに「museum」と書けば勝手にgroupが「see」になる, といった形で自動で振り分けているのです (そのためmuseumやmonumentは水色, ferryやairportは赤色など, 色は現在と変わりません).
情報ボックス導入の是非
  • 情報ボックス (上で説明) を導入するか否か.
長くなりました. これで基本的な情報はカバーできたかと思います. 決めることが複数ありますが, vCardと情報ボックスといった具合にセクションを分けた方がいいでしょうか? --Tmv (会話) 2023年10月4日 (水) 08:14 (UTC)返信

投票

ひとまずはVCardを導入するか否かについて投票を行いたいと思います. 上記議論すべき点は可決された際に議論しましょう. なお, 賛否がそちらの議論によって変わるような場合には, 条件付賛成または 条件付反対をお願いします.

質問があれば上の「導入の議論」へ.

賛成
  1. 賛成 --Tmv (会話) 2023年10月14日 (土) 08:36 (UTC)返信
  2. 条件付賛成 --Omotecho (トーク) 2023年10月14日 (土) 15:22 (UTC)返信
  3. 賛成 --職員室(トーク投稿記録) 2023年10月18日 (水) 11:22 (UTC)返信
反対
コメント

  1. リンク元の分類表にアルファベット順でテンプレートのパラメータを省略形で記載、テンプレートのパラメータの翻訳用に用いる。
    • 「address-lang」などの項目値は、テンプレートで使うパラメータ名です。
    • キー/インデックスはマーカー・モジュールが使う。翻訳には値文字列を使用。
    今も使っている引数
    (a)データ: ・checkin ・checkout ・directions ・email ・fax ・phone ・price ・tollfree ・url
    (b)現状で使用、 ・googlemaps(Maps.Google.com) ・image
    (bー1)独自テンプレートに収容:・iata ・icao
    (bー2)テンプレートは無いが別のパラメータに収容(丸カッコ内は日本語版のパラメータ名、△記載の前例がない):・directionsLocal ・mobile(phone△) ・payment(price△)
    追加するかどうか検討する引数(Wikidata に連動)
    (c)商用予約サイト: ・agoda ・Booking ・dav(Alpenverein.de)・expedia ・foursquare ・"※"HistoricHotels.org傘下3社(・histhotelsAm ・histhotelsEu ・histhotelsWw) ・hostelworld(Hostelworld.com) ・hotels(Hotels.com) ・kayak(Kayak.com) ・leadingHotels(LHW.com) ・oeav(Alpenverein.at)・preferredHotels(PreferredHotels.com)・pzs(PZS.si スロヴェニア) ・relaisChateaux(RelaisChateaux.com) ・sac(SAC-CAS.ch) ・skyscanner(Skyscanner.com)・trip(Trip.com) ・TripAdvisor ・rss
    (cー1)SNS:・facebook(無印) ・flickr(無印) ・Instagram(無印) ・skype(無印) ・tiktok(無印) ・twitter(無印) ・youtube(無印)
    (cー2)その他サービス:・googlemaps
    (d)分類不明: ・ useIcon(internal use) ・recreation(ウィキデータ経由Recreation.gov) ・subtypeAdd(internal use) ・symbol(internal use)・text(internal use) ・unesco(mi.options.showUnesco)
    1. ドイツ語版の目次
      • Importing modules(モジュールの移入)
      • Modules needed(必要なモジュール)
      • Localization(翻訳・ローカル化)
      マーカテンプレート導入の場合は3件の翻訳を揃えるとよい由。
      1. VCard/i18n(VCard国際化)
      2. Marker/Params(マーカのパラメータ)
      3. Marker utilities/i18n(マーカのユーティリティ)
      • Registration at Wikidata(ウィキデータに登録する)
      • Naming of templates(テンプレートの命名規準)
      • Styles needed(スタイル設定)
      • Template calls(テンプレートの呼び出し)
      • Additional tools(VCardの移入#追加のツール)
      • Maintenance(VCardの移入#メンテナンス)
  2. 原文の「注記」より。
      • このテンプレートはウィキデータに最大限に対応します。そのため、ウィキデータからのデータ取得に膨大な計算時間がかかるため、実装が困難になりました。ほとんどの場合に、テンプレート単位でQ番号付きデータセット1件のみ呼び出せばよい方法を見つけた(従前は10~30件)とは言え、必要時間は従前と同じくらいです。例えば、ウィーンとハレ(ザーレ)でテストした場合。前者の記事はリスト項目268件、マーカ55項目を使います。そのうちの216件はウィキデータからデータを取得、しかし計算時間が長い主な原因は<maplink> 呼び出しで、約40%を占めます。
      • 「テンプレート:ウィキペディア」のパラメータは使用をやめました。対応は削除もしくはウィキデータに置換願います。ただし下位互換性には、限定的なサポートがあります。
      • タイプのテンプレートのパラメータは、元のパラメータと異なります。「see」「do」などは、旧タイプは現状のタイプと変わりました。これらは同じ論文の見出しの部分を要約し、見出し内の異なるタイプは区別できません。ウィキデータへの自動転送は無意味ですから、これらは非推奨にしました。新しい VCard/リストでは、用語2つを用いるようになりました。「type」はレストランやカフェ、教会やダムなど、より具体的な種別になり、便宜上の理由から「see」「do」などの値を持たせることも可能。すべてのタイプが属する「group」は、従来の「see」「do」などの意味を引き継ぎます。「group」パラメータを使うと自動的に推定される「group」への所属を上書きできます。古い一覧テンプレートのうち、滅多に使わない「group」は、パラメータ名を「map-group」に変更しなければなりません。
      • 国際化をしようとすると、翻訳には時間がかかります。およそ1週間くらい見込んでください。
      • 過去にどれほど間違いが多かったか驚くでしょう。私たちの経験から言えるのは、すべての記事の約10%に間違いがあります。ほとんどのエラーは、名前、URL、電話番号、電子メールアドレス、またはパラメータ名の誤記が原因で発生します。修正は主に手動で、おそらく数週間かかります。
      • パラメータ名、タイプ、グループ、サブタイプにエイリアスを付けることができます。
      • パラメータの形式を検査。
      • ウィキデータからデータを採取。
      • カテゴリの分析には以下を使用。

設定等の議論

投票開始から1週間以上経過し, 賛成あるいは条件付賛成票が3票, 反対意見はありませんでした. 現在ウィキボヤージュで活動している人数を考慮すると, vCardは導入することと判断してよろしいかと思います. Omotechoさんの仰る通り, パラメータをはじめとした諸設定は今後評議が必要ですが, それらについての議論に移行してよろしいでしょうか? --Tmv (会話) 2023年10月23日 (月) 11:06 (UTC)返信

質問 @Tmvさん、今更なのですが、技術面で導入の準備は過重なご負担にはなりませんか? そこがOKなら変数ほかの協議へ進みたいです。--Omotecho (トーク) 2023年10月23日 (月) 16:43 (UTC)返信
回答 同じくvCardが導入されているエスペラント語版とスペイン語版ではパラメータ等は変更されていなかったため, 初の試みとはなるでしょう. とはいえ, 先方は有難いことにそういったカスタムを想定して作ってくださっている様ですので, そこまで難航することはないと思います. --Tmv (会話) 2023年10月23日 (月) 22:57 (UTC)返信
返信 承知しました。お手伝いできる点が見えてきたら相談させてください。
だんだん具体的な疑問が見えてきました。手間なく情報が増えるのは歓迎、懸念はウィキボヤージュの実用性と、欲を出すなら情報の鮮度が担保できるかどうか。以下、順不同で、またあくまでも理屈なので、手間と天秤にかけましょう。
先般、ウィキデータで基礎自治体の基本情報の洗い出しにお力添えをいただきました。それを足場に、2つのウィキの連携に関心が湧きました。
質問 ウィキデータから引いてくる情報が、向こうで日本語になっていない場合。
  1. ウィキボヤージュでは原語で表示される→表示言語の指定は可能か?
  2. データは移入されない。
質問 ウィキデータのデータ更新は、どうやってウィキボヤージュに反映されるか?
  1. 向こうで日本語化すると、ボットか何かで(定期的に)更新。▼(詳細は要確認か)手順は自動化。頻度は日本語版ウィキボヤージュ側で決めるのか。
提案 ウィキデータから移入しない変数はどこに記録するか。(見直しはいつ?)
未定 番外編=
ウィキデータにおんぶに抱っこで良いかどうか。(利用者の人数が少ないながら相身互いの志として)
希望 姉妹プロジェクトへの波及効果
たとえば来日観光客なら、日本語版ウィキボヤージュを機械翻訳にかける。リンクのある情報をウィキデータに読みに行く。すると母語で情報を得たり、ひょっとしてウィキペディアを読みに行く。
わずかであっても、見た目、ウィキボヤージュから利用者を姉妹プロジェクトに〈送客〉するんじゃないかと妄想します。--Omotecho (トーク) 2023年10月24日 (火) 04:53 (UTC)返信
セクションを分けました

回答 少々技術的な話にはなりますがご了承ください.
まず, ウィキデータはありとあらゆる情報のデータベースとして開発されているため, ウィキデータの情報は全て取ってこれると解釈していいです. 何語と指定をすれば, その言語での名前, 説明, 別名など欲しい情報を全て取得できます.
2つ目については, 少々ややこしい話になりますが以下の通りです:
まず, ウィキデータの情報は, ウィキデータからウィキボヤージュに取る作業は必要ありません. というのも, ウィキデータにある情報をウィキボヤージュにコピーしてくるのではなく, ウィキデータから直接表示するのです.
直接と言ってもあまりピンと来ないかも知れませんので, もう少し具体的に. vCardが読者に表示されるプロセスを示します:
  1. 編集者が, ある記事にとある名所αについて, ウィキデータの番号と紹介文のみを書いたvCardを追加
  2. ウィキボヤージュの記事には, そのままウィキデータの番号と紹介文が保存される
  3. 読者がページを開こうとする
  4. vCardのプログラムが, ウィキボヤージュに保存されているウィキデータの番号から, 情報を勝手にとって表示する
  5. 読者の画面には, ウィキデータの情報が自動で補填されたαの紹介が表示される
ウィキデータの情報のかわりに独自の情報を表示したい (例えば電話番号), という場合にはウィキデータの番号や紹介文とともに, 電話番号の情報を記入します. すると, vCardがウィキデータから情報を取ってきて表示する時に, 「電話番号はもう知ってるからいらない」と言ってウィキデータから取ってこないのです.
ウィキデータから移入しない変数については, 今まで通りウィキボヤージュに書けば問題ありません.
長く, 少々ややこしいですがこういった仕組みになっています--Tmv (会話) 2023年10月24日 (火) 10:07 (UTC)返信
質問ウィキボヤージュのデータはウィキデータの方移入されるのでしょうか?--Chqaz (トーク) 2023年10月26日 (木) 11:32 (UTC)返信
回答 @Chqazさん ウィキボヤージュに書くとウィキデータに勝手に移入はされません. 極力情報はウィキデータに追加・編集し, ウィキボヤージュに書かれているものはListing Editorなどで簡単にウィキデータに移せるようにできればと思っています. 或いはボットでウィキデータに自動的に移入するのがいいでしょうか? --Tmv (会話) 2023年10月26日 (木) 11:51 (UTC)返信
提案 #投票の最下部でOmotechoさんがまとめてくださった(a)~(d)のパラメータを, グループごとに導入するか否か決めていきたいと思います.
  • (a)データ: ・checkin ・checkout ・directions ・email ・fax ・phone ・price ・tollfree ・url
  • (b)現状で使用、 ・image
    • (bー1)独自テンプレートに収容:・iata ・icao
    • (bー2)テンプレートは無いが別のパラメータに収容(丸カッコ内は日本語版のパラメータ名、△記載の前例がない):・directionsLocal ・mobile(phone△) ・payment(price△)
  • (c)商用予約サイト: ・agoda ・Booking ・dav(Alpenverein.de)・expedia ・foursquare ・"※"HistoricHotels.org傘下3社(・histhotelsAm ・histhotelsEu ・histhotelsWw) ・hostelworld(Hostelworld.com) ・hotels(Hotels.com) ・kayak(Kayak.com) ・leadingHotels(LHW.com) ・oeav(Alpenverein.at)・preferredHotels(PreferredHotels.com)・pzs(PZS.si スロヴェニア) ・relaisChateaux(RelaisChateaux.com) ・sac(SAC-CAS.ch) ・skyscanner(Skyscanner.com)・trip(Trip.com) ・TripAdvisor ・rss ・recreation(ウィキデータ経由Recreation.gov)
    • (cー1)SNS:・facebook(無印) ・flickr(無印) ・Instagram(無印) ・skype(無印) ・tiktok(無印) ・twitter(無印) ・youtube(無印)
    • (cー2)その他サービス:・googlemaps
  • (d)分類不明: ・ useIcon(internal use) ・recreation(ウィキデータ経由Recreation.gov) ・subtypeAdd(internal use) ・symbol(internal use)・text(internal use) ・unesco(mi.options.showUnesco)
(a)は現在も使用しており, 導入するということで問題ないでしょう. (b)については, 個々に議論する必要がありそうです (取り敢えずは他のものを先に決めます).
(c)についてなのですが, 全サービスをカバーすることは不可能であり, 例えばここではニコニコ動画・Threadsなどのサービスは入っていません. このようにどうしても偏ってしまうため, WV:TOUT (Chqazさんが利用者:Chqaz/WV客引きはしないで一部翻訳してくださっています) に抵触する可能性があります. 公平性を求める以上, これらのサービスの情報は使わない方がいいと思うのですが如何でしょうか.
(d)についてはパラメータの意味から考えなくてはなりません. 「internal use」, つまり内部で使用すると書かれているパラメータは, その名の通りテンプレートのシステムで使いますのでそのまま導入することになります (この議論が落ち着いた後に話し合うタイプの導入の可否によって一部導入しないこととなりますが). recreationについては予約サイトらしいので(c)に移動しました. ユネスコは悩みどころで, フランス語版のListing (vCardではない) でもユネスコのアイコンが使われていたりとかなり便利な機能です. 世界遺産に登録されているかどうかは読者に有用だと思うので, こちらは導入で如何でしょうか?
なお, 上記のパラメータは「ウィキデータからとって来る」パラメータです. そうではない (ウィキボヤージュに直接書いてあるときだけ表示される) パラメータもありますのでこちらも今後協議しなくてはなりません. 歩一歩と進めておきましょう--Tmv (会話) 2023年10月29日 (日) 09:15 (UTC)返信
では1件ずつ。
賛成(a)--Omotecho (トーク) 2023年10月29日 (日) 10:55 (UTC)返信
保留(c)商用のホテル予約サイト。
コメント ドイツ語版の判断基準が知りたいです。なぜこんなにたくさん載っているのか、(財団側の)集金装置なのか? こっち方面、理解できてません。
予約情報は購買力を示すので、ウィキボヤージュ経由でリンクを開いて予約したら、何かリスクはあるのでしょうか?(詳細をお聞きしても話題から落伍しそうです)
  • 質問1:利用者がお得・便利か?(cー1も) 
    • 自分が登録しているサイトでポイントがつく? 
    • 予約サイトのアプリとリンクしてて、より新鮮な観光情報や運休・臨時休業の情報が読める?(それにしてはアイコンがない)
    • 予約日の直前に「お忘れなく」とメールが来る?
  • 質問2:財団に紹介料が入るのか?
保留(cー1)SNS、ニコニコなど動画系。
保留(cー2)その他サービス:googlemaps。
  • 質問3:OSMと両方揃えるメリットがあるのか? それは何か? 緯度経度を入力しなくて済むから手間が省ける?
  • 質問4:ウィキデータは、日本ローカルの商用サイトも情報がほしいのかどうか(禁止しているか・いないか。)
--Omotecho (トーク) 2023年10月29日 (日) 11:23 (UTC)返信
回答 現状で答えられる部分を先に回答しておきます.
質問1質問2: ウィキボヤージュから開くとお得になること, そして財団に紹介料が入ることは無いと思います. それは一種の広告であり, 広告なしで完全ボランティアでやっていると謳っている当プロジェクトでそのようなことがあってはなりません. ウィキボヤージュから開くとお得になる, ということに関しては, 当プロジェクトの中立性にも違反します. (ドイツ語版のやり方も中立性に則っているか怪しい所です)
質問4: 質問の意図がよく読み取れないのですが, ウィキデータは日本の商用サイトのデータも求めているのか, という意味でよろしいでしょうか?
他の点に関しては先方に質問しておきます--Tmv (会話) 2023年10月29日 (日) 11:50 (UTC)返信
「質問4」はデータ提供を期待されているかです。ウィキデータでも中立性の話題は嫌というほど読んだのに、そこから取ってきて記事になると「商用リンク盛り盛りにできる」のか、そんなバカなことはないだろうと迷走してしまいました。
説明書を読んだだけでアタフタしただけかも。前提が間違っていると気づきました。
ウィキデータの「ホーチミン市」には商用サイトのリンクはありません。ということは、商用サイトの引数を「いらない」にすれば、安心できますか? 
おっしゃる通り、日本語版ウィキボヤージュは中立を貫きたいです。そこさえ固まっているなら、私が出したどの質問の解も明確でした。それ以上はシステムを信頼しないことになってしまいますね。
(反省室:「ウィキデータって何でもありなのか?」と疑い妄言を発してしまいました。)
--Omotecho (トーク) 2023年10月29日 (日) 13:13 (UTC)返信
情報 一応, ウィキデータにはアゴダのホテルID (P6008)Google マップカスタマー識別子 (P3749)などのプロパティがあります. ドイツ語版ウィキボヤージュではこれらウィキデータに存在するプロパティを実装したそうです. 「読者がウィキボヤージュ外部の情報を求めていたり, 或いはすぐにホテルを予約したり, もっとレビューをチェックしたりしたい場合にそれらの情報を提供します」とDerFussiさんが仰っていました.
ドイツ語版でもあまり商用サイトのリンクが見つからないのは, 単にウィキデータにリンクが保存されているケースが少ないためだと思います. 中立性維持のためには, 使わないべきでしょう. (c)も導入せずでいいでしょうか?
また, ぼちぼち翻訳も進めていこうと思います. ドイツ語版のリストの上から順にやっていきます. --Tmv (会話) 2023年10月30日 (月) 10:03 (UTC)返信
ご確認、ありがとうございます。ウィキデータに情報精度も鮮度もお任せなら、神経質になるのはやめます、餅は餅屋だし、向こうは人数も多いですから。
分岐:VCardで仕掛けして、ニコ動でもなんでも、手入力のウソ情報防止ができますか? 
仮説:ウィキデータ側でコントロールしてもらうから、増える情報はクリーン。なおかつ、ウィキボヤージュの管理者さんの手間を省けることを大事にしたいです。
  • ウィキデータにお任せできる=(c)賛成。商用、SNS,その他サービス(googlemaps)を組み込む。
  • ウィキデータべったりの仕掛けにすると、かえって手間が増える=(c)全部、1年ほど保留。
賛成でも保留でも、(c)の情報リスクの評価と、出遅れた時のロスがどちらも低いと予想します。ウィキデータの自治におもねる形ですが。--Omotecho (トーク) 2023年10月30日 (月) 11:17 (UTC)返信
コメント 少々話が食い違っていませんか? 私としては, ウィキデータにはあるものの依然中立性の疑問が解決できないため, (ウィキデータや独語版では採用しているかもしれないが) 日本語版ではやめておこうという意見です. 読み返すと少々言葉足らずでした, すみません
採用する場合にはウィキデータを完全自動に利用できるため作業は大幅に少なくなります. --Tmv (会話) 2023年10月30日 (月) 11:29 (UTC)返信

地理情報を増やそう(ウィキデータの企画)

済み

ウィキデータの企画で少しこちらに関係がありそうなものの情報です。観光情報ではなく、地理情報を増やそうというプロジェクトが立ち上がりました。

趣旨:共通のデータベースであるウィキデータに、行政区分など地理的な情報を補完しよう。 実数に対して、ウィキデータでヒットするするように、足りないデータを加筆する活動。

アルジェリアの例を見てください。都道府県に当たるレベル1から基礎自治体(同3)もヒットしますね。日本は都道府県単位で止まっていて、これは項目名などの英訳がまだまだ足りないのだと推測します。ラベル名がローマ字になるだけで、ヒット率は上がる???

凡例:
  • 国名(ウィキデータのQ識別子)
    • レベル(数値) / 種別 / 数量 / 完了・未完・ヒット件数(以下、found)など

  • アルジェリア (Q262) administrative territorial entity of Algeria (Q6721654) / 
    •  1 アルジェリアの地方行政区画 (Q240601) / 48 / 完了
    •  2 アルジェリアの郡 (Q2614970) / 553 /  536 ヒット
    •  3 アルジェリアの基礎自治体 (Q2989398) / 1,541 / 1,535 found

日本 (Q17) レベル分けが不全で、中分類は並列になっていて、分岐していない。

日本の行政区画 (Q1850442)ISO 3166-2:JP (Q456671) / 47 都道府県, 1,719
日本語化できてないのですが、便利そうなら10月に取り掛かる気持ちが湧きそうです。

--Omotecho (トーク) 2023年9月23日 (土) 13:57 (UTC)返信

コメント なるほど, ウィキデータの地図の情報を充実させる企画ですね. ウィキボヤージュに情報を書くよりも, 共通データベースであるウィキデータを利用する方がいいと思っている当方ですので, (日本だけでも) 参加してみたいです--Tmv (会話) 2023年9月26日 (火) 09:38 (UTC)返信
そうですね、ここに引用したプロジェクトは、有り体に申すなら少し前進すれば上等ではないかと思います。「よし、できた」と手を放せる里程は、どのくらいでしょうね。標準値が出せない気がします。
ページ数(語彙素)のめど
(少)▲【2桁】←(どこらへん?)→【4桁】▼(多)
  • ウィキデータの日本の市町村プロジェクト]
  • ウィキペディアのw:ja:プロジェクト:日本の市町村
  • 左辺なら、政令指定都市くらい。50件未満?
  • 中間なら、ウィキボヤージュの骨組み(スケルトン)に収まるレベル。
  • 右辺なら、村まで? 2000件未満?
ウィキデータは無味乾燥かと思い込んでいましたら、緯度経度を読み込むとウィキボヤージュに地図も描けると教わりました。座標の話になったついでに、数値データは手作業を挟まないで機械的に移入し、精度を優先するものかなと漠然と理解しています。--Omotecho (トーク) 2023年9月26日 (火) 11:51 (UTC)返信
@Omotechoさん 2,000件はとてもではありませんが手に負えませんね... ウィキペディアに助っ人を頼んだとしても1,000弱が関の山ではないでしょうか (1,000でも多すぎると思います). ちょうど#Info-Button,_VCardで議論中ですが, 独語版のVCard (日本語版でいうListing) を使うとListingのほとんどの情報がウィキデータからとって来れるそうです. --Tmv (会話) 2023年9月26日 (火) 13:55 (UTC)返信
User:glglgl 制作、User:UkainoADX 翻訳、CC BY-SA 4.0、ウィキメディア・コモンズ経由
そうですね、2千点をどう達成するか考えても、もう一段先の査読の精度と折り合いがつかない、するとVCardで読み込んでも虚しい。
あるいはまた、そのドイツ語版が苦戦しているのも宜なるかなです。
  • ドイツ (Q183)
    • administrative divisions of Germany (Q3879179) /
    • ISO 3166-2:DE (Q27895) /1
    • ドイツの地方行政区分 (Q1221156)/16 完了
      • ドイツの行政管区 (Q22721)/19 完了
      • ラントクライス (Q106658)/401(10万都市107を含む) 未完了
      • Gemeindeverband (Q13405470)/ 未完了
      • ドイツのゲマインデ (Q262166)/ 未完了
--Omotecho (トーク) 2023年9月26日 (火) 19:35 (UTC)返信
コメント とりあえずは, 都道府県から埋めていきましょう (まだどの階層にもdoneはついていない). 因みに, 一般市等のレベルが2で, 市区町村等のレベルが3なのはおかしくないでしょうか. 一般市や政令指定都市などは3+に入り, 県が2に入る方が適切な気がします (レベルの認識はこれで合っている? ). --Tmv (会話) 2023年9月26日 (火) 22:55 (UTC)返信
返信 @Tmvさん、失敗しました! おっしゃる順序です。市町村1500件未満から上位の区分を拾おうとしたら、政令指定都市20件は見つかったものの、あまりの数字の落差を埋めようと画策するうち、数字の大きさなのか、行政上のレベルなのか混乱。中学校の教科書から出直さねば(汗)。
賛成 今回の作業目標で市のレベルまで掘り下げないのは賛成です。
(余談)
それにしても単純にウィキデータ側の興味ですが、文化のメガネで眺めるなら「市」のレベルではザルの目が粗すぎるように感じます。しかし日本にある郡部を拾おうにも郵便番号簿しかない?(郡長職がもうない?) 日本の郡の一覧はドイツ語版にならあるので、ドイツも郡レベルだと帰属意識が別れるなど、意識が似ているのか? 興味シンシンです。--Omotecho (トーク) 2023年9月27日 (水) 04:43 (UTC)返信
質問 よくわかっておらず恐縮ですが, このプロジェクトで増やす「地理情報」というのはどのレベルなのでしょうか? ページがあればいいのか, それとも特定のプロパティがないといけないのか. もし前者なら, 都道府県は愚か市区町村は全てがそろっている事でしょう. --Tmv (会話) 2023年9月27日 (水) 11:52 (UTC)返信
困りました、次のシナリオを想像しています。
例の表組みに「都道府県」などの語彙素を記入する → 誰かがクエリを走らせて「status」判定が出る → それで「未完了」と出たら、足りないデータを埋める。
では、その合否判定はどうやって出るのか?
クエリをかけて何かの域値で判断しているだろうと当たりをつけ、二点、クエリが見つかりました。(a)と(c)です。
これらのクエリは日本の県にぶつけると、自動判定で「完了」とか旗付きの「何項目ある」と判定が出る?
プロジェクトページのタブ4枚。
(a)「Item」タブ、本文の1行目の上に全データ用のクエリ(?)が貼ってあるようです。tools.wmflabs.org - Administrative subdivisions
(b)タブ「Item」にある表。
Wikidata:WikiProject Country subdivision/Itemsを開くと、表組みの右の端から2列目に件数の数字があり、そのリンクを押すとクエリが開きます。アルジェリアの場合。
Country / Level / Type / Quantity / Status /
(c)「アルジェリア」1行目の項目数48は青リンクで、押すとクエリが開く。--Omotecho (トーク) 2023年9月27日 (水) 13:33 (UTC)返信
コメント ウィキデータに接続されているページ数が所定の数 (Quantityと書いてある欄) と合致したら完了という事でしょう. 接続されているページの確認にはWikidata Query Serviceが使用されているようです. 試しに日本の都道府県の下位ページを絞り込むと[1], 都道府県に全く関係のない物が出てきました. これらを適切な場所に付け替え, 47個の適切な結果が出てくるようになったら完了の様です. --Tmv (会話) 2023年9月27日 (水) 13:55 (UTC)返信
クエリをかけると、自然公園などが自治体に分類されるということですね。どうも属性の共通の付け間違いであろうと思われます。
47の行政単位は網羅されているかなど、精査できずすみません。作業表を作りたいと感じつつ、着手は10月一日になりそうな現況です。ここで一旦、スレッドを放れます。悪しからず。--Omotecho (トーク) 2023年9月28日 (木) 05:54 (UTC)返信
クエリの結果が47都道府県と一致しない原因を調べてみました。
自然公園については、それが属する「都道府県立自然公園」(Q11643861)が「都道府県」のサブクラスであるためでした。SPARQLの "?item wdt:P31/wdt:P279* wd:Q50337." を "?item wdt:P31 wd:Q50337." として、「都道府県」の直接の要素のみにすることでヒットしなくなりました。
その他の「仙台県」、「内陸県」、「琉球県」などについては修正をしてヒットしなくなりました。
こちらの条件で、正しいものだけがヒットするようになりました。--Kensakak (トーク) 2023年9月28日 (木) 12:59 (UTC)返信
報告 @Kensakakさんにより, 中核市以外は全て完了したようです [1]. ありがとうございます--Tmv (会話) 2023年10月4日 (水) 08:17 (UTC)返信
大変おせわになりました。今回のご相談の件は、おかげさまで見事にクリアいただきました。
あとの空欄はどうやら今回の話題から離れてしまうようです。自治体創設の日付? 確か佐幕倒幕で政情がもめた話題だったような。未来のバケットリストに入れます。貴重なお時間をありがとうございました。--Omotecho (トーク) 2023年10月5日 (木) 04:08 (UTC)返信

──────────────────────────────────────────────────────────────────────────────────────────────────── 感謝 すべて完了したようで, 教えてくださったOmotechoさん, そしてプロジェクトを進めてくださったKensakakさん, ありがとうございました--Tmv (会話) 2023年10月9日 (月) 08:03 (UTC)返信

韓国のあれこれ

お疲れ様です, Tmvです. 最近韓国に手を伸ばしていたのですが, いくつか微妙な点がありましたのでご意見いただきたいです.

  1. 都市の名前は「~市」か単に名前だけを書くのか?
    • e.g. 春川市 or 春川?
    • 釜山が「釜山広域市」でないのですが, 市を付けない「春川」「東海」というのは些か違和感がありますし日本の地名とも被ります
  2. 漢字? カタカナ?
    • 今のところ漢字名で統一しているのですが, Googleで調べているとカナカナ表記を用いているところも多く, どちらがいいのか迷っています.
    • 私個人の意見としては, 「韓国」が漢字である以上他も漢字でいいのでは.
  3. カテゴリ:大韓民国について, 国の記事名は「韓国」なのにカテゴリ名が正式名称なのはおかしいと思います. カテゴリの方も「韓国」にしてよろしいでしょうか.

以上です. ご意見お待ちしております--Tmv (会話) 2023年10月9日 (月) 08:01 (UTC)返信

旅人として現地を訪れた場合に、役に立つ表記が良いかと感じます。聞きかじりをお許しいただくとして、2000年以降生まれの韓国の成人で漢字が読める人口比率は想像以上に低い由。
ウィキメディア・コモンズより(画像)
特別市の庁舎内の案内板 には漢字がなく、ko/en/jaで記載されています(画面上部中央、非常口のサインの下。黒字に金色文字の標識)。
  • 「漢字表記があればなんとかなる」という予断は通じない模様で、ではどのくらい漢字表記が「ない」のか。
  • 仮の実例をウィキメディア・コモンズで探す。画像、地図?
  • ウィキペディアKowpに明確な方針があるかどうか。
  • ウィキボヤージュで特定の名所に関心を持ったら、機械翻訳を挟んでKowpを読みに行くと思います。
--Omotecho (トーク) 2023年10月11日 (水) 10:55 (UTC)返信
コメント @Omotechoさん 私の友人の肌感ですと, 韓国の若者からすると漢字はもはや古典文字のような感覚であり, 漢字の韓国名が十分に通じるのは高齢者のみということです. 看板についても, 最近では日本語の翻訳として漢字の固有名詞が用いられているなど, 韓国語としての漢字は益々その出番を失っています. 今後更に韓国での漢字が衰退するであろうことも頭に入れると, 記事名が漢字であることに現地での有用性はあまりないかも知れません.
しかし, カタカナで書くと長くなりがちで, 漢字と比べると名前が覚えにくいというデメリットもあります. そのため, 現地での有用性がなかろうとも漢字表記の方が個人的には好きです. --Tmv (会話) 2023年10月12日 (木) 11:48 (UTC)返信
おっしゃるとおり、黙読なら漢字で文字数を節約、汎用性はローマ字表記が有効となると、カタカナ転写がいちばん不便などは気になります。表記の問題は韓国に限らないかもしれませんが、事例として良いきっかけかとも感じます。まるで三段活用ですが、通じるのか、可読性か、悩ましいです。
  1. 漢字は文字数を減らせる。
  2. カタカナ転写は文字数が増える、正確なカタカナ表記は難しい(耳で聞きなすのも発音するのも)
  3. それならいっそ、現地の人との共通の書字は欧文表記=英語圏の聞きなし? 
プリントアウトでも携帯端末の画面でも、欧文表記ならおおよその行き先(現地)で使い道があるとも思います。でも漢字に欧文を読み仮名のように添える形態?
オープンストリートマップで皆さん、どうしているのでしょう?--Omotecho (トーク) 2023年10月12日 (木) 17:56 (UTC)返信
返信 (Omotechoさん宛) OSMには「韓国語の漢字」や「韓国語のラテン文字」があり, そちらに漢字表記・ローマ字表記が入っています. 日本語の名称は基本的に漢字で「〜〜市」ですが, ソウルは「ソウル」, 釜山広域市は「釜山」でした. おそらく日本語で最もよく使われているであろうものが当てはめられているのだと思います
ウィキデータはウィキペディアの影響あってか全て漢字の正式名称に統一されているようですが, それでもソウルはカタカナでした(Q8684): 漢字が制定されたのが最近 (2005年) なのが原因か?
仰る通り, ローマ字表記を活用するならば記事名と言うよりは記事内に書くことになると思います. --Tmv (会話) 2023年10月12日 (木) 22:34 (UTC)返信
得心しました。本題は〔カテゴリの方も「韓国」にしてよろしいか 〕なのに、あれこれ変化球を投げて失礼しました。
ご解説を読むだに受け皿(プロジェクト)ごとの特徴がほの見えて興味深いです。--Omotecho (トーク) 2023年10月13日 (金) 03:35 (UTC)返信
報告 とりあえずカテゴリの名前を変更してまいりました.
質問 ページ名の表記については漢字, 記事内でローマ字を紹介するというのは決まりとして, 「市」をつけるかつけないかの問題は如何しましょう? --Tmv (会話) 2023年10月14日 (土) 08:50 (UTC)返信
コメント 別スレッドのVCardの議論と連動すると思い、賛否保留、非常に根拠の弱いまま選ぶなら「市なし」。個人の偏った見方ですが、正式名称のソウル特別市から中途半端な省略をした印象を受けます。つまりはベルリン、ウィーン、モスクワ、グラスゴー、エディンバラなども、私個人は行き先として考える時、行政上の区分を気にしていないせいでしょうか。大手の旅行サイトの様子をみてきました。
  • 大づかみにウェブ検索し、広告主3社の文字列をnowikiで転写しました。それらサイトはランディングページで「市」がないです(太字に変えた箇所)。以下「3」のみ試しにリンクを押して検索用のページに飛ぶと、都市名記入欄のサンプルは「ソウル」で示しています。
  1. スポンサー:【ソウル】ホテル予約 - ベストプライス保証 https://www.a_goda.com › ソウル › ホテル
  2. スポンサー:エクスペディア: 韓国 - ソウル - 安心して旅を満喫 https://www.e_xpedia.co.jp
  3. スポンサー:j_ptrip.com ソウル旅行・飛行機+ホテル & 2023 格安航空券付き宿泊...
繰り返しになりますが、VCardの導入と切り分けると二律になりそう。
--Omotecho (トーク) 2023年10月14日 (土) 10:44 (UTC) 外部リンクに細工、アンダーバー。返信
コメント 確かに, ソウル特別市というのはなんとも堅い印象で, 単にソウルといった方がカジュアルというか, とっつきやすい感覚です. であれば, 他の町 (安山市など) も市をとって安山といった方がいいでしょうか? --Tmv (会話) 2023年10月20日 (金) 08:45 (UTC)返信
申し訳ない、ウィキペディアをチェックし忘れました。あちらではソウル特別市なんですね。ウィキ間リンクを書くだろうから、ページ名は同じ方が良いでしょうか? ただ、フィンランド語版ウィキペディア(Soul (kaupunki))を除くと、いずれの言語版でも「ソウル」が題名のようで「ソウル特別市」は浮いているようにも見えます。類例の話を繰り返しますが、w:ja:ベルリンは導入部でベルリン州が正式名称であると示し、w:ja:ワシントンD.C.なども同様。("※"=正式名はコロンビア特別区で変化球です)。
他言語のウィキボヤージュの場合。
ウィキデータに照らすと、英語版その他どれも「ソウル」みたいです(一部を抜き書き)。
これらのパターンで、他の都市名・地名も基準になるでしょうか? 安山という「山・山脈」がありませんように。--Omotecho (トーク) 2023年10月21日 (土) 17:30 (UTC)返信
返信 ウィキペディアと同じ名前にする必要はありません. 極論を言ってしまえば, 旅行時に分かりやすければいいのです. 他の旅行ガイドで「ソウル」と表記しているのなら, ウィキペディアよりそちらに倣う方がいいかと思います.
また, ソウルなど, 通常の市とは異なった特別市などの町と, 通常の市については分けて考えた方がいいかも知れません. ソウルに「特別市」と足すと固く感じますが, 安山に市を足してもあまりそういった印象は感じません. --Tmv (会話) 2023年10月21日 (土) 23:20 (UTC)返信

──────────────────────────────────────────────────────────────────────────────────────────────────── (インデント調節)了解しました。「ソウル」表記に1票賛成します。 次に一般的な市町村の表記。他の旅行サイトでどう示しているかは、軸になりますね。テンプレートで外部リンクを呼び込む案の下地にしたいです。

(a)漢字もしくはカタカナ(ヨミガナ)なし、「市」なし
  • 安山(ヨミガナ)なし Expedia
  • 安山市(ヨミガナ)なし、「市」ありTrip.com
  • アンサン〈漢字表記なし〉booking
(b)漢字(ヨミガナ変則)、「市」あり
  • 安山市(アンサン)Agoda
(c)漢字(ヨミガナ)、「市」なし
  • 安山(アンサン) skyticket.jp、このサイトは「市」は省き、漢字表記(ヨミガナ)で統一。【大見出し】にヨミガナはあったりなかったり。【済州島】城山日出峰(ソンサンイルチュルボン)、【光州(クァンジュ)】国立アジア文化殿堂(ACC)。("※"=ページ名は「韓国・安山(アンサン)のおすすめホテル!外国人労働者の多い工業都市」2020年2月12日更新)
  • 安山(アンサン韓国観光公社。("※"=ページ名は「安山ピョルピッ村アニマル&ハートビレッジ……」と続く。)

--Omotecho (トーク) 2023年10月22日 (日) 04:19 (UTC)/ インデント減らしました。2023年10月22日 (日) 04:25 (UTC) / 文字直し --Omotecho (トーク) 2023年10月22日 (日) 04:56 (UTC)返信

コメント 数だけでみると, 「市」なしのほうが多そうですね. とはいえ, どちらの表記も見られます. ソウルに完全に合わせるならばカタカナ表記の「市」なしが一番でしょう. ただし, 日本語を扱う人にとっては漢字の方が一般に理解しやすいと思います. また, 韓国は大きな都市は「市」として記事を書くものの小さな都市群は「郡」単位を地理的階層の最下にしているようです (少なくとも英語版では). これらを同じ階層だから区別しないとすると「市」「郡」なし, 逆に区別するとするとつけることになるでしょう.
個人的には「市」「郡」ありの方がどういう階層の記事なのか一目でわかるので好みです. --Tmv (会話) 2023年10月28日 (土) 08:01 (UTC)返信
賛成  記事名に限り、国を限定せずに県・州以下も「市、郡、村」をつけたいです。それで不都合が出そうですか? 
ちゃぶ台返しの話ですみません。乱暴な論なのですが、こと韓国地名に限らず、カタカナ表記の欧米やアジアの地名にも、同音異義語の問題はあると思います。導入部に丸カッコで国名をそえれば済むなら一刀両断で、この思いつきは成り立ちませんが。
そうですね、私も漢字表記の地名は目に入りやすいです。実例ばかりこだわって、記事名が競合するケースはあまり考えませんでした。
ウィキペディア(東海)
  • 日本
    • 愛知県東海市。
    • 愛知県名古屋市港区東海通。
    • 茨城県那珂郡東海村。
    • 東京都大田区東海。
  • 中国
    • 江蘇省連雲港市東海県。
    • 東海鎮 (曖昧さ回避)
  • 韓国
    • 大韓民国の地名(トンヘ)
    • 江原特別自治道東海市。
--Omotecho (トーク) 2023年10月28日 (土) 10:50 (UTC)返信
コメント 同意見ですし, 行政名をつけることによる弊害も (ソウルと違う表記になるという点を除いて) 思い当たりません. 少し待ってみて問題なさそうでしたら上記の通りに統一したいと思います.
なお, その旨はどのページに書くのが適しているでしょうか? Wikivoyage:記事名の付け方に書くには具体的すぎますし, Wikivoyage:地理的階層/各国の地域区分とは少々内容が異なります... --Tmv (会話) 2023年10月28日 (土) 12:59 (UTC)返信
Wikivoyage:記事名の付け方」が良いように思います。州や県の下の層として、以下の構成はいかがですか?
  • →地方
  • →【ここ】大ざっぱに2、3例を書く。
  • →略称を使用しない
「記事名の付け方」の他言語版リンクで中国語版を見ました。曖昧さ回避のところで「青森(県)と青森市」の例があります。(ピンポイントの回答が見つからないので、ゴマ菓子。)--Omotecho (トーク) 2023年10月28日 (土) 15:06 (UTC)返信
コメント 現在記事名の付け方を編集していたのですが, 日常会話では「ソウル」「釜山」と同様に「安山」と言い, 「安山市」とは言わないのではないかと気付きました. そうなるとこれらの違いをどう説明すればいいのかわからず, 詰まっております.
韓国だけでなくほかのアジアのケースにも一般化する旨についても同意で, そのつもりで書いていました. しかし, ベトナムなどもホーチミン市など「市」を付ける一方で, バンコクはつきません. 国一つ一つについて「この国はこう, この国はこう」と書く必要があるのでしょうか? 「こういう国は付ける、そうじゃない国は付けない」と書けるのがベストだと思います. --Tmv (会話) 2023年10月29日 (日) 08:56 (UTC)返信
ご苦労を押し付けて申し訳ないです。実は下調べのつもりで以下を読んで、4話割くらいは納得したのですが、どうも、スパッと、スパッと書き分けができません。「プロジェクト:世界の旅」は現在休止中でした。苦し紛れでドイツ語版ものぞいたのですが、徒労(地名は文化だった)
百科事典では以下の理屈を通していますが、曖昧さ回避の幅と奥行きは、旅行・地理でそんなに意識させるのか? これはローカルルールですよねぇ。長いものに巻かれてしまうかどうか。ウィキデータを金科玉条にできないかというと、それも言語ごとで揺れがありそうです(ドイツ語の例1件)。
🔺ご注意:以下はウィキペディアの読解です。
  • バンコクはつかない。これが本則。
  • ホーチミンはつく。有名人が由来のためウィキペディアは曖昧さ回避のため。「+市」。
  • 安山市 はつく。曖昧さ回避
    • "※"「安山」はこの項目へ転送されています。大韓民国の女子アーチェリー選手(アン・サン)については「安山 (アーチェリー選手)」をご覧ください。
    • ドイツ語版のウィキデータ: Ansan(ウィキデータ)。
    • 曖昧さ回避あり、隣国フランスの同音地名。Ansan (Gers) (Koordinaten ♁43° 41′ N, 0° 47′ O)。
--------
 
以下はウィキペディアの命名規準から抜粋。
【ウィキペディア】 > 地名
【ウィキペディア】 > 人名
2. 中国人、韓国人などで名前の表記が通常漢字である場合
  • 原則として漢字名を使用する。日本人の名前と同様に扱う。機種依存文字に区分される漢字の扱いも日本人に準ずる。
  • 中国語の簡体字などで、日本で用いられている漢字と対応するものがある場合には、それを用いる。 見当たらない場合にはカタカナ表記を用いてもよい。
  • 用いられている漢字が見当たらない場合には、読み方に則したカタカナを使用する。
--------
 
『△川の地図帳』『□川地名事典』を見よとは書けない--Omotecho (トーク) 2023年10月29日 (日) 12:09 (UTC)返信

提携委員会、オンブズ委員会、事例審査委員会用に開かれた機会

こんにちは、皆さん!提携委員会(AffCom)とオンブズ委員会(OC)、事例審査委員会(CRC)では新しい委員を探しています。このボランティアグループではコミュニティーや活動に対して重要な構造的な支援や管理支援を行っています。立候補することが奨励されていたりこのグループに貢献すると思われる人を励ますことになります。このグループの役割や必要なスキル、メタウィキページに立候補する機会についての情報があります。

委員会支援チームを代表して

Review and comment on the 2024 Wikimedia Foundation Board of Trustees selection rules package

評価とコメントのお願い(発信者=財団選挙管理委員会)
2024年ウィキメディア財団理事選定の審査規定集について(メタの情報共有、抄訳)
まとめ:2023年10月29日(UTC)を期日として、ウィキメディア財団理事選定規準一式の評価とコメントをお願いします。2024年の理事交代に臨み、旧版の更新が目的であり、速やかな選定のためご協力願います。--まとめ文責Omotecho (トーク) 2023年10月24日 (火) 02:48 (UTC)詳細はメタウィキに掲載返信
You can find this message translated into additional languages on Meta-wiki.

Dear all,

Please review and comment on the Wikimedia Foundation Board of Trustees selection rules package from now until 29 October 2023. The selection rules package was based on older versions by the Elections Committee and will be used in the 2024 Board of Trustees selection. Providing your comments now will help them provide a smoother, better Board selection process. More on the Meta-wiki page.

Best,

Katie Chan
Chair of the Elections Committee

2023年10月17日 (火) 01:13 (UTC)

署名について

済み

現在自分は、「 水戸特快(トーク)」という署名を使用しようと思っているのですが、Wikipedia :署名の、 「ただし、凝り過ぎるとかえって読みにくくなったり他の利用者に不快感を与えたりすることもありますので、注意してください。」という部分に、個人的に作成した署名が引っ掛かるのではないか、と思ったため、こちらに質問させていただきました。
この署名は、鉄道が好きなため、列車の3色行き先表示器をイメージし作成しました。wikivovageの皆様は、この署名をどのように思われますか? -- 水戸特快(トーク) 2023年10月21日 (土) 05:00 (UTC)返信

@水戸特快さん、こんばんは、ご活躍の段、拝見しました。たいへん失礼なのですが、文字を置いた箱の背景色を黒100%に指定されていますか? 
実はウィキボヤージュがそうなるか確かめないまま老婆心ですので、仮の話として聞いてください。ダークモード(明暗反転+文字色はまだ緑色)が近々、導入されるようです。
で、現状のダークモード(既定)に切り替えると、黒100%すなわち白100%に反転、やや眩しい気がします。そこで、通常モードの表示で黒味を調整するのは許容範囲でしょうか? イメージとしては車体が日光または人口照明で輝いたときの味付けを仮想して少し黒のパーセントを下がるわけですが、しかしながら、せっかくのデザインが壊れてもいけませんし……。特異な使い方をする者の例をお示ししました。ご参考になれば幸いです。--Omotecho (トーク) 2023年10月23日 (月) 11:34 (UTC)返信
@Omotechoさん、こんにちは。ダークモードに関しては正直抜けていましたね。背景色は現在、#424242に指定しています。実際の方向幕も点灯していないところは真っ黒ではないので。実際に、光り輝く方向幕の写真を撮ってきて、色味を調整しようと思います。-- 水戸特快(トーク) 2023年10月24日 (火) 00:13 (UTC)返信

英文告知文を和文にしたい(テンプレート:redirect)

済み

{{redirect}}なのですが、告知の平文が英語で表示されます。お手数なのですが、修正をお願いできるとありがたいです。また、赤リンクのままにしていてすみません。

たとえば、/docページの説明文は以下のとおり。
  • {Redirect|REDIRECT}} (disambiguous)?曖昧さ回避 → "REDIRECT" redirects here. For other uses, see REDIRECT (disambiguation).
  • {{Redirect|REDIRECT||P1}} → "REDIRECT" redirects here. For other uses, see PAGE1 P1へ転送。
  • {{Redirect|REDIRECT|USE1|PAGE1}} → "REDIRECT" redirects here. For U1, see P1 U1はP1へ転送。
  • {{Redirect|REDIRECT|U1|P1|U2|P2}} → "REDIRECT" redirects here. For U1, see P1 U1はP1へ、U2はP2へ転送。
  • {{Redirect|REDIRECT|U1|P1|U2|P2|U3|P3}} → "REDIRECT " redirects here. For U1, see P1 U1はP1へ、U2はP2へ、U3はP3へ転送。
  • {{Redirect|REDIRECT|U1|P1|and|P2}} → "REDIRECT" redirects here. For U1, see P1 and P2 U1はP1 と P2へ転送。
  • {{Redirect|REDIRECT|U1|P1|U2|P2|and|P3}} → "REDIRECT " redirects here. For U1, see P1 U1はP1へ、U2はP2 と P3へ転送。

--Omotecho (トーク) 2023年10月25日 (水) 01:06 (UTC)返信

コメント 確認しました、お手数をおかけしました。自分で移入したことをすっかり失念しておりました。反省してお詫び申します。--Omotecho (トーク) 2023年10月26日 (木) 02:45 (UTC)返信

テンプレート:Sleepの疑問

済み

{{Sleep}}のチェックインは「チェックイン」と表示されるのに、チェックアウトは「check-out」と表示されます。片仮名表記か英語表記かどちらかに統一した方がよいのではないでしょうか。--柏尾菓子 (トーク) 2023年10月25日 (水) 22:28 (UTC)返信

@柏尾菓子さん ご指摘ありがとうございます. その部分だけ翻訳が抜けていたようです. 先程修正したので, 現在はチェックアウトもカタカナ表記になっていると思います. --Tmv (会話) 2023年10月25日 (水) 22:50 (UTC)返信
片仮名表記を確認しました。Tmvさん、迅速に対応してくださり、どうもありがとうございます。--柏尾菓子 (トーク) 2023年10月25日 (水) 22:57 (UTC)返信

The Vector 2022 skin as the default in three weeks?(情報周知)

まとめ、「情報周知」。3週間後の処理の予告として、デスクトップ表示の グローバル個人設定(the global preferences)で選べるベクター外装既定値を「2022年版」に変えたいが、いかがか。
★ レガシー版を好まれる皆さんは上記リンク、「表示タブ」(appearance tab)にて指定願います。
  • 判断材料としてカスタム化を盛り込んだ。要素の詳細はこちら(リポジトリ)。
  • 先行導入ウィキで好評の利点(順不同)
  1. メニューバーが常置されツールを探しにスクロールせずに済む。
  2. 検索バーの新しい配置が検索を増やす。
  3. 目次の位置変更で記事内の複数の見出しを読みにいく行動が惹起されるなど。
弱く賛成 indicator ({{geo}}や{{mapsources}}) のバグが直るなど, いい点もある反面, TocFixedをはじめとしたいくつかのガジェットやスクリプトは新しいスキンに独自の対応をしなければなりません. よって弱い賛成です. --Tmv (会話) 2023年10月26日 (木) 11:06 (UTC)返信
こんにちは @Tmvさん. We will gladly help with TocFixed. Would it be possible for you to help me find it and see how it doesn't work in the Vector 2022 skin? ありがとう.--SGrabarczuk (WMF) (トーク) 2023年11月10日 (金) 14:22 (UTC)返信
Hi @SGrabarczuk (WMF)! TocFixed fixes the TOC on the Wikivoyage banner to the top of the page, though Vector 2022 has the fixed header menu, so we have to modify the position of the TOC. But the menu implemented by the new skin includes a toc, therefore I wonder it might be a good idea to turned off this gadget to people using the skin. Anyway, this is probably a local problem that I will repair. Thanks for caring! Regards, Tmv (会話) 2023年11月12日 (日) 05:28 (UTC)返信

Read this in your language邦訳にご協力ください • Please tell other users about these changes

Hello. I'm writing on behalf of the Wikimedia Foundation Web team. In two weeks, we would like to make the Vector 2022 skin the default on this wiki.

グローバル個人設定

If you prefer keeping the current skin select "Vector legacy (2010)" on the appearance tab of the global preferences and save the change. We encourage you to give the new skin a try, though.

Since I last came to you with this question, many things have changed. The skin is now the default on most Wikipedias, and all logos are done! We have also made some tweaks in the skin itself. Below is the text I've sent to you once, but I'm sending it again, just slightly edited, for those who haven't seen it.

If you know what this is about, jump straight to the section "Our plan":

It would become the default for all logged-out users, and also all logged-in users who currently use Vector legacy as a local (but not global) preference. Logged-in users can at any time switch to any other skin. No changes are expected for these skins.

About the skin

Slides to our Wikimania 2022 presentation. You may also listen to the recording on YouTube (in English).

[Why is a change necessary] When the current default skin was created, it reflected the needs of the readers and editors as these were 14 years ago. Since then, new users have begun using the Internet and Wikimedia projects in different ways. The old Vector does not meet their needs.

[Objective] The objective for the Vector 2022 skin is to make the interface more welcoming and comfortable for readers and useful for advanced users. It introduces a series of changes that aim to improve problems new and existing readers and editors were having with the old skin. It draws inspiration from previous user requests, the Community Wishlist Surveys, and gadgets and scripts. The work helped our code follow the standards and improve all other skins. The PHP code in the other available skins has been reduced by 75%. The project has also focused on making it easier to support gadgets and use APIs.

[Changes in a nutshell] The skin introduces changes that improve readability and usability. The new skin does not remove any functionality currently available on the Vector skin.

  • The limited width and pin-able menus allow to adjust the interface to the screen size, and focus on editing or reading. Logged-in and logged-out users may use a toggle button to keep the full width, though.
  • The sticky header makes it easier to find tools that editors use often. It decreases scrolling to the top of the page by 16%.
  • The new table of contents makes it easier to navigate to different sections. Readers and editors jump to different sections of the page 50% more than with the old table of contents. It also looks a bit different on talk pages.
  • The new search bar is easier to find and makes it easier to find the correct search result from the list. This increased the amount of searches started by 30% on the tested wikis.
  • The skin does not negatively affect pageviews, edit rates, or account creation. There is evidence of increases in pageviews and account creation across partner communities.

[Customize this skin] It's possible to configure and personalize our changes. We support volunteers who create new gadgets and user scripts. Check out the repository for a list of currently available customizations and changes, or add your own.

Our plan

If no large concerns are raised, we plan on deploying on 14 November. If you'd like to ask our team anything, if you have questions, concerns, or additional thoughts, please comment in any language. If this is the first comment to my message, make sure to ping me. We will gladly answer! Also, check out our FAQ. Thank you! SGrabarczuk (WMF) (トーク) 2023年10月26日 (木) 01:09 (UTC)返信

「アジア」執筆コンテスト→アジア月間(お誘い)

アジアに特化した執筆コンテストが連続する形ですが、今週、月が替わりましたら「w:ja:アジア月間」が始まります。

10月31日〆切、このボタンで
→→「参加登録」できます(編集モード)。

手順の大きな違いは2つあるようです。

  • 出典が必要。
  • 参加者は、計測用ツールに自発的に自分の記録を残す。

もしもご近所の国について、書き足りなかった、百科事典の目で見たらこんな話題もあったなど、まだ鉄の熱いうちに打てる方はどうぞご注目を!

メタでも「WAM」という略語で情報発信があり、鳥瞰図のように眺めてみてください。世界中で「よーい、ドン」です。--Omotecho (トーク) 2023年10月30日 (月) 10:05 (UTC)返信

「アジア」執筆コンテスト→アジア月間(お誘い)

アジアに特化した執筆コンテストが連続する形ですが、今週、月が替わりましたら「w:ja:アジア月間」が始まります。

  • 参加登録は10月31日(UTC)〆切。

もしもご近所の国について、書き足りなかった、百科事典の目で見たらこんな話題もあったなど、まだ鉄の熱いうちに打てる方はどうぞご注目を!

手順の大きな違い
  • 出典が必要。
  • 参加者は、計測用ツールに自発的に自分の記録を残す。

この2つが目立つかもしれません。

外国へ飛び出す旅人なら、いきなり巨大空港で迷子になるなど心細さは鍛えられているかもしれません。というわけで、メタでも「WAM」という略語で情報発信があり、鳥瞰図のように眺めてみてください(今時点ではまだ翻訳対象になっていないようです)。お知らせでした。--Omotecho (トーク) 2023年10月30日 (月) 10:52 (UTC)返信

為替とレート(テンプレート)

為替と、そのレート関連で気になることがあります。(Template:為替=Q6072575

対象のテンプレート
  1. 対になるテンプレート:Exchange_rate_eurosを有効にしても良いでしょうか? 翻訳してからしばらく経ってしまい、あるいはまた、元々、ドイツ語版からきたようなので、そちらとも比較した方が良いかどうかご意見いただけるとありがたいです。
  2. テンプレート:Exchangerate
  • 優先度は低い。原文を英語版にして、内容をドイツ語版から補足するかどうか?
為替のテンプレート

ウィキメディア・コモンズにあります。観に行くと、Template:Exchange_Rate_Dataがあります。ドイツ語版ウィキボヤージュから載せたものだそうです。構成は、以下の箇条書き(仮訳部分=箱入り)、その下にコードが対応通貨分、書いてあります。
〈ここから仮訳です。〉↓

続いて、箱入りの注意書き(仮訳)

〈仮訳はここまで。〉↑

  • どうやら為替レートの表が外部にあって、そこへ上記のテンプレートから読み取りに行くようです。ユーロの為替レートは、「Data:ECB_euro_foreign_exchange_reference_rates.tab」。直近の更新
  • 為替会社「Xe.com」のレートを採用。
為替用テンプレートの全体像

カテゴリ:通貨のテンプレート全体に影響しそうなので、話が複雑になるかもしれません。
このカテゴリ「通貨のテンプレート」にあるページ

--Omotecho (トーク) 2023年10月31日 (火) 14:58 (UTC)返信

賛成 話題に上がっているテンプレートはどれも問題ないと思います. 具体的に言えば, 冒頭の2つとカテゴリ:通貨のテンプレートに直接入っている3つです. 唯一気になることと言えば, {{Exchange rate euros}}の名前が他の{{Exchange rate JPY}}や{{Exchange rate USD}}の様に{{Exchange rate EUR}}でないことでしょうか. --Tmv (会話) 2023年11月12日 (日) 06:03 (UTC)返信

Wikidateを使用した座標の指定

済み

こんにちは、水戸特快です。本日、サンドボックスで作業中に気づいたのですが、従来はWikidateの引数を指定すれば地図にピンが立った(座標の指定がされた)のですが、現在はlatとlongの引数まで表記しなければピンが立ちません。私の知らないうちに仕様変更がなされたり、そもそもの使い方が間違っていたりしましたでしょうか。-- 水戸特快(トーク) 2023年11月4日 (土) 06:02 (UTC)返信

返信 (水戸特快さん宛) スペルミスのように見えます. 「Wikidate」を「Wikidata」に変えて直りませんか? --Tmv (会話) 2023年11月4日 (土) 08:46 (UTC)返信
感謝 治りました。Tmvさん、ありがとうございます。スペルミスは疑ったんですが、よく確認していなかったです。お騒がせして申し訳ございませんでした。-- 水戸特快(トーク) 2023年11月4日 (土) 09:17 (UTC)返信

記事の進捗を示すテンプレート

お疲れ様です, 少々間が空いてしまいましたが, テンプレート・ノート:Stubにて議論していた記事の進捗テンプレートの修正・張り替えの合意形成を行いたいと思います.

これまでの話を要約すれば, 本来内容の非常に薄い記事に張られる{{stub}}を, 私の無配慮により充実した記事の進捗も計る別の目的に改造したため混乱が生まれてしまいました. そのため, Stubテンプレートは元に戻し, 記事の進捗を計るものを別に作成すべきとの意見がありました.

その意見によれば, 新テンプレート (仮名: {{status}}) に記事の進捗を計る機能を移し, Stubテンプレートは単に内容不十分である記事にのみ貼る, とすべきです. しかし, 新テンプレートへ移行するために今まで記事に張られてきた多くのStubテンプレートを張り替えなければなりません. また, 新テンプレートは記事がStubかどうかを判別する機能も持ち合わせているため, そちらを使うならStubはおそらく必要ありません.

以上から, 進捗を自動で計る新テンプレート (機能は現在のStubと同じ) を作成してStubは元の機能に戻し, 次いでテンプレートStatusで既存のStubを張り替えたいと思うのですが, 如何でしょうか. 張り替え作業にはボットが必要かと思われます--Tmv (会話) 2023年11月10日 (金) 12:54 (UTC)返信

お疲れさまです。疑問が2つあり(以下aとb)、英語版Wikivoyage:Article_statusを見てきました(#Status criteria節)。
  • (a)段階をいくつ作るのか?
  • (b)何をめどに判断するか?
詳細は、テンプレート・ノート:Stub」に書きます。--Omotecho (トーク) 2023年11月11日 (土) 02:53 (UTC)返信
コメント まずはこちらで, 最優先のStubとStatusの分離の合意をとりたいです. これができれば混乱は避けられるので. Statusの中身については, 分離が完了した後別個で話しませんか? --Tmv (会話) 2023年11月12日 (日) 06:06 (UTC)返信