diff --git a/src/common/messages/combinedMessages.prod.ts b/src/common/messages/combinedMessages.prod.ts index 00cfdd4c..28603c8c 100644 --- a/src/common/messages/combinedMessages.prod.ts +++ b/src/common/messages/combinedMessages.prod.ts @@ -4,6 +4,7 @@ export const allMessages: Readonly [!INFO]- The connected devices have been detected as follows:\n${devices}": { def: "> [!INFO]- The connected devices have been detected as follows:\n${devices}", @@ -189,46 +207,55 @@ export const allMessages: Readonly Storage": { def: "Database -> Storage", @@ -1114,6 +1200,7 @@ export const allMessages: Readonly ${remote})": { def: "Higher (${local} > ${remote})", es: "Superior (${local} > ${remote})", ko: "더 높음 (${local} > ${remote})", + "zh-tw": "較高（${local} > ${remote}）", }, "Highlight diff": { def: "Highlight diff", @@ -2391,6 +2564,7 @@ export const allMessages: Readonly [!MORE]-\n> If you have been using it for many years, there may be unreferenced chunks - that is, garbage - accumulating in the database. Therefore, we recommend rebuilding everything. It will probably become much smaller.\n>\n> If the volume of your vault is simply increasing, it is better to rebuild everything after organizing the files. Self-hosted LiveSync does not delete the actual data even if you delete it to speed up the process. It is roughly [documented](https://github.com/vrtmrz/obsidian-livesync/blob/main/docs/tech_info.md).\n>\n> If you don't mind the increase, you can increase the notification limit by 100MB. This is the case if you are running it on your own server. However, it is better to rebuild everything from time to time.\n>\n\n> [!WARNING]\n> If you perform rebuild everything, make sure all devices are synchronised. The plug-in will merge as much as possible, though.\n", @@ -3583,6 +3864,8 @@ export const allMessages: Readonly [!MORE]-\n> 오랜 기간 사용했다면 참조되지 않는 청크, 즉 쓰레기 데이터가 데이터베이스에 쌓였을 수 있습니다. 이 경우 전체 재구축을 권장합니다. 용량이 훨씬 줄어들 것입니다.\n>\n> 단순히 보관함 용량이 커지고 있는 것이라면, 파일을 정리한 뒤에 전체를 재구축하는 것이 좋습니다. Self-hosted LiveSync는 처리 속도를 위해 파일을 삭제해도 실제 데이터를 바로 지우지 않습니다. 이 내용은 [기술 문서](https://github.com/vrtmrz/obsidian-livesync/blob/main/docs/tech_info.md)에 간략히 정리되어 있습니다.\n>\n> 용량 증가가 괜찮다면 알림 한도를 100MB 단위로 높일 수 있습니다. 직접 서버를 운영하는 경우에 적합한 방법입니다. 다만 가끔은 전체를 재구축해 주는 것이 좋습니다.\n>\n\n> [!WARNING]\n> 전체 재구축을 실행할 때는 모든 기기가 동기화되어 있는지 확인해 주세요. 플러그인이 최대한 병합하려고 시도하기는 합니다.\n", ru: "Ваша база данных увеличивается! Но не волнуйтесь, мы можем решить это сейчас.", zh: "**您的数据库正在变大！** 但别担心,我们现在可以解决它。在远程存储空间用完之前还有时间。\n\n| 测量大小 | 配置大小 |\n| --- | --- |\n| ${estimatedSize} | ${maxSize} |\n\n> [!MORE]-\n> 如果您已经使用了很多年,数据库中可能会积累未引用的 chunks——也就是垃圾。因此,我们建议重建所有内容。它可能会变得小得多。\n>\n> 如果您的库容量只是在增加,最好在整理文件后重建所有内容。即使您为了加速过程删除了文件,Self-hosted LiveSync 也不会删除实际数据。这大致[有文档记录](https://github.com/vrtmrz/obsidian-livesync/blob/main/docs/tech_info.md)。\n>\n> 如果您不介意增加,可以将通知限制增加 100MB。如果您在自己的服务器上运行,就是这种情况。但是,最好还是不时地重建所有内容。\n>\n\n> [!WARNING]\n> 如果您执行重建所有内容,请确保所有设备都已同步。尽管如此,插件会尽可能地合并\n", + "zh-tw": + "**你的資料庫正在變大！** 但不用擔心，我們現在就可以處理。在遠端儲存空間用盡之前還有一些時間。\n\n| 測量大小 | 設定大小 |\n| --- | --- |\n| ${estimatedSize} | ${maxSize} |\n\n> [!MORE]-\n> 如果你已經使用了好幾年，資料庫中可能累積了未被參照的 chunks，也就是垃圾資料。因此，我們建議重建全部內容，通常會讓資料庫變得小很多。\n>\n> 如果你的 Vault 容量只是持續增加，最好先整理檔案再重建全部內容。即使你為了加快速度而刪除了檔案，Self-hosted LiveSync 也不會刪除實際資料，詳情大致記載在[文件](https://github.com/vrtmrz/obsidian-livesync/blob/main/docs/tech_info.md)中。\n>\n> 如果你不在意容量增加，可以將通知上限調高 100MB，這在你自行架設伺服器時較適用。不過，還是建議偶爾重建全部內容。\n>\n\n> [!WARNING]\n> 若要執行重建全部內容，請確保所有裝置都已同步。不過外掛會盡可能地進行合併。", }, "moduleCheckRemoteSize.msgSetDBCapacity": { def: "We can set a maximum database capacity warning, **to take action before running out of space on the remote storage**.\nDo you want to enable this?\n\n> [!MORE]-\n> - 0: Do not warn about storage size.\n> This is recommended if you have enough space on the remote storage especially you have self-hosted. And you can check the storage size and rebuild manually.\n> - 800: Warn if the remote storage size exceeds 800MB.\n> This is recommended if you are using fly.io with 1GB limit or IBM Cloudant.\n> - 2000: Warn if the remote storage size exceeds 2GB.\n\nIf we have reached the limit, we will be asked to enlarge the limit step by step.\n", @@ -3593,16 +3876,20 @@ export const allMessages: Readonly [!MORE]-\n> - 0: 스토리지 용량을 경고하지 않습니다.\n> 직접 서버를 운영하는 등 원격 스토리지에 여유 공간이 충분한 경우에 권장합니다. 스토리지 용량을 직접 확인하고 수동으로 재구축할 수 있습니다.\n> - 800: 원격 스토리지 용량이 800MB를 초과하면 경고합니다.\n> 1GB 제한이 있는 fly.io나 IBM Cloudant를 사용하는 경우에 권장합니다.\n> - 2000: 원격 스토리지 용량이 2GB를 초과하면 경고합니다.\n\n한도에 도달하면 한도를 단계적으로 늘릴지 여쭤보겠습니다.\n", ru: "Можно установить предупреждение о максимальной ёмкости базы данных.", zh: "我们可以设置一个最大数据库容量警告,**以便在远程存储空间耗尽前采取行动**。\n您想启用这个功能吗?\n\n> [!MORE]-\n> - 0: 不警告存储大小。\n> 如果您在远程存储(尤其是自托管)上有足够的空间,则推荐此选项。您可以手动检查存储大小并重建。\n> - 800: 如果远程存储大小超过 800MB 则发出警告。\n> 如果您使用的是 fly.io(1GB 限制) 或 IBM Cloudant,则推荐此选项。\n> - 2000: 如果远程存储大小超过 2GB 则发出警告。\n\n如果达到限制,系统会要求我们逐步增大限制\n", + "zh-tw": + "我們可以設定資料庫容量上限警告，**以便在遠端儲存空間用盡之前及早採取行動**。\n你要啟用這個功能嗎？\n\n> [!MORE]-\n> - 0：不警告儲存空間大小。\n> 如果你在遠端儲存空間（尤其是自行架設）有足夠空間，建議選擇此項；你也可以自行手動檢查儲存空間大小並重建。\n> - 800：遠端儲存空間大小超過 800MB 時警告。\n> 如果你使用限制為 1GB 的 fly.io 或 IBM Cloudant，建議選擇此項。\n> - 2000：遠端儲存空間大小超過 2GB 時警告。\n\n如果達到上限，系統會要求逐步提高限制。", }, "moduleCheckRemoteSize.noticeExceeded": { def: "Remote storage size is ${measuredSize}, above the configured ${notifySize} notification threshold. {HERE}", es: "El tamaño del almacenamiento remoto es de ${measuredSize}, por encima del umbral de aviso configurado de ${notifySize}. {HERE}", ko: "원격 스토리지 크기 ${measuredSize}이(가) 설정된 알림 임계값 ${notifySize}을(를) 초과했습니다. {HERE}", + "zh-tw": "遠端儲存空間大小為 ${measuredSize}，已超過設定的 ${notifySize} 通知閾值。{HERE}", }, "moduleCheckRemoteSize.noticeNotConfigured": { def: "Remote storage size notifications are not configured. {HERE}", es: "Los avisos sobre el tamaño del almacenamiento remoto no están configurados. {HERE}", ko: "원격 스토리지 크기 알림이 설정되어 있지 않습니다. {HERE}", + "zh-tw": "尚未設定遠端儲存空間大小通知。{HERE}", }, "moduleCheckRemoteSize.option2GB": { def: "2GB (Standard)", @@ -3613,6 +3900,7 @@ export const allMessages: Readonly [!DETAILS]-\n> These flags are set by the plug-in while rebuilding, or fetching. If the process ends abnormally, it may be kept unintended.\n> If you are not sure, you can try to rerun these processes. Make sure to back your vault up.\n", @@ -3894,6 +4193,7 @@ export const allMessages: Readonly[!INFO]- 자세히\n> ## 가져오기 전에 로컬 데이터베이스를 한 번 생성.\n> **낮은 트래픽**, **높은 CPU**, **낮은 위험**\n> 원격에서 데이터를 가져오기 전에 기존 로컬 파일로 로컬 데이터베이스를 먼저 만듭니다.\n> 로컬과 원격 양쪽에 일치하는 파일이 있으면 둘 사이의 차이만 전송됩니다.\n> 다만 양쪽에 모두 있는 파일은 처음에 충돌 파일로 처리됩니다. 실제로 충돌하지 않는다면 자동으로 해결되지만, 이 과정에 시간이 걸릴 수 있습니다.\n> 일반적으로 가장 안전한 방법이며 데이터 손실 위험이 가장 낮습니다.\n> ## 가져오기 전에 로컬 파일 청크 생성.\n> **낮은 트래픽**, **보통 CPU**, **낮음~보통 위험** (작업에 따라 다름)\n> 먼저 로컬 파일로 데이터베이스용 청크를 만든 다음 데이터를 가져옵니다. 따라서 로컬에 없는 청크만 전송됩니다. 다만 메타데이터는 모두 원격에서 가져옵니다.\n> 그다음 시작 시점에 로컬 파일을 이 메타데이터와 비교합니다. 수정 시각을 기준으로 더 새롭다고 판단된 내용이 오래된 쪽을 덮어씁니다. 그 결과는 다시 원격 데이터베이스로 동기화됩니다.\n> 로컬 파일이 실제로 가장 최신 타임스탬프를 가지고 있다면 대체로 안전합니다. 하지만 타임스탬프는 더 새롭지만 내용은 더 오래된 파일(처음 만들어지는 `welcome.md` 같은)이 있으면 문제가 생길 수 있습니다.\n> \"가져오기 전에 로컬 데이터베이스를 한 번 생성\"보다 CPU를 적게 쓰고 더 빠르지만, 주의해서 사용하지 않으면 데이터가 손실될 수 있습니다.\n> ## 원격에서 모든 것 가져오기.\n> **높은 트래픽**, **낮은 CPU**, **낮음~보통 위험** (작업에 따라 다름)\n> 모든 것을 원격에서 가져옵니다.\n> 가져오기 전에 로컬 파일 청크 생성와 비슷하지만, 모든 청크를 원격에서 가져옵니다.\n> 가장 전통적인 가져오기 방식으로, 보통 네트워크 트래픽과 시간을 가장 많이 소모합니다. 또한 '가져오기 전에 로컬 파일 청크 생성' 옵션과 마찬가지로 원격 파일을 덮어쓸 위험이 있습니다.\n> 다만 가장 오래되고 단순한 방식이기 때문에 가장 안정적인 방법으로 여겨지는 경우가 많습니다.", ru: "Как вы хотите загрузить?", zh: "How do you want to fetch?\n- Create a local database once before fetching.\n **Low Traffic**, **High CPU**, **Low Risk**\n Recommended if ...\n - Files possibly inconsistent\n - Files were not so much\n- Create local file chunks before fetching.\n **Low Traffic**, **Moderate CPU**, **Low to Moderate Risk**\n Recommended if ...\n - Files probably consistent\n - You have a lot of files.\n- Fetch everything from the remote.\n **High Traffic**, **Low CPU**, **Low to Moderate Risk**\n\n>[!INFO]- Details\n> ## Create a local database once before fetching.\n> **Low Traffic**, **High CPU**, **Low Risk**\n> This option first creates a local database using existing local files before fetching data from the remote source.\n> If matching files exist both locally and remotely, only the differences between them will be transferred.\n> However, files present in both locations will initially be handled as conflicted files. They will be resolved automatically if they are not actually conflicted, but this process may take time.\n> This is generally the safest method, minimizing data loss risk.\n> ## Create local file chunks before fetching.\n> **Low Traffic**, **Moderate CPU**, **Low to Moderate Risk** (depending operation)\n> This option first creates chunks from local files for the database, then fetches data. Consequently, only chunks missing locally are transferred. However, all metadata is taken from the remote source.\n> Local files are then compared against this metadata at launch. The content considered newer will overwrite the older one (by modified time). This outcome is then synchronised back to the remote database.\n> This is generally safe if local files are genuinely the latest timestamp. However, it can cause problems if a file has a newer timestamp but older content (like the initial `welcome.md`).\n> This uses less CPU and faster than \"Create a local database once before fetching\", but it may lead to data loss if not used carefully.\n> ## Fetch everything from the remote.\n> **High Traffic**, **Low CPU**, **Low to Moderate Risk** (depending operation)\n> All things will be fetched from the remote.\n> Similar to the Create local file chunks before fetching, but all chunks are fetched from the remote source.\n> This is the most traditional way to fetch, typically consuming the most network traffic and time. It also carries a similar risk of overwriting remote files to the 'Create local file chunks before fetching' option.\n> However, it is often considered the most stable method because it is the longest-established and most straightforward approach.", + "zh-tw": + "你想要如何抓取？\n- 先建立一次本機資料庫，再抓取。\n **低流量**、**高 CPU 使用率**、**低風險**\n 建議情況：\n - 檔案可能不一致\n - 檔案數量不多\n- 先建立本機檔案的 chunks，再抓取。\n **低流量**、**中等 CPU 使用率**、**低至中等風險**\n 建議情況：\n - 檔案應該是一致的\n - 你有大量檔案\n- 從遠端抓取所有內容。\n **高流量**、**低 CPU 使用率**、**低至中等風險**\n\n>[!INFO]- 詳細說明\n> ## 先建立一次本機資料庫，再抓取。\n> **低流量**、**高 CPU 使用率**、**低風險**\n> 這個選項會先使用現有的本機檔案建立本機資料庫，再從遠端來源抓取資料。\n> 若本機與遠端都存在相符的檔案，只會傳輸兩者之間的差異部分。\n> 不過，兩邊都存在的檔案一開始會被當作衝突檔案處理。若實際上並無衝突，會自動解決，但這個過程可能需要一些時間。\n> 這通常是最安全的方式，能將資料遺失的風險降到最低。\n> ## 先建立本機檔案的 chunks，再抓取。\n> **低流量**、**中等 CPU 使用率**、**低至中等風險**（依操作而異）\n> 這個選項會先從本機檔案為資料庫建立 chunks，再抓取資料。因此只會傳輸本機缺少的 chunks，但所有中繼資料都會取自遠端來源。\n> 啟動時本機檔案會與這份中繼資料比對，內容較新的一方（依修改時間判斷）會覆寫較舊的一方，其結果會同步回遠端資料庫。\n> 如果本機檔案的時間戳記確實是最新的，這通常是安全的；但如果某個檔案時間戳記較新卻內容較舊（例如初始的 `welcome.md`），可能會出問題。\n> 這比「先建立一次本機資料庫，再抓取」耗用更少 CPU、速度也更快，但若不小心使用可能導致資料遺失。\n> ## 從遠端抓取所有內容。\n> **高流量**、**低 CPU 使用率**、**低至中等風險**（依操作而異）\n> 所有內容都會從遠端抓取。\n> 與「先建立本機檔案的 chunks，再抓取」類似，但所有 chunks 都是從遠端來源抓取。\n> 這是最傳統的抓取方式，通常會耗用最多的網路流量與時間，覆寫遠端檔案的風險也與「先建立本機檔案的 chunks，再抓取」選項相近。\n> 不過，由於這是歷史最久、最直接的做法，通常被認為是最穩定的方式。", }, "RedFlag.Fetch.Method.FetchSafer": { def: "Create a local database once before fetching", @@ -7391,6 +7835,7 @@ export const allMessages: Readonly