Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • 想定読者
  • Why
  • 現状と課題
  • プロセス
  • 1. 日本語の文言の確定
  • 2. 翻訳依頼
  • 3. 実装
  • 参考

役に立ちましたか?

  1. 第二部:技術領域への案内
  2. 開発プロセス

多言語化対応(i18n)

この章では多言語化対応を実施する背景やプロセス、具体的な実装方法について紹介します。

想定読者

  • フロントエンドエンジニア

  • モバイルエンジニア

  • その他翻訳を依頼する人

Why

2024 年時点でウォンテッドリーは日本語・英語の 2 ヶ国語をサポートしています。理由としてはシンガポールへの事業展開と国内利用における非日本語話者の存在が挙げられます。

そのため、新規・グロース問わずプロダクト開発を行う時には、基本的に多言語化対応を考慮する必要があります。

現状と課題

多言語化対応に関する問題もいくつか存在します。これらはプロダクト開発チームや Frontend Chapter によって鋭意改善中です。

  • 多言語化対応が追いついていない機能がある

  • フロントエンドでは推奨ライブラリである hi18n 以外の利用箇所が一部残っている

プロセス

多言語化対応のプロセスは、以下のステップに分けられます。

参考事例

実際で行われた翻訳プロセスの事例を置いておきます。

1. 日本語の文言の確定

プロダクトデザイナーと連携して翻訳の基準となる日本語の文言を確定します。 この段階でプロダクト内での一貫性を保つための用語や特殊な意味を持つ言葉を選定し、その文脈を理解することが重要です。

2. 翻訳依頼

翻訳対象となる画面の画像を添付し、次のような項目がある場合には issue に記載します。

  • 特定の文言を通常とは異なる意味で伝えたい場合

  • 既存の画面に文言の追加・変更があり、その中に意訳された文言が含まれる場合

  • 英訳時に語順を変更したくない場合(変数として名前・アバターなどを渡す必要があり、語順が逆転することでデザイン差分が発生するなど)

3. 実装

ウォンテッドリーの翻訳プロセスは単なる機械翻訳ではなく、専門チーム(前述)がウォンテッドリーらしさを加味しながら作っているので数日のリードタイムが生じます。もし初めから多言語化対応した変更をリリースしたいのであれば早めに翻訳チームに依頼してください。

また、施策によってはスピード重視で日本語の文言のみ先にリリースすることもあります。

実装方法

  • モバイルアプリ実装では、iOS/Android それぞれの OS 標準のローカライゼーション実装方法に従います。

hi18n とは

  • 翻訳 ID や翻訳の引数に対して型安全性を提供します。

  • React などの宣言的なフレームワークとの統合が容易です。

  • Webpack などの既存の JavaScript 開発環境に自然に統合でき、ホットリロードやモジュールバンドラーの機能を利用した翻訳データの分割ロードが可能です。

参考

話を聞きに行きたい

もっと知りたい

前へ作業ログを残す意味次へメール開発

最終更新 1 年前

役に立ちましたか?

翻訳は、を通じて行います。

フロントエンド実装では を利用します。

は、TypeScript/JavaScript 向けの翻訳テキスト管理ライブラリであり、以下のような特徴を持っています。 開発の動機や設計思想、詳細な特徴などはで紹介されていますが、主な特徴は以下の通りです。

Slack:

Slack:

Slack:

フロントエンド事例 (internal)
モバイルアプリ事例 (internal)
翻訳依頼リポジトリ
hi18n
iOS 公式ドキュメント
Android 公式ガイド
hi18n
別記事
#engineering
#frontend_chapter
#mobile_chapter
wantedly/hi18n: message internationalization meets immutability and type-safety
社内 Issue: I18n ライブラリを作る