Updates in HE,TR,ZH-CN

content/he/docs/client-options.md

@@ -37,5 +37,7 @@ lastmod: 2025-01-22
 1. הלקוח מכבד את [מדיניות סימני המסחר של Let's Encrypt](https://www.abetterinternet.org/trademarks).
 1. הלקוח אינו מבוסס דפדפן ותומך בחידושים אוטומטיים.
 1. הלקוח מבצע [חידושים שגרתיים במועדים אקראיים](/docs/integration-guide#when-to-renew), או מעודד הגדרה שכזאת.
-1. ההגשה שלך מוסיפה את הלקוח המוצע ל**סוף** הסעיפים המתאימים (לא לשכוח את „acme_v2” אם יש צורך!).
+1. הקיבוע (commit) שלך מוסיף את הלקוח שלך ל**סוף** הסעיף המתאים.
 1. ההגשה שלך מעדכנת את חותמת התאריך של `lastmod` (שינוי אחרון) בראש הקובץ `clients.json`.
+
+אנחנו נסיר מדי פעם בפעם רשומות של מיזמים שנראה שהפיתוח שלהם נפסק. אם עבודת הפיתוח של מיזם ממשיכה, אפשר להגיד בקשת דחיפה (pull request) להוספת המיזם הזה שוב.

content/he/docs/godaddy.md

@@ -1,14 +1,15 @@
 ---
 title: "אישורי Let's Encrypt באירוח של GoDaddy"
 slug: godaddy
-lastmod: 2025-07-31
+lastmod: 2025-08-11
 show_lastmod: 1
 ---
 
-אנו מקבלים שאלות רבות בנוגע לשימוש ב־Let’s Encrypt עם GoDaddy. כרגע אנחנו לא ממליצים להשתמש באישורים שלנו עם GoDaddy כיוון שזה מסובך ואי אפשר ליצור אוטומציה של התהליך.
+אנו מקבלים שאלות רבות בנוגע לשימוש ב־Let’s Encrypt עם GoDaddy. ב־GoDaddy אין תמיכה ב[פרוטוקול ACME](https://tools.ietf.org/html/rfc8555) להנפקה וחידוש אישורים אוטומטית. במקום, מציעים ב־GoDaddy חידוש אוטומטי עם אישורים משלהם, שהם [בתוספת תשלום](https://www.godaddy.com/web-security/ssl-certificate).
 
-ב־GoDaddy אין תמיכה ב[פרוטוקול ACME](https://tools.ietf.org/html/rfc8555) להנפקה וחידוש אישורים אוטומטית. במקום, מציעים ב־GoDaddy חידוש אוטומטי עם אישורים משלהם, שהם [בתוספת תשלום](https://www.godaddy.com/web-security/ssl-certificate).
+כרגע אנחנו לא ממליצים להשתמש באישורים שלנו עם GoDaddy כיוון שזה מסובך ואי אפשר ליצור אוטומציה של התהליך. אנו חושבים שחידושים אוטומטיים חשובים לניהול אישורים. השימוש ברכיב תוכנה כדי לחדש אוטומטית מוריד את הסבירות שתוקף האישור שלך יפוג מבלי שיוחלף.
 
-אנו חושבים שחידושים אוטומטיים חשובים לניהול אישורים. השימוש ברכיב תוכנה כדי לחדש אוטומטית מוריד את הסבירות שתוקף האישור שלך יפוג מבלי שיוחלף.
+אם עדיין מעניין אותך לנסות להשתמש באישורי Let’s Encrypt עם אירוח משותף של GoDaddy, אפשר לבחון את האפשרויות הבאות:
 
-אם, לאחר שהבנת את הבעיות שמוצגות כאן, החלטת שמעניין אותך לנסות לתחזק אישור של Let’s Encrypt על גבי אחסון משותף של GoDaddy, ישנן [הנחיות](https://www.godaddy.com/help/install-a-lets-encrypt-certificate-on-your-cpanel-hosting-account-28023) שסופקו על ידי GoDaddy. איננו יכולים להתחייב על הדיוק שלהם. כדאי לשים לב שמעקב אחר ההוראות האלה גוזל זמן רב וזאת פעולה שאמורה להתבצע באופן מחזורי, לפני פקיעת תוקף של כל אחד מהאישורים.
+1. להשתמש ב־[CertSage](https://certsage.com/) מבית Griffin Software. משתמשי Let's Encrypt אחרים ב־GoDaddy הצליחו בעזרתו.
+2. GoDaddy [מספקים הנחיות](https://www.godaddy.com/help/install-a-lets-encrypt-certificate-on-your-cpanel-hosting-account-28023). איננו יכולים להתחייב על הדיוק או הנכונות שלהם. כדאי לשים לב שמעקב אחר ההוראות האלה גוזל זמן רב וזאת פעולה שאמורה להתבצע באופן מחזורי, לפני פקיעת תוקף של כל אחד מהאישורים.

content/he/how-it-works.md

@@ -2,15 +2,15 @@
 title: כיצד זה עובד
 linkTitle: כיצד Let's Encrypt עובד
 slug: how-it-works
-lastmod: 2025-07-31
+lastmod: 2025-08-02
 show_lastmod: 1
 ---
 
-המטרה של Let's Encrypt ושל [פרוטוקול ACME](https://tools.ietf.org/html/rfc8555) היא לאפשר להקים שרת HTTPS ושהוא ימשוך אוטומטית אישורים מהימנים לדפדפן, ללא התערבות של בן אדם. אפשר להשיג את זה על ידי הרצת לקוח ACME על שרת האתר.
+המטרה של Let's Encrypt ושל [פרוטוקול ACME](https://tools.ietf.org/html/rfc8555) היא לאפשר להקים שרת HTTPS ושהוא ימשוך אוטומטית אישורים מהימנים מבחינת הדפדפן, ללא התערבות של בן אדם. אפשר להשיג את זה על ידי הרצת לקוח ACME על שרת אתר.
 
 כדי להבין איך הטכנולוגיה הזו עובדת, הבה נעבור על תהליך הגדרת `https://example.com/` עם לקוח ACME.
 
-לתהליך זה שני שלבים. קודם, לקוח ה־ACME מוכיח ל[רשות האישורים](https://simple.wikipedia.org/wiki/Certificate_authority) (CA) שהשרת שולט בשם התחום. לאחר מכן, הסוכן יכול לבקש, לחדש ולשלול אישורים עבור שם התחום הזה.
+לתהליך זה שני שלבים. קודם, לקוח ה־ACME מוכיח ל[רשות האישורים](https://wikipedia.org/wiki/Certificate_authority) (CA) שהשרת שולט בשם התחום. לאחר מכן הלקוח יכול לבקש או לשלול אישורים לשם התחום הזה.
 
 ## תיקוף שם תחום
 
@@ -37,22 +37,25 @@ Let's Encrypt מזהה את תוכנת לקוח ה־ACME באמצעות [מפת
 
 לאחר השלמת האתגרים בהצלחה, הלקוח שמזוהה על ידי המפתח הציבורי מורשה לבצע ניהול אישורים עבור `example.com`.
 
+נא לשים לב שהתהליך הזה לא יכול להשתמש ב־HTTPS, מה שהופך אותו לפגיע למתקפות מסוימות. כדי למזער את הבעיה הזאת, המנגנון של Let's Encrypt מבצע למעשה מגוון אימותים במקביל ממגוון היבטי רשת. ההתנהלות הזאת מקשה מאוד על תוקפים להטות את תהליך התיקוף.
 
 ## הנפקה ושלילה של אישורים
 
 לאחר שהלקוח קיבל אישור, בקשה, חידוש ושלילה של אישורים היא פשוטה - צריך פשוט לשלוח הודעות ניהול אישורים ולחתום עליהן עם חשבון צמד המפתחות המורשה.
 
 ### הנפקה
 
-כדי להשיג אישור עבור שם התחום, הסוכן מרכיב [בקשת חתימת אישור - Certificate Signing Request ‏(CSR)](https://tools.ietf.org/html/rfc2986) בתצורת PKCS#10 שמבקשת מרשות האישורים Let'sEncrypt להנפיק אישור עבור `example.com` עם מפתח ציבורי מסוים. כרגיל, ה־CSR כולל חתימה במפתח הפרטי שתואם למפתח הציבורי שב־CSR. הסוכן גם חותם על כל ה־CSR עם המפתח המורשה עבור `example.com` כדי שרשות האישורים Let'sEncrypt תדע שהוא מורשה.
+כדי להשיג אישור עבור שם התחום, הלקוח מרכיב [בקשת חתימת אישור - Certificate Signing Request ‏(CSR)](https://tools.ietf.org/html/rfc2986) בתצורת PKCS#10 שמבקשת מרשות האישורים Let'sEncrypt להנפיק אישור עבור `example.com` עם מפתח ציבורי מסוים. כרגיל, ה־CSR כולל חתימה במפתח הפרטי שתואם למפתח הציבורי שב־CSR. הלקוח גם חותם על כל ה־CSR עם המפתח המורשה עבור `example.com` כדי שרשות האישורים Let'sEncrypt תדע שהוא מורשה.
 
-כאשר רשות האישורים Let'sEncrypt מקבלת את האישור, היא מאמתת את שתי החתימות. אם הכול נראה טוב, היא מנפיקה אישור עבור `example.com` עם המפתח הציבורי מתוך בקשת חתימת האישור (CSR) ומחזירה אותו אל הסוכן. רשות האישורים גם תגיש את האישור למגוון יומני שקיפות אישורים (CT) ציבוריים. לפרטים נוספים ניתן לגשת ל[כאן](https://certificate.transparency.dev/howctworks/#pki).
+כאשר רשות האישורים Let'sEncrypt מקבלת את האישור, היא מאמתת את שתי החתימות. אם הכול נראה טוב, היא מנפיקה אישור עבור `example.com` עם המפתח הציבורי מתוך בקשת חתימת האישור (CSR) ומחזירה אותו אל הלקוח. רשות האישורים גם תגיש את האישור למגוון יומני שקיפות אישורים (CT) ציבוריים. לפרטים נוספים ניתן לגשת ל[כאן](https://certificate.transparency.dev/howctworks/#pki).
 
 <div class="howitworks-figure">
 <img alt="בקשת אישור עבור example.com"
      src="/images/howitworks_certificate.png"/>
 </div>
 
+חידוש אישור במועד מאוחר יותר משמעותו חזרה על תהליך ההנפקה מההתחלה - ביצוע אימות שם תחום ואז בקשת אישור חדש.
+
 ### שלילה
 
 השלילה עובדת באופן דומה. הלקוח חותם על בקשת שלילה עם חשבון צמד המפתחות שמורשים עבור `example.com`, ורשות האישורים Let'sEncrypt מוודאה שהבקשה מורשית. אם התהליך צלח, פרטי השלילה מפורסמים דרך [רשימת שלילת אישורים](https://en.wikipedia.org/wiki/Certificate_revocation_list) (CRL), כך שגופים נסמכים כגון דפדפנים יכולים לדעת שהם לא אמורים לקבל את האישור שנשלל.

content/tr/stats-dashboard.html

@@ -2,7 +2,7 @@
 layout: blank
 title: Let's Encrypt İstatistikleri
 slug: stats-dashboard
-date: 2018-04-12
+lastmod: 2018-04-12
 ---
 
 <!-- This is used as a full-screen display by various parties, including

content/tr/thankyou.md

@@ -1,7 +1,7 @@
 ---
 title: Teşekkürler
 slug: thankyou
-date: 2022-12-02
+lastmod: 2022-12-02
 ---
 
   <div class="container">

content/zh-cn/docs/client-options.md

@@ -37,5 +37,7 @@ Python 模块[acme](https://github.com/certbot/certbot/tree/main/acme) 是 Certb
 1. 该客户端尊重 [Let's Encrypt 商标政策](https://www.abetterinternet.org/trademarks)。
 1. 该客户端不是基于浏览器使用的，并且支持自动续期。
 1. 该客户端的[自动续期时间点是随机的](/docs/integration-guide#when-to-renew)，或鼓励按这种方式配置。
-1. 您的提交把该软件加至相关列表的**末尾**（如果该软件支持 ACMEv2 协议，请不要忘记添加“acme_v2”）。
+1. 您在修改代码时将该客户端添加至相关列表的**末尾**。
 1. 您的提交更新了 `clients.json` 顶部的 `lastmod` 日期戳。
+
+我们可能会定期移除停止维护的客户端或项目。 如果将来开发进程恢复，欢迎再次发起 Pull Request 重新将该项目加入列表中。

content/zh-cn/docs/ct-logs.html

@@ -1,7 +1,7 @@
 ---
 title: 证书透明化 (CT) 日志
 slug: ct-logs
-lastmod: 2023-09-25
+lastmod: 2025-08-27
 show_lastmod: 1
 ---
 
@@ -13,9 +13,8 @@
 </p>
 
 <p>
-  Let's Encrypt 签发的所有证书都会录入 CT 日志。 我们还有两套按年度分片的自营 CT 系统，<a href="https://letsencrypt.org/2019/05/15/introducing-oak-ct-log.html"
-    >Oak</a
-> 和 Sapling。 欢迎所有可信的证书颁发机构将证书提交至我们的日志。 我们的CT日志中已包含许多证书颁发机构的根证书。 如果您所经营的证书颁发机构不在我们的可信颁发者列表中，请在<a href="https://github.com/letsencrypt/ct-log-metadata">此处</a>发起 Issue。
+  Let's Encrypt 签发的所有证书都会录入 CT 日志。 同时我们也运作着若干 CT 日志系统，
+  欢迎所有可信的证书颁发机构将证书提交至我们的日志。 我们的CT日志中已包含许多证书颁发机构的根证书。 如果您所经营的证书颁发机构不在我们的可信颁发者列表中，请在<a href="https://github.com/letsencrypt/ct-log-metadata">此处</a>发起 Issue。
 </p>
 
 <p>
@@ -50,6 +49,22 @@ <h2>CT 日志服务器</h2>
 CT 日志在其生命期内所经历的各种状态可在<a href="https://googlechrome.github.io/CertificateTransparency/log_states.html">此处</a>详细了解。
 </p>
 
+<h3>Sunlight</h3>
+<p>
+  Let's Encrypt 正在逐步将日志系统转移至 <a href="https://sunlight.dev">Sunlight</a>。
+  各日志系统接受的根证书、公钥、日志 ID、分片间隔等信息可以在下方列出的各系统首页中查询。
+</p>
+<p>我们新部署的生产环境 CT 日志系统是 Sycamore 和 Willow，只接受由可信的 CA 颁发的证书。</p>
+<ul>
+  <li><b>Sycamore</b>: <a href="https://log.sycamore.ct.letsencrypt.org/">log.sycamore.ct.letsencrypt.org</a></li>
+  <li><b>Willow</b>: <a href="https://log.willow.ct.letsencrypt.org/">log.willow.ct.letsencrypt.org</a></li>
+</ul>
+<p>用于测试日志系统为 Twig，既接受由可信 CA 颁发的证书，也接受由某些测试 CA 颁发的证书，包括 Let's Encrypt 测试环境的证书。</p>
+<ul>
+  <li><b>Twig</b>: <a href="https://log.twig.ct.letsencrypt.org/">log.twig.ct.letsencrypt.org</a></li>
+</ul>
+
+
 {{< ct_logs data="production" >}}
 <li>
   Oak 已被 <a href="https://support.apple.com/en-us/HT209255">Apple</a> 和 <a href="https://github.com/chromium/ct-policy/blob/master/ct_policy.md"
@@ -75,19 +90,8 @@ <h2>CT 日志服务器</h2>
 <li>
   其他证书颁发机构也可以使用 Sapling 进行测试。
 </li>
-{{< /ct_logs >}} {{< ct_logs data="Sunlight" >}}
-<li>
-  Let's Encrypt 正在测试基于 <a href="https://sunlight.dev">Sunlight</a> 运作的日志系统。
-</li>
-<li>
-  公开可信的证书<b>不应</b>含有此日志系统的 SCT。
-</li>
-<li>Twig 将继续作为测试日志，所接受的 CA 与 Sapling 相同。
-</li>
-<li>Willow 与 Sycamore 所接受的 CA 与 Oak 相同，最终计划作为生产环境日志。
-</li>
 {{< /ct_logs >}}
-<br />
+
 <h2>日志操作</h2>
 <p>
   如需查看某一 CT 日志系统包含的所有根证书，可以在任意 UNIX 命令行中执行以下命令：