רקע¶
ספרייה זו יושבת בנקודת המפגש של שני סיפורים ארוכים — האחד על האופן שבו תוכנה מתורגמת, והשני על האופן שבו Python משבצת ערכים במחרוזות — שסוף-סוף הצטלבו ב-2025 ואז נעצרו בדיוק בנקודה שבה נדרשה מוסכמה קטנה וזהירה. עמוד זה מספר את שני הסיפורים, עם קישורים למקורות, כי קל יותר לשפוט את החלטות העיצוב באתר הזה כשאפשר לראות את השאלות שעליהן הן עונות.
האקוסיסטם של gettext¶
GNU gettext הוא הדרך שבה תוכנה חופשית מתורגמת מאז אמצע שנות התשעים:
מסמנים את המחרוזות בקוד, מחלצים אותן לתבנית, נותנים למתרגמים קובץ
קטלוג אחד לכל שפה, מקמפלים, וטוענים בזמן ריצה. סביב הלולאה הזאת צמח
אקוסיסטם שלם — עורכי PO, תהליכי סקירה ופלטפורמות תרגום שכולם דוברים את
אותו פורמט קובץ — ו-Python מספקת מודול gettext
בספרייה הסטנדרטית שלה כבר יותר משני עשורים. חצי זמן-הריצה של התרגום
מעולם לא היה הבעיה.
החצי הלא-מוכרע היה תמיד איך נראית המחרוזת בקטלוג. הודעת %(name)s
מוסרת למתרגמים תחביר printf שמחיקת אות אחת הופכת אותו לקריסה בסביבת
ייצור; הודעת .format() מוסרת לקטלוג גישה לתכונות של אובייקטים חיים.
(למה מחרוזות-t עובר על שניהם, עם הכשלים מוצגים
לראווה.) ומחרוזות-f — התחביר שרוב קוד ה-Python מעדיף כיום — אינן
יכולות להשתתף כלל: ברגע שספרייה כלשהי רואה אחת מהן, היא כבר מחרוזת
גמורה. אנשים מנסים בכל זאת, לעיתים קרובות דיין כדי שעוקב הבאגים של
Babel יאסוף את הניסיונות (#594, #715); הכשל
הוא מבני, לא פיצ'ר חסר.
שני מסמכי PEP, בהפרש עשר שנים¶
ב-2015 כתבו Alyssa Coghlan ו-Nick Humrich את PEP 501, שהציע תבניות שיבוץ שהמוטיבציה הראשונה המוצהרת שלהן הייתה i18n — "אספקת תחביר נקי יותר לתרגום i18n", במילותיו של ה-PEP עצמו. ההצעה נדחתה למועד מאוחר יותר, בין השאר משום שהדיון הראה שמקרה ה-i18n נושא עימו שיקולים נוספים משמעותיים שמקרי שימוש פשוטים יותר אינם נושאים.
עשור לאחר מכן, PEP 750 — מאת Jim Baker, Guido van Rossum, Paul Everitt, Koudai Aono, Lysandros Nikolaou ו-Dave Peck — החייה את הרעיון בדמות מחרוזות-t, התקבל באפריל 2025, ויצא לאור ב-Python 3.14 באוקטובר 2025. PEP 501 נמשך אז לטובתו. פרט אחד חשוב לעמוד הזה: i18n אינה בין המוטיבציות המוצהרות של PEP 750. ה-PEP הכליל את המנגנון — טיפוס תבנית שכל ספרייה יכולה לצרוך — והשאיר את שאלת התרגום בדיוק במקום שבו PEP 501 החנה אותה עשר שנים קודם לכן: פתוחה.
כך שנכון ל-Python 3.14, לשפה היה בדיוק מבנה הנתונים שקטלוג הודעות זקוק לו — ואף לא מוסכמה אחת לשימוש בו ככזה.
הדיון על הספרייה הסטנדרטית¶
חודשיים לפני צאת 3.14, Adrian Mönnich (הידוע בכינויו ThiefMaster,
מתחזק של פרויקט Indico) הציע לסגור את הפער הזה בספרייה הסטנדרטית עצמה:
השרשור Support t-strings in gettext
ב-discuss.python.org, שנפתח באוגוסט 2025, הגיע עם
pull request עובד שמוסיף תמיכה במחרוזות-t גם ל-gettext
וגם ל-pygettext.
השרשור שווה קריאה במלואו, כי הוא מעלה על פני השטח כל שאלה קשה שהספרייה הזאת נדרשה מאוחר יותר לענות עליה:
- מה מותר לשיבוץ להיות? שם פשוט בלבד, או גם תכונות וקריאות עם שם מציין מקום נגזר? כל תשובה סוחרת נוחות תמורת יציבות msgid ובטיחות הקטלוג.
- מה דורשות צורות הריבוי, כאשר מערכת הריבוי של שפת היעד שונה מזו של שפת המקור?
- האם gettext הוא בכלל היעד הנכון? Barry Warsaw — שטען במהלך
פיתוחו של PEP 750 שמחרוזות-t אינן מתאימות ל-i18n — הצביע על
flufl.i18nשלו ועל סגנון מחרוזות ה-$שבה ככלי הידידותי יותר; אחרים טענו לנטישת gettext כליל לטובת מערכות חדשות יותר כגון Fluent. - ושאלת-העל: מה שהספרייה הסטנדרטית משחררת, למעשה לעולם אינו יכול להשתנות. מוסכמה עם כל כך הרבה בחירות פתוחות היא דבר מסוכן להקפיא בניסיון הראשון.
לא התגבשה הסכמה. סוגיית ה-CPython נסגרה כ"לא מתוכננת" וה-pull request נסגר ללא מיזוג באוקטובר 2025, ימים ספורים אחרי שחרור 3.14. היכולת הייתה קיימת בשפה; למוסכמה לא היה בית.
למה חבילה, קודם¶
זה הפער שהפרויקט הזה בחר למלא מחוץ לספרייה הסטנדרטית, על בסיס הימור מכוון: מוסכמה מבשילה מהר יותר במקום שבו היא יכולה לצאת בגרסאות בחופשיות ולזכות באימוץ מקרה אחר מקרה, והספרייה הסטנדרטית — שחייבת לקלוע בפעם הראשונה — היא המקום שבו מוסכמה צריכה להסתיים, לא המקום שבו היא מתגבשת.
באופן קונקרטי, לכל שאלה שנויה במחלוקת בשרשור יש כאן תשובה כתובה, כל אחת בעמוד משלה:
- שיבוצים הם שמות פשוטים בלבד, כך שה-msgids נשארים יציבים ובעלי משמעות — המדריך מציג את הכלל, איך זה עובד את הסיבות.
- הפורמט נשאר מחוץ לקטלוג לחלוטין (למה מחרוזות-t).
- צורות ריבוי פועלות לפי כלל איחוד/חיתוך שמאפשר למערכת הריבוי של שפת היעד להיות שונה מזו של המקור (מפרט §4).
- קטלוג שבור נסוג לטקסט המקור במקום לקרוס, ושומר על החוזה של gettext עצמו (המדריך).
- והמוסכמה כולה היא מפרט מנוהל-גרסאות עם חבילת בדיקות תאימות קריאה למכונה — כתובה כך שמימוש אחר, לרבות מימוש עתידי בספרייה הסטנדרטית, יוכל לאמץ אותה ללא שינוי ולפעול בתאימות מלאה.
הדיון לא הסתיים, והפרויקט הזה הוא משתתף בו, לא פסק דין עליו. אם יש לכם ניסיון ייצור עם gettext שנוגע לבחירות האלה, אותו שרשור וה-Discussions של המאגר הזה הם המקום שבו הדיון נמשך.
ציר זמן¶
| מתי | מה קרה |
|---|---|
| אמצע שנות התשעים | GNU gettext מכונן את תהליך העבודה של PO/POT/MO, שמתרגמים ופלטפורמות דוברים עד היום. |
| 2015 | PEP 501 מציע תבניות שיבוץ, עם i18n כמוטיבציה הראשונה שלו; נדחה למועד מאוחר יותר. |
| 2016 | מחרוזות-f יוצאות ב-Python 3.6 — השיבוץ מקבל את התחביר שלו, והתרגום אינו יכול להשתמש בו. |
| יולי 2024 | PEP 750 מציע מחרוזות-t. |
| אפריל 2025 | PEP 750 מתקבל; PEP 501 נמשך לטובתו. |
| אוגוסט 2025 | השרשור Support t-strings in gettext נפתח, עם pull request לספרייה הסטנדרטית. |
| אוקטובר 2025 | Python 3.14 יוצא עם מחרוזות-t; סוגיית הספרייה הסטנדרטית נסגרת כלא מתוכננת. |
| 2026 | gettext-tstrings יוצאת כגרסת אלפא, עם מפרט v1 וחבילת בדיקות התאימות שלו. |