copenhagen_themeダウンロード - copenhagen_themeソースコードダウンロード

copenhagen_theme

その他のソースコード

v4.2.3

ダウンロード

Zendeskのコペンハーゲンのテーマ

コペンハーゲンのテーマは、デフォルトの Zendesk Guide テーマです。応答性が高くアクセスしやすいように設計されています。 Zendesk Guideのカスタマイズの詳細については、こちらをご覧ください。

ヘルプセンターのコペンハーゲンのテーマは次で構成されます。

マニフェストファイル
テンプレートのセット
スタイルシートとJavaScriptファイル
アセットフォルダー。

使用方法

これは、Guide で利用できるコペンハーゲンテーマの最新バージョンです。このリポジトリを開始点として使用して、独自のカスタムテーマを構築することができます。このリポジトリは必要に応じてフォークできます。お気に入りの IDE を使用してテーマを開発し、ZCLI を使用して Web ブラウザでローカルに変更をプレビューできます。詳細については、zcli テーマのドキュメントを参照してください。

テーマのカスタマイズ

このリポジトリをフォークしたら、テンプレート、CSS、JavaScript を自由に編集し、アセットを管理できるようになります。

マニフェストファイル

マニフェストを使用すると、テーマの設定グループを定義し、テーマセンターの UI を介して変更できます。マニフェストファイルの詳細については、こちらをご覧ください。

設定フォルダー

fileタイプの変数がある場合は、その変数のデフォルトファイルを/settingsフォルダーに提供する必要があります。このファイルはデフォルトで設定パネルで使用され、ユーザーは必要に応じて別のファイルをアップロードできます。元。セクションの背景画像の変数が必要な場合、マニフェストファイル内の変数は次のようになります。

 {
  ...
  "settings" : [ {
    "label" : "Images" ,
    "variables" : [ {
      "identifier" : "background_image" ,
      "type" : "file" ,
      "description" : "Background image for X section" ,
      "label" : "Background image" ,
    } ]
  } ]
}

これにより、設定フォルダー内で、 background_imageという名前のファイルが検索されます。

アセットの追加

アセットをアセットフォルダーに追加し、CSS、JavaScript、テンプレートで使用できます。アセットの詳細については、こちらをご覧ください

テーマを公開する

テーマをカスタマイズした後、リポジトリをzipファイルとしてダウンロードし、テーマセンターにインポートできます。

ここでインポートに関するドキュメントに従ってください。

GitHub から直接インポートすることもできます - 詳細については、こちらをご覧ください。

テンプレート

テーマには、利用可能なすべての機能を備えたヘルプセンターで使用されるすべてのテンプレートが含まれています。テーマ内のテンプレートのリスト:

記事ページ
カテゴリページ
コミュニティ投稿一覧ページ
コミュニティ投稿ページ
コミュニティトピックリストページ
コミュニティトピックページ
貢献ページ
文書の先頭
エラーページ
フッター
ヘッダ
ホームページ
新しいコミュニティ投稿ページ
新規リクエストページ
リクエストページ
検索結果ページ
セクションページ
定期購入ページ
ユーザープロフィールページ

次のオプションのテンプレートを最大 10 個追加できます。

記事ページ
カテゴリページ
セクションページ

これを行うには、フォルダーtemplates/article_pages 、 templates/category_pagesまたはtemplates/section_pagesの下にファイルを作成します。詳細については、こちらをご覧ください。

スタイルシートとJavaScript

Rollup を使用して、テーマstyle.cssおよびscript.jsで使用される JS ファイルと CSS ファイルをコンパイルします。これらはリリース時に再生成されるため、直接編集しないでください。

始めるには:

$ yarn install
$ yarn start

これにより、 srcとstylesのすべてのソースコードがコンパイルされ、変更が監視されます。 previewも開始されます。

注:

script.jsをコンパイルするときに意図的に babel を使用しないので、クリーンなバンドル出力が得られます。広くサポートされている ecmascript 機能 (ES2015) のみを使用するようにしてください。
style.css 、 script.js 、およびassetsフォルダー内のファイルを直接編集しないでください。これらはリリース時に再生成されます。
プレビューにはログインが必要なので、これまでに実行したことがない場合は、必ず最初にyarn zcli login -i実行してください。

資産

コペンハーゲンテーマにはいくつかの JavaScript アセットが付属していますが、他のアセットをassetsフォルダーに配置することでテーマに追加できます。

反応コンポーネント

バージョン 4.0.0 以降、Copenhagen テーマは UI の一部をレンダリングするためにいくつかの React コンポーネントを使用します。これらのコンポーネントはsrc/modulesフォルダーにあり、Zendesk Garden コンポーネントライブラリを使用して構築されます。

これらのコンポーネントは、ロールアップビルドプロセスの一部としてネイティブ JavaScript モジュールとしてバンドルされており、 assetsフォルダーに JS ファイルとして出力されます。テーマのインストール時にアセットの名前が変更されるため、アセットヘルパーを使用してモジュールをインポートする必要があります。

