Next.jsアプリのローカライゼーション | POSTD
クイックサマリー ‐ 国際化ルーティングは、厳密にはNext.jsの新機能ではありません。（v.10以降搭載されています。）この記事では、この機能のメリットだけではなく、こうした機能を利用して最高のユーザ体験と円滑な開発者体験を実現する方法についても見ていきます。自己文書化コードやバンドルサイズの削減、さらにはランタイムエラーではなくコンパイル時エラーに興味のある方は、是非このまま読み進めてください。 開発中のアプリにおいて、ロケール（または国、あるいは両方）ごとにルートを設定したい場合、Next.jsで簡単に対応できるようになりました。プロジェクトのrootディレクトリにnext.config.jsがない場合、新たに作成してください。このスニペットからコピーしても構いません。 /** @type {import('next').NextConfig} */ module.exports
Kaizen AdにおけるSPAでのi18nへの取り組みと手法について - Kaizen Platform 開発者ブログ
こんにちは。フロントエンドエンジニアのaxrossです。この記事では、弊社のサービス「Kaizen Ad」で行った "i18n" (国際化) の取り組みについて紹介したいと思います。 Kaizen Adでは、サービス提供を行う地域として日本とアメリカを同時に見据えて開発をしてきました。そのため、プロジェクト発足当初から意識して開発を始め、(クローズドな) ファーストローンチの2週間後にはこの記事で紹介するようなi18nを取り入れています。 i18nとは "Internationalization" の略で、単語の最初の文字 "I" と 単語の最後の文字 "N" との間に18文字あることからこのように略されます。 i18nをどのように考えるか? まずは、Kaizen Adを国際化するにあたって考えたことについて話したいと思います。大きく分けて2つの点をチームで徹底して意識しながら開発を進めま
GitLocalize - Continuous Localization for GitHub Projects
Here's what makes GitLocalize a great fit for GitHub-based localization projects: Your repository is the single source of truth. GitLocalize tracks changes in both the source and translated documents and pulls them into the project. Translations added on GitLocalize are sent to the repository via a pull request. Have existing translations that need to be imported? No problem! Those will be synced
エンジニア・Webデザイナー必読: アプリケーションを国際化・多言語展開する前に知っておくべきこと - Qiita
ちょろっとメモ。の割には長くなったけど、最後の方にいいことが書いてある。 ※技術英語や翻訳 Advent Calendar 2015に参加してみました。スレ違いだったらすみません。 追記: taka-oyamaさんの記事「多国対応ウェブアプリを開発する前に知っておきたかったこと」も参考になります。 追記: 「17ヶ国の多言語対応Tips」で当記事を紹介いただきました。素晴らしいスライドです。 追記: 「本当にあった怖い誤訳」によると、今でも機械翻訳をそのままウェブページで使っている自治体があるそうです。怖す。 追記: ぼくたちのかんがえたさいきょうのi18n国家 - Qiitaもどうぞ。 概要 Web アプリやモバイルアプリを問わず、アプリで当てたらそれ英語化だ多言語化だ国際化だ、となることは多い。しかしアプリの作りなどさまざまな原因によって、他所の国の言葉に翻訳してもらっても実は現地の人
3年間日本語のみで運用してきたサービスを、3ヶ月で新人が多言語化した話 | FiNC Developers Blog
3年間日本語のみで運用してきたサービスを、3ヶ月で新人が多言語化した話 はじめにはじめまして。FiNCで今年の4月からサーバーサイドエンジニアをやっている澤井です。 先日プレスリリースがありましたとおり、FiNCで提供している法人向けサービスFiNCプラスが日本語以外にも対応し、この度英語版がリリースされました。 入社直後に携わった最初のプロジェクトということで、個人的には非常に感慨深いのですが、今回はこのプロジェクトの舞台裏を見ていきたいと思います。 多言語化とはサービスの多言語対応と言っても、そのスコープは様々ですし、サービスが提供しているデータは多岐にわたります。 ざっくりカテゴライズするだけでも、 UIタイムラインなどユーザー投稿によるデータおすすめのタスクなどのマスターデータがあり、それぞれテキストのものと画像データがあります。 またこれらに紐付いて、 ユーザー使用言語の判定があ
I18n.tでHTMLを出力するのにrawやhtml_safeを使ってはいけない - Qiita
みたいなのを書くわけですが、このままだと html_safe でないので自動的にエスケープされてしまいます。 <strong>tnj</strong>さんからメッセージがあります！ 悲しい！ 正しい HTML の含み方 この問題に直面した Rails I18n 初級者は、「じゃーエスケープ避けてそのまま出力させるしかなくない？」と、 raw だったり html_safe を付けてしまいがちです。 でもそうなると、もし @username にタグが含まれていた場合もエスケープされずに出力されてしまうので、簡単に XSS を引き起こしてしまいます。「ここはユーザー入力値は入らないから大丈夫だよ！」は絶対守り切れないし、変数を必要とするたびに「本当にユーザー入力値入ってこないんだっけ?」なんて判断をいちいち必要としていては時間がいくらあっても足りないので、機械に任せたいところです。 で、 Rai
Rails I18n via database column
I have a legacy database table that has columns name_en and name_es and was wondering what the best way to query in ActiveRecord for either translation based on the user's i18n preference would be. The i18n implementations I see for Rails tend to be more about storing translations in a separate hash or table, but I don't want to change the structure of the database. Currently in the old PHP app, I
Rails Timezone の設定色々
困ったときのRails timezone api Timezone 基本設定 config/environments/production.rb 等、各環境後とに・・・ config.time_zone = "Tokyo" ApplicationController でのタイムゾーン設定 class ApplicationController < ActionController::Base before_filter :set_timezone def set_timezone Time.zone = session[:tz] if session[:tz] end end そして、ログインに使うコントローラーで session[:tz] を設定 class User::LoginController < UserRootController def index if request.p
RailsでTimeZoneを設定する｜TechRacho by BPS株式会社
Railsでは、タイムゾーンを簡単に扱う仕組みが用意されています。 まず、Rails (今回は3.0系) でアプリを作ると、config/application.rb に config.time_zone = 'Central Time (US & Canada)' のような記述があると思います。日本用のシステムを作るなら、これを"Tokyo"に変えてコメントアウト解除すればOKです。 config.time_zone = 'Tokyo' これで、入出力は日本時間で、DBにはUTC時刻が入ります。 アクセスに応じて動的に変更するには、before_filterなどで以下のように設定できます。 class HogeController < ApplicationController before_filter do Time.zone = 'UTC' end end タイムゾーンをプルダウン
Railsでの時間管理はUTCで
RailsのTimeクラスは拡張されているので，zoneメソッドが利用できます． ※標準のTimeクラスでは，undefined method でエラーがでます． irb:0> Time.zone => (GMT+00:00) UTC これは，config/application.rbで， 「config.time_zone = 」で指定するのですが，デフォルトは「UTC」です． ここで，「Tokyo」とかに変えても良いのですが，ActiveRecordによって，DBに保存される日時はUTCみたいなのです．．． どうやら，Railsで日時はUTCで管理した方が良さそうで，表示する際にローカル時刻（JST）に変換するというやり方の方が良さそうです． 例えば，users テーブルに，「start_time」というDATETIME型のフィールドを作成されているとき， user = User.fi
Rails 4.0.2のi18nで出るようになったdeprecated警告の対策方法 - @znz blog
Ruby on Rails のセキュリティアップデートがあって、 4.0.2 にあげたら i18n gem も 0.6.5 から 0.6.9 にあがって locale の設定変更をしているところで [deprecated] I18n.enforce_available_locales will default to true in the future. If you really want to skip validation of your locale you can set I18n.enforce_available_locales = false to avoid this message. という警告が出るようになりました。 警告の出るタイミング deprecated - Rails 4.0.2 I18n validation deprecation warning - St
Rails Internationalization (I18n) API — Ruby on Rails Guides
The Ruby I18n (shorthand for internationalization) gem which is shipped with Ruby on Rails (starting from Rails 2.2) provides an easy-to-use and extensible framework for translating your application to a single custom language other than English or for providing multi-language support in your application. The process of "internationalization" usually means to abstract all strings and other locale
[Rails3] 国際化 I18n のまとめ（その３：辞書ファイルの使い方）
実行環境： ruby 1.9.3 Rails 3.1.3 I18n Railsアプリで表示を担当するのはビューなので国際化するのは当然ビューですね。ページに表示される文字すべてが対象となります。 ページに表示される文字をざっと分類してみましょう。 DBに格納されている文字列 HTMLに直接書く単語や文章 モデルの名前や属性の名前などモデルに関連する文字列 Railsのエラーメッセージ 1. DBに格納されている文字列 DBに格納されているデータを国際化（多言語化）する場合は、各ロケールごとのデータを用意する必要があります（日本語だけなら不要です）。 シンプルな方法としては、テーブルに複数のロケール用データをカラムを増やして各ロケールのデータを格納します。 TABLEの構造 +------+----------+------------+ | id | hello_en | hello_ja
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Why locale setting in Rails acts as global (when using Thin)?
i18nについて | 酒と涙とRubyとRailsと