copenhagen_theme
v4.2.3
哥本哈根主題是預設的 Zendesk Guide 主題。它被設計為響應靈敏且易於訪問。在此處了解有關自訂 Zendesk 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下建立檔案來完成此操作。在這裡了解更多。
我們使用 Rollup 來編譯主題中使用的 JS 和 CSS 檔案 - style.css和script.js 。不要直接編輯它們，因為它們將在發布期間重新生成。
開始使用：
$ 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 開始，哥本哈根主題使用一些 React 元件來渲染部分 UI。這些元件位於src/modules資料夾中，並使用 Zendesk Garden 元件庫建置。
作為 Rollup 建置過程的一部分，這些元件會作為本機 JavaScript 模組捆綁在一起，並在assets資料夾中作為 JS 檔案發出。由於安裝主題時資產會被重新命名，因此需要使用資產助理匯入模組。
為了讓導入模組的過程更容易，我們添加了一個 Rollup 插件，它會產生一個導入映射，將模組名稱映射到資產 URL。然後在建置過程中將此導入映射注入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" ,
} ,
// ...
}
] ) ; Rollup 會在assets資料夾中產生一個名為my-module-bundle.js的文件，而此導入映射將會被加入到document_head.hbs範本中：
< script type =" importmap " >
{
"imports" : {
"my-module" : "{{asset 'my-module-bundle.js'}}" ,
}
}
</ script >然後，您可以像這樣在模板中匯入模組：
I18n 是使用 React-i18next 函式庫在 React 元件中實現的。我們使用平面 JSON 文件，並使用.作為複數的分隔符，與預設的_不同，它是在初始化期間配置的。
我們還添加了一些工具，以便能夠將該庫與 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 的自訂節點腳本來進行自動可訪問性測試。
運行腳本有兩種方式：
zcli themes:preview才能運作；根據測試範圍，除了上述之外，可能還需要一些手動測試。 ax DevTools、螢幕閱讀器（例如 VoiceOver、對比度檢查器等）等工具可以協助此類測試。
要在更改主題時運行可訪問性審核：
$ yarn install
$ yarn start在根資料夾中建立一個.a11yrc.json檔案（請參閱範例）；
zcli設定檔匹配username和password ；urls （如果留空，腳本將測試所有 url）；在單獨的控制台中，在開發模式下運行可訪問性審核：
yarn test-a11y -d然後，A11y 審核將在步驟1中開始的預覽上執行。
要對特定帳戶的即時主題運行可訪問性審核，必須：
yarn installend_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 如果存在應忽略或無法立即修復的已知可訪問性問題，則可以在腳本配置物件的忽略清單中新增一個條目。這會將可訪問性問題轉變為警告而不是錯誤。
該條目應包括：
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)]
IE：
chore: automate release
fix(styles): fix button padding
feat(script): add auto focus to fields with errors
我們在提交時使用husky和commitlint來驗證訊息。
一旦 PR 合併，我們就會使用 Github actions 和semantic-release來發布主題的新版本。在每次合併時， semantic-release都會分析提交訊息並推斷語義版本衝突。然後它會建立一個 git 標籤，更新清單版本並產生相應的變更日誌。
下面的清單描述了支援的提交類型及其在發布和變更日誌中的影響。
| 類型 | 描述 | 發布 | 變更日誌 |
|---|---|---|---|
| 建造 | 影響建置系統或外部相依性的更改 | - | - |
| 雜務 | 其他不修改原始碼的更改 | - | - |
| 字 | CI 設定檔和腳本的更改 | - | - |
| 文件 | 僅文檔更改 | - | - |
| 壯舉 | 一個新功能 | 次要的 | 特徵 |
| 使固定 | 錯誤修復 | 修補 | 錯誤修復 |
| 效能 | 提高效能的程式碼更改 | 修補 | 性能改進 |
| 重構 | 既不修復錯誤也不添加功能的程式碼更改 | - | - |
| 恢復 | 恢復之前的提交 | 修補 | 恢復 |
| 風格 | 不影響程式碼意義的變更（空格、格式、缺少分號等） | - | - |
| 測試 | 添加缺失的測試或修正現有測試 | - | - |
新增重大變更的提交應在提交訊息的正文或頁腳中包含BREAKING CHANGE 。
IE：
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/