モジュールのインポートプロセスを簡単にするために、モジュール名をアセット URL にマップするインポートマップを生成する Rollup プラグインを追加しました。このインポートマップは、ビルド中にdocument_head.hbsテンプレートに挿入されます。

たとえば、 src/modules/my-moduleフォルダーにmy-moduleという名前のモジュールを定義した場合は、次のようにrollup.config.mjsファイルに追加できます。

 export default defineConfig ( [
  // ...
  // Configuration for bundling modules in the src/modules directory
  {
    // ...
    input : {
      "my-module" : "src/modules/my-module/index.js" ,
    } ,
    // ...
  }
] ) ;

ロールアップは、 my-module-bundle.jsという名前のファイルをassetsフォルダーに生成し、このインポートマップがdocument_head.hbsテンプレートに追加されます。

 < script type =" importmap " >
{
  "imports" : {
    "my-module" : "{{asset 'my-module-bundle.js'}}" ,
  }
}
</ script >

次に、次のようにテンプレートにモジュールをインポートできます。

 < script type = " module " >
  import { something } from " my-module " ;

  // ...
</ script >

国際化

I18n は、react-i18next ライブラリを使用して React コンポーネントに実装されます。フラットな JSON ファイルを使用し、 .複数形の区切り文字として使用します。これはデフォルトの_とは異なり、初期化中に設定されます。

また、Zendesk で使用されている内部翻訳システムとライブラリを統合できるようにするツールもいくつか追加しました。カスタムテーマを構築していて、独自の翻訳を提供したい場合は、ライブラリのドキュメントを参照して翻訳の読み込みを設定できます。

Zendesk翻訳システムとの統合

翻訳文字列の追加

翻訳文字列はソースコードに直接追加されます。通常はuseTranslationフックを使用して、キーとデフォルトの英語値を渡します。

 import { useTranslation } from 'react-i18next' ;

function MyComponent ( ) {
  const { t } = useTranslation ( ) ;

  return < div > { t ( "my-key" , "My default value" ) } < / div>
}

コード内にデフォルトの英語値を指定すると、文字列がまだ翻訳されていないときにフォールバック値として使用したり、ソースコードから文字列を翻訳 YAML ファイルに抽出したりできるようになります。

複数形

複数形を使用する場合、翻訳システムの要求に応じて、 zero 、 one 、およびother値のデフォルト値を提供する必要があります。これは、 t関数のオプションにデフォルト値を渡すことで実行できます。

 t ( "my-key" , {
  "defaultValue.zero" : "{{count}} items" ,
  "defaultValue.one" : "{{count}} item" ,
  "defaultValue.other" : "{{count}} items" ,
  count : ...
} )

文字列抽出

bin/extract-strings.mjsスクリプトを使用すると、ソースコードから翻訳文字列を抽出し、内部翻訳システムによって取得される YAML ファイルにそれらの文字列を配置できます。スクリプトの使用法はスクリプト自体に文書化されています。

このスクリプトはi18next-parserツールをラップし、その出力を内部で使用される YAML 形式に変換します。標準のi18next-parser出力を翻訳のソースとして使用するか、カスタムトランスフォーマーを実装することで、カスタムテーマでも同様のアプローチを使用することができます。

翻訳ファイルの更新

bin/update-modules-translations.mjsを使用して、すべてのモジュールの最新の翻訳をダウンロードします。すべてのファイルは、ビルドプロセスによって単一の[MODULE]-translations-bundle.jsファイルにバンドルされます。

初めて翻訳をモジュールに追加するときは、モジュールフォルダーと翻訳システム上のパッケージ名の間のマッピングをスクリプトのMODULE変数に追加する必要があります。たとえば、モジュールがsrc/modules/my-moduleにあり、パッケージ名がcph-theme-my-moduleの場合、以下を追加する必要があります。

 const MODULES = {
  ... ,
  "my-module" : "cph-theme-my-module"
}

アクセシビリティテスト

自動アクセシビリティテストのために Lighthouse を実行するカスタムノードスクリプトを使用します。

スクリプトを実行するには 2 つの方法があります。

開発モード- 特定のアカウントのローカルテーマプレビューでアクセシビリティ監査を実行します。 zcli themes:previewを実行する必要があります。
CI モード- 特定のアカウントのライブテーマに対してアクセシビリティ監査を実行します。

テストの範囲によっては、上記に加えて手動テストが必要になる場合があります。 ax DevTools、VoiceOver などのスクリーンリーダー、コントラストチェッカーなどのツールは、このようなテストを支援できます。

開発モード

テーマの変更中にアクセシビリティ監査を実行するには:

通常と同じように、変更のコンパイルとプレビューを開始します。

$ yarn install
$ yarn start

ルートフォルダーに.a11yrc.jsonファイルを作成します (例を参照)。
1. アカウント/サブドメインを指定してテーマをプレビューし、アクティブなzcliプロファイルと一致することを確認します
2. usernameとpasswordに管理者ユーザーの資格情報を入力します。
3. テストするurls指定します (空のままにすると、スクリプトはすべての URL をテストします)。
別のコンソールで、開発モードでアクセシビリティ監査を実行します。

 yarn test-a11y -d

