honesome
@honesome (honesome)

Are you sure you want to delete the question?

Leaving a resolved question undeleted may help others!

ロケールや表示言語をURLに入れるべきでしょうか

Discussion

Closed

ロケールや表示言語をURLに入れるべきでしょうか

多言語に対応するWebページの設計として、
ja-Jpや、単にjpをURLに含めるべきなのか皆さんの意見をお聞きしたいです。

1

URL=Uniform Resource Locatorですから、それぞれの言語のコンテンツを同一のリソースとみなすか(設計するか)というところがポイントのように思います。
例えば技術ドキュメントであれば、基本的に各言語の情報が1:1になってますから、同一のリソースとして(同一のURLとして)運用してもさほど問題はないと思います。
ただ多言語のウェブサイトを作る上でそんなにきれいに1:1になるパターンは多くないので、基本的にはlangやlocaleでURLを区別し、特別に同一URLとしたい明確な事情があるときのみURLを分けずに運用するといった方針が良いと思います。

ちなみにGoogleは言語ごとのURLを推奨しているため、SEOを意識するのであれば分けたほうが良さそうです。
https://support.google.com/webmasters/answer/182192?hl=ja

2Like

@studio15さん

なるほど、SEO的には入れた方が良いのですね。
知りませんでした。

私はどっちかと言うと、ロケールや言語の情報は
CookieやLocalStrage等のみで管理していれば良いと思っておりましたので、参考になります。

0Like

共用のPCから日本語話者も日本語話者でない人も「同じページ(の違う言語版)」にアクセスを試みるという事態はあるし、翻訳を信頼しきれず邦訳ページと原語ページをいったり来たりしながらチェックしたいことも頻繁に有ります。URLに然るべきオプションを付け加えることで確実に任意の言語版にアクセスできるスタイルのほうが断然便利だと私は思います。

ブラウザの言語設定を検知して否応なく英語ページや日本語ページを押し付けてくるサイトが有りますが、ほんとやめてほしいです。

3Like

私も、多言語対応するのであれば URL を変更すると言語も変更される、つまり URL に含めたほうが良いに1票です。

10 数年前、お客様の強いご要望により、Apache の MultiViews 設定で index.html.ja index.html.en といった自動切り替えを使ったことがあります。

しかし、ランニング・コストの問題で、途中から翻訳が追いつかなくなったり、総務の方がやっつけで翻訳した北斗の拳の再翻訳のようなページが増えてしまいました。懸念した通りの結果です。

このようなページは、オリジナルの言語で読んだ方が早いことが多くあります。しかし、他の方のコメントのように、ブラウザの設定言語で自動検知されると、切り替えることすらできないサイトも多く、そのようなサイトには足を運んでいただけなくなると思われます。

逆に、ユーザーが任意で切り替えられるようにしたところ、割と客足は遠のきませんでした。

3Like

@doikojiさん
@KEINOSさん

回答ありがとうございます。
確かに、ブログ等の静的コンテンツをホスティングしているWebサイトでは
urlに入れたほうが良さそうですね。

例えば、Qiita等のWebアプリケーションで言語切替えできるようなサイトでは
特に含む必要は無いと思うのですが、如何でしょうか。

0Like

@honesome さん

例えば、Qiital等のWebアプリケーションで言語切替えできるようなサイトでは
特に含む必要は無いと思う

いちいち別のページに行って切り替えることをユーザに強制するような作りが全然ダメだと申しております。コンテンツの供給方法が静的だろうと動的だろうと同じです。

0Like

多言語対応のポイントとしてはURL設計とUI設計の2点があると思います。

A. URLが言語別に分かれており、環境に依らず特定のリソースを参照できるか
B. GUI上で言語を容易に切り替えることができるか(言語選択メニューが有るか)

おそらく

Qiita等のWebアプリケーションで言語切替えできるようなサイトでは特に含む必要は無い

というのはBが実装されているのであれば、Aを満たす必要はないのでは、という疑問だと思いますが、Aを満たすべきかどうかはケースバイケースだと思います。

例示されたQiitaで考えると、個人的には「言語設定を変えてもメニューや既存の文言しか変わらずメインコンテンツは基本的に日本語(投稿された言語)」という場合は、それらを言語別に別リソースとして扱うのは不自然なので、QiitaのページURLがjaやenで分けられていないのは良い選択だと思います。
ただQiitaと違い、言語設定によってメインコンテンツの言語も変わるようなサービスであれば言語別のURLを実装することも検討したほうが良いと思います。

2Like

@honesome さん

Webアプリケーションで言語切替えできるようなサイトでは
特に含む必要は無い

Qiita は UI の言語を設定で切り替えられるだけで、コンテンツそのものの言語を切り替えているわけではないので、どちらに対しての質問かによると思います。そういう意味でも「必要か否か」「べき論」の2極では決められないと思います。

「UI が多言語対応しているだけ」の場合は、おっしゃるように URL に含めなくてもいいと思います。

そういう意味で、Qiita に外国語コンテンツが少ないのも多言語対応感が UI や URL に無いからだと思います。(特に必要とも思いませんが)

逆にコンテンツ自体が多言語対応している場合ですが、「英語(もしくは日本語)の原文が読みたい」と思った時に、即座にコンテンツの言語が切り替えられるのであれば方法論は何でも良いと思います。

言語切り替えの UI がそのページ内に無い場合、URL に .../ja/... や ../en/.. が含められていれば、ユーザーが「あ、多言語コンテンツ対応なんだ」と勝手に理解したり、URL を書き換えて見に行ってくれことが期待できるので、多言語コンテンツ対応であれば含んだ方が良いという程度です。

1Like

@KEINOS さん

URL に .../ja/... や ../en/.. が含められていれば、ユーザーが「あ、多言語コンテンツ対応なんだ」と勝手に理解したり、URL を書き換えて見に行ってくれことが期待できるので

これは… 相当メインユーザー層のリテラシーが高くないと期待できないやつ!

1Like

これは… 相当メインユーザー層のリテラシーが高くないと期待できないやつ!

Σ( ̄□ ̄;) ハッ

1Like

Your answer might help someone💌