4

i18nリソースキーをコンポーネントごとに整理するのが最適ですか？

FILE_TAB_TITLE:    'Files'
FILE_FIELD_TITLE:  'File'
GROUP_TAB_TITLE:   'Group'
GROUP_FIELD_TITLE: 'Group'
SAVE_MENU_ITEM:    'Save'
SAVE_AS_MENU_ITEM: 'Save as...'
SAVE_BUTTON:       'Save'

またはそれらが何を意味するのですか？

FILE:    'File'
FILES:   'Files'
GROUP:   'Group'
SAVE:    'Save'
SAVE_AS: 'Save as...'
4

3 に答える 3

2

これはルールというより慣習だと思うので、答えは「より論理的に見えるものは何でも」かもしれません。

i18n リソース キーの作成を開始し、次の規則を採用しました。

  1. # で始まる「タイトル セクション」を含むヘッダー
  2. ドット区切りの階層表記
  3. 簡単にアクセスできるようにアルファベット順に整理されたキー

例：

#File access
file.field.title = File
file.field.subtitle = Click here
file.tab.title = Files

#User
user.name = First and last name
user.password = Password
user.username = Username
于 2012-07-24T13:50:32.260 に答える
2

英語のフレーズの簡潔な大文字バージョンを使用します。例 (JavaScript):

SAVE: "Save",
LOAD: "Load",
PLEASE_SELECT_ITEM: "Please select an item.",
PRESS_NEXT_TO_PROCEED: "Please press the Next button to proceed."

このように、開発者は実際の意味を理解するためにトークンの内容を調べる必要はありません。

個別に翻訳される可能性のある別のモジュールに表示される場合を除き、別の場所に表示されるアイテム (たとえば、メニューに表示される「保存」とボタンに表示される「保存」など) の冗長なエントリはありません。

また、タイトル/キャプション、プロンプト、およびエラー メッセージのトークンは、別のファイルに編成されます。

于 2012-07-24T13:58:27.497 に答える
1

次のように、機能ごとに階層的に整理します

ui:
  choose: choose...
  save: save
  cancel: cancel
  preview: preview

season:
  summer: summer
  autumn: autumn
  winter: winter
  spring: spring

people: !!pl
  0: no people
  1: one person
  n: "%1 people"

is_are_people: !!pl
  0: are no people
  1: is one person
  n: "are %1 people"

次に、ヘルパー、ルート、または haml ファイル (主に Sinatra を使用)Unicode::capitalize(t.ui.save)で、[保存] ボタンや"There #{t.is_are_people some_people.count}."見出しなどで参照できます。

于 2012-09-19T22:47:37.883 に答える