A11y 監査は、ステップ1で開始したプレビューで実行されます。

CIモード

特定のアカウントのライブテーマでアクセシビリティ監査を実行するには、次のことを行う必要があります。

ノードモジュールをインストールします。

 yarn install

end_user_email 、 end_user_password 、 subdomain 、およびurls環境変数として設定し、CI モードでアクセシビリティ監査を実行します。つまり、次のようになります。

 end_user_email=<EMAIL> 
end_user_password=<PASSWORD> 
subdomain=<SUBDOMAIN> 
urls="
    https://<SUBDOMAIN>.zendesk.com/hc/en-us/
    https://<SUBDOMAIN>.zendesk.com/hc/en-us/requests/new
    https://<SUBDOMAIN>.zendesk.com/hc/en-us/requests" 
yarn test-a11y

無視リスト

無視すべき既知のアクセシビリティの問題がある場合、またはすぐには修正できない場合は、スクリプトの構成オブジェクトの無視リストに新しいエントリを追加できます。これにより、アクセシビリティの問題がエラーではなく警告に変わります。

エントリには以下を含める必要があります。

監査 ID。
URL パターン文字列としてのpath 。
文字列としてのselector 。

例えば：

  custom: {
    ignore: {
      tabindex: [
        {
          path : "*" ,
          selector : "body > a.skip-navigation" ,
        } ,
      ] ,
      aria - allowed - attr : [
        {
          path : "/hc/:locale/profiles/:id" ,
          selector : "body > div.profile-info"
        }
      ]
    } ,
  } ,

この例では、セレクターbody > a.skip-navigationを含む監査tabindexのエラーが、すべてのページで警告として報告されます ( * )。セレクターbody > div.profile-infoを使用した監査aria-allowed-attrでも同じことが起こりますが、ユーザープロファイルページ/hc/:locale/profiles/:idに対してのみ発生します。

これはどうしても必要な場合にのみ使用する必要があることに注意してください。テーマを変更するときは、アクセシビリティに焦点を当て、優先事項にする必要があります。

貢献する

プルリクエストは GitHub (https://github.com/zendesk/copenhagen_theme) で受け付けています。プルリクエストを作成する際は、@zendesk/vikings と明記してください。

従来のコミットを使用して、プロジェクト履歴の読みやすさを向上させ、リリースプロセスを自動化します。したがって、コミットメッセージは次の形式に従う必要があります。

 <type>[optional scope]: <description>

[optional body]

[optional footer(s)]

type: 変更のカテゴリを説明します。サポートされているタイプを参照してください。
スコープ: (オプション) 変更によって影響を受ける内容を説明します。
件名: 変更の簡単な説明
body: (オプション) 変更に関する追加のコンテキスト情報
フッター: (オプション) 外部リンク、問題参照、その他のメタ情報を追加します。

つまり:

 chore: automate release
fix(styles): fix button padding
feat(script): add auto focus to fields with errors

コミット時にメッセージを検証するためにhuskyとcommitlint使用します。

PR がマージされたら、Github アクションをsemantic-releaseと組み合わせて使用し、テーマの新しいバージョンをリリースします。マージのたびに、 semantic-releaseコミットメッセージを分析し、セマンティックバージョンのバンプを推測します。次に、git タグを作成し、マニフェストのバージョンを更新し、対応する変更ログを生成します。

コミットタイプ

以下のリストでは、サポートされているコミットタイプと、リリースおよび変更ログにおけるそれらの影響について説明します。

タイプ	説明	リリース	変更履歴
建てる	ビルドシステムまたは外部依存関係に影響を与える変更	-	-
雑用	ソースコードを変更しないその他の変更	-	-
シ	CI 構成ファイルとスクリプトの変更	-	-
ドキュメント	ドキュメントのみが変更されます	-	-
偉業	新しい機能	マイナー	特徴
修理	バグ修正	パッチ	バグ修正
パフォーマンス	パフォーマンスを向上させるコード変更	パッチ	パフォーマンスの向上
リファクタリング	バグの修正も機能の追加も行わないコード変更	-	-
元に戻す	以前のコミットを元に戻します	パッチ	元に戻す
スタイル	コードの意味に影響を与えない変更 (空白、書式設定、セミコロンの欠落など)	-	-
テスト	不足しているテストの追加または既存のテストの修正	-	-

重大な変更

重大な変更を追加するコミットには、コミットメッセージの本文またはフッターにBREAKING CHANGEを含める必要があります。

つまり:

 feat: update theme to use theming api v2

BREAKING CHANGE: theme is now relying on functionality that is exclusive to the theming api v2

これによりメジャーリリースが生成され、変更ログにBREAKING CHANGESセクションが追加されます。

バグレポート

バグレポートは、Zendesk の標準サポートチャネル (https://www.zendesk.com/contact/) を通じて送信する必要があります。

拡大する

追加情報

バージョン v4.2.3
タイプその他のソースコード
更新時間 2024-11-13
サイズ 50MB
から Github