בינאום (i18n) של תבניות ותוספי WordPress: הפכו את הקוד למוכן לתרגום

הפכו תבנית או תוסף של WordPress למוכנים לתרגום: text domain, __() ו־_n(), קובץ POT בעזרת WP-CLI, ואז טעינת קובצי .mo, .json ו־.l10n.php.

משתמשים ב־Claude Code, ב־Codex או ב־Cursor?

חברו את PTC לסוכן שלכם והיא תעשה זאת עבורכם: היא לומדת את האפליקציה שלכם, שואלת אתכם רק את מה שהקוד לא יכול לענות עליו, ומתרגמת וסוקרת כל שפה. פרומפט אחד:

בצעו לוקליזציה לאפליקציה זו לגרמנית ולספרדית עם PTC.

חבר את PTC לסוכן שלך

הכינו את התבנית או התוסף שלכם ב־WordPress לתרגום. מדריך זה מכסה text domains, פונקציות gettext, יצירת POT ומנגנון הטעינה שמציג את התרגומים למשתמשים. לאחר מכן, PTC (Private Translation Cloud) מתרגמת את קובצי המשאבים וסוקרת חזותית את התבנית או התוסף המרונדרים בכל שפה.

רוצים לתרגם אתר WordPress שאתם מנהלים, ולא קוד שכתבתם? השתמשו ב־WPML.

מדריך זה מיועד למפתחים שכותבים את הקוד. אם כבר יש לכם קובץ POT או PO ואתם רק צריכים לתרגם אותו, עברו אל עמוד קובצי ה־PO לקבלת תהליך העבודה בן 3 השלבים.

בסוף מדריך זה, התבנית או התוסף שלכם יהיו:

מבוינאמים (Internationalized) כהלכה לפי תקני הקידוד של WordPress.
מוכנים לתרגום על ידי PTC ליותר מ־40 שפות.
מוכנים להפצה דרך חבילות השפה (Language Packs) של WordPress.org.
ניתנים לאימות בכל שחרור גרסה בעזרת סקירת התרגום החזותית של PTC.

מהו בינאום (internationalization) ב־WordPress?

בינאום (i18n) הוא תהליך ההכנה של הקוד שלכם כך שיוכל להיות מתורגם. לוקליזציה (l10n) היא השלב הבא. היא מפיקה את המחרוזות המתורגמות בפועל עבור שפות ספציפיות.

עבור תבניות ותוספים של WordPress, בינאום (i18n) אומר שלושה דברים:

לעטוף כל מחרוזת שמוצגת למשתמש בפונקציות gettext כדי ש־WordPress תוכל להחליף אותן בזמן ריצה.
להגדיר text domain שמקשר את התרגומים שלכם לפרויקט שלכם.
ליצור קובץ POT שמתרגמים (או PTC) יעבדו איתו.

לאחר שהעבודה הזו מסתיימת, יש לכם את כל מה שצריך כדי להפיק קובצי PO, MO, JSON ו־.l10n.php מתורגמים לכל שפה.

PTC מתרגמת קובצי POT ל־MO, JSON ו־.l10n.php עבור WordPress

חמש סיומות קבצים מופיעות בכל תהליך תרגום של WordPress. PTC מתרגמת מ־.pot (המקור שלכם) ל־.po, .mo, .json ו־.l10n.php עבור כל שפת יעד. לכל פורמט יש תפקיד ספציפי:

POT (Portable Object Template). קובץ המקור שנוצר מהקוד שלכם. הוא מפרט כל מחרוזת שניתנת לתרגום ללא תרגומים מצורפים. את הקובץ הזה אתם מעבירים ל־PTC.
PO (Portable Object). עותק של ה־POT עם תרגומים שנוספו עבור שפה ספציפית אחת. טקסט פשוט (Plain text), קריא לבני אדם. PTC מחזירה קובץ PO אחד לכל שפת יעד.
MO (Machine Object). הגרסה הבינארית המקומפלת של קובץ PO. WordPress קוראת קובצי MO בזמן ריצה מכיוון שהם נטענים מהר יותר מטקסט PO.
JSON. המקבילה של MO עבור JavaScript. WordPress אינה יכולה לקרוא קובצי MO מ־JavaScript, ולכן צינור ה־build מפיק קובצי JSON עבור מחרוזות בצד הדפדפן.
.l10n.php. חלופה חדשה יותר ל־MO, שהוצגה ב־WordPress 6.5. הקובץ נטען מהר יותר ומשתמש בפחות זיכרון. WordPress בוחרת בו אוטומטית כאשר הוא קיים לצד קובץ ה־MO.

הפעילו את .l10n.php עבור פרויקטים חדשים. קובץ זה עדיף באופן מובהק על MO בגרסאות הנתמכות של WordPress.

למה תרגומי קהילה אינם מספיקים

WordPress.org מציעה תרגומי קהילה דרך GlotPress. בפועל, זה מכסה רק חלק קטן ממה שרוב התוספים והתבניות צריכים. ניתוח של יותר מ־60,000 תוספים ותבניות של WordPress מצא שתרגומי קהילה מכסים פחות מ־5% מצרכי התרגום ב־40 שפות.

שתי בעיות מבניות מסבירות את הפער:

מתנדבים הם נדירים ברוב ה־locales. קומץ של תוספים עם בסיס משתמשים עצום מושכים מתרגמים. הרוב לא.
תרגומים עשויים לקחת חודשים או שנים עד שיופיעו, אם בכלל. אם אתם רוצים שמשתמשים יראו את התוסף או התבנית שלכם בשפה שלהם מהיום הראשון, אינכם יכולים להסתמך על הקהילה.

מדריך זה יוצא מנקודת הנחה שאתם מעוניינים בכיסוי תרגום מלא ועקבי, בלוח זמני שחרור גרסאות שאתם שולטים בו. זה בדיוק מה ש־PTC מספקת.

הכנת התבנית או התוסף שלכם ב־WordPress לתרגום

text domain שאינו תואם או מחרוזת שאינה עטופה משמעותם שהטקסט לעולם לא יופיע בפלט המתורגם שלכם. הפרטים הקטנים חשובים.

שלב 1: הגדירו את ה־text domain ואת ה־domain path שלכם

כל תבנית או תוסף צריכים text domain. ה־text domain הוא מזהה ייחודי שאומר ל־WordPress אילו קובצי תרגום שייכים לפרויקט שלכם. הוא חייב להיות זהה לחלוטין ל־slug של התוסף או התבנית שלכם.

הצהירו עליו בכותרת הקובץ הראשי של התוסף שלכם:

<?php
/**
 * Plugin Name: My Plugin
 * Description: An example plugin.
 * Version: 1.0.0
 * Text Domain: my-plugin
 * Domain Path: /languages
 */

או ב־style.css של התבנית שלכם:

/*
Theme Name: My Theme
Text Domain: my-theme
Domain Path: /languages
*/

ה־domain path אומר ל־WordPress היכן נמצאים קובצי התרגום שלכם ביחס לתיקיית השורש של התוסף או התבנית. /languages הוא התקן.

שלב 2: עטפו את מחרוזות ה־PHP שלכם בפונקציות gettext

כל מחרוזת שאתם רוצים שתהיה ניתנת לתרגום צריכה להיות עטופה באחת מפונקציות ה־gettext של WordPress. בזמן ריצה, הפונקציות הללו מחפשות את התרגום הנכון. אם לא נמצא תרגום, הן חוזרות לחלופה של המחרוזת המקורית.

מחרוזות בסיסיות. השתמשו ב־__() כאשר אתם צריכים להחזיר מחרוזת. עבור פלט HTML, השתמשו בגרסאות ה־escaped. תקני הקידוד של WordPress ממליצים על echo esc_html__() על פני _e(). הצורה ה־escaped הופכת את ה־output escaping למפורש ומונעת XSS בנקודת הפלט:

// Return a translated string
$label = __( 'Settings', 'my-plugin' );

// Echo a translated string, escaped for HTML
echo esc_html__( 'Settings saved.', 'my-plugin' );

מחרוזות עם משתנים. אל תשרשרו משתנים לתוך מחרוזות. המתרגמים רואים רק מקטעים ואינם יכולים לשנות את סדר המילים עבור שפות עם תחביר שונה. השתמשו ב־printf() או sprintf() עם מציין מיקום (placeholder). הוסיפו הערה למתרגם כדי שהמתרגמים ידעו מה %s מייצג:

printf(
    /* translators: %s: the user's display name */
    esc_html__( 'Welcome back, %s.', 'my-plugin' ),
    esc_html( $display_name )
);

צורות רבים. צורות רבים באנגלית הן פשוטות (תגובה אחת, שתי תגובות). בשפות אחרות זה לא כך. השתמשו ב־_n() כדי לתמוך בכל כלל של צורות רבים ש־WordPress מכירה:

printf(
    esc_html( _n( '%s comment', '%s comments', $count, 'my-plugin' ) ),
    number_format_i18n( $count )
);

מחרוזות שדורשות הקשר. למילים מסוימות יש משמעות שונה בהתאם למקום שבו הן מופיעות. השתמשו ב־_x() כדי לתת למתרגמים את ההקשר שהם צריכים:

// "Export" as a noun (the file) vs. a verb (the action)
echo esc_html_x( 'Export', 'button label', 'my-plugin' );

שלב 3: בינאום של מחרוזות ה־JavaScript שלכם

WordPress מספקת את החבילה wp-i18n כדי שתוכלו להשתמש באותן פונקציות gettext ב־JavaScript שבהן אתם משתמשים ב־PHP. בעת רישום הסקריפט שלכם, הצהירו על wp-i18n כתלות (dependency):

wp_register_script(
    'my-plugin-script',
    plugins_url( 'js/app.js', __FILE__ ),
    array( 'wp-i18n' ),
    '1.0.0',
    true
);

לאחר מכן, בקובץ ה־JavaScript שלכם:

const { __, _n, sprintf } = wp.i18n;

const message = __( 'Settings saved.', 'my-plugin' );

אם אתם משתמשים ב־bundler כמו Webpack, התקינו את @wordpress/babel-plugin-makepot. הוא מחלץ מחרוזות שניתנות לתרגום מה־bundle שלכם כחלק מתהליך ה־build שלכם.

שלב 4: צרו את קובץ ה־POT שלכם

לאחר שהמחרוזות שלכם עטופות, צרו קובץ POT. קובץ ה־POT הוא קובץ המקור שממנו PTC (או כל מתרגם) עובדת. הוא מכיל כל מחרוזת שניתנת לתרגום אך ללא תרגומים.

wp i18n make-pot . languages/my-plugin.pot

WP-CLI סורק את קובצי ה־PHP, ה־JavaScript ו־block.json שלכם לאיתור קריאות gettext. הוא מקמפל אותם לקובץ POT יחיד. אם הצוות שלכם משתמש ב־Composer, הוסיפו את הפקודה הזו כסקריפט של Composer. זה שומר על שימוש עקבי ב־WP-CLI ברחבי הצוות ללא צורך בהתקנה גלובלית.

חבילת הפקודות המלאה של wp i18n מכסה את שאר ה־pipeline:

פקודה	מה היא עושה
`wp i18n make-pot`	יצירת קובץ POT מהמקור.
`wp i18n update-po`	סנכרון קובצי PO קיימים כאשר ה־POT שלכם משתנה.
`wp i18n make-mo`	קימפול קובצי PO לקובצי MO בינאריים.
`wp i18n make-json`	חילוץ מחרוזות JS מ־PO לקובצי JSON.
`wp i18n make-php`	יצירת קובצי `.l10n.php` (WordPress 6.5 ומעלה).

אינכם צריכים את Poedit. כל דבר בתהליך העבודה הזה פועל דרך WP-CLI ו־PTC. WP-CLI מטפל ביצירת ה־POT ובקימפול של MO/JSON. PTC מטפלת בתרגום ומחזירה כל פורמט קובץ ש־WordPress צריכה. Poedit הוא עורך שולחני שימושי לתרגום ידני, אך הוא אינו חלק מתהליך העבודה הזה.

תרגום קובצי POT בעזרת PTC

PTC נבנתה מתוך מחשבה על מפתחי WordPress. התחילו עם קובץ POT וקבלו בחזרה קובצי תרגום מוכנים להפצה. תקופת ניסיון של 30 יום מכסה עד 20,000 מילים בשתי שפות.

הגדרת פרויקט התרגום הראשון שלכם

העלו את קובץ ה־POT שלכם. בחרו אילו פורמטים של פלט אתם צריכים. PTC מחזירה כל שילוב של:

קובצי .po עבור כל שפת יעד.
קובצי .mo, מקומפלים ומוכנים לשחרור.
קובצי .json עבור מחרוזות ה־JavaScript שלכם.
קובצי .l10n.php לטעינה מהירה יותר ב־WordPress 6.5 ומעלה.

אשף ההגדרה יבקש מכם לתאר את התבנית או התוסף שלכם. PTC משתמשת בתיאור כדי ליצור תרגומים עם הטון וההקשר הנכונים. הוסיפו מונחים ייחודיים למותג למילון המונחים בשלב זה. מילון המונחים שומר על עקביות של שמות, תוויות של פיצ'רים וכל טרמינולוגיה אחרת בכל השפות.

PTC מנתחת את מבנה ה־gettext בעת ההעלאה. היא מזהה מצייני מיקום (%s, %1$s, %d), צורות רבים (ערכים שחולצו על ידי _n() עם כותרת ה־Plural-Forms שלהם), והקשרים (ערכי _x() עם msgctxt). לאחר מכן היא יוצרת את קטגוריות הרבים הנכונות לכל שפה. פולנית מקבלת one / few / many / other. יפנית מקבלת רק other. ערבית מקבלת שש צורות.

מעבר ללוקליזציה מתמשכת

לאחר שהקבצים הראשונים שלכם תורגמו, שדרגו ל־Pay-As-You-Go. חברו את PTC למאגר ה־GitHub, ה־GitLab או ה־Bitbucket שלכם. מנקודה זו ואילך לא תעלו קבצים באופן ידני.

בצעו commit לקובץ .ptc-config.yml שמציין את קובץ המקור שלכם ולהיכן התרגומים שייכים:

# .ptc-config.yml
source_locale: en
files:
  - file: languages/my-plugin.pot
    output: languages/my-plugin-{{lang}}.po
    additional_translation_files:
      - type: mo
        path: languages/my-plugin-{{lang}}.mo

לאחר מכן הוסיפו את פעולת PTC Translate ל־workflow שלכם. היא נושאת בתוכה גרסת pinned של ה־PTC CLI, כך שה־build שלכם לא מוריד שום דבר בזמן ריצה:

# .github/workflows/translate.yml
name: Regenerate POT for PTC
on:
  push:
    branches: [main]
    paths:
      - 'languages/my-plugin.pot'
  workflow_dispatch: {}

jobs:
  translate:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - name: Generate POT
        run: |
          wp i18n make-pot . languages/my-plugin.pot --domain=my-plugin
      - uses: OnTheGoSystems/ptc-action@v1
        with:
          api-token: ${{ secrets.PTC_API_TOKEN }}
          create-pr: true

יש לכם שתי דרכים להפוך זאת לאוטומטי. בעזרת אינטגרציית Git, PTC עוקבת אחר המאגר שלכם ופותחת merge request עם תרגומים מעודכנים בכל פעם שקובץ המקור משתנה. כדי להריץ את התרגום בתוך משימת ה־CI שלכם במקום זאת, השתמשו ב־PTC CLI - הוא מעלה את הקובץ שהשתנה, ממתין לסיום התרגום, ומוריד את הקבצים המתורגמים. תבניות workflow מוכנות עבור GitHub Actions, GitLab CI ו־Bitbucket Pipelines נמצאות במדריך ההגדרה של צינור CI/CD.

כל אחד מהתהליכים מספק merge request או הורדה עם קובצי ה־.po, .mo, .json ו־.l10n.php המעודכנים. ראו את תיעוד ה־API של PTC עבור ה־webhook המלא ו־REST API.

ההחלטה אם לבצע commit לקובצי .mo למאגר שלכם תלויה במדיניות הצוות. תוספים רבים יוצרים אותם בזמן השחרור במקום זאת. אינטגרציית ה־CI של PTC מפיקה אותם בכל הרצת תרגום. בצעו להם check in רק אם אתם רוצים שקובצי תרגום יופיעו בהיסטוריית הגרסאות.

טעינת תרגומים ב־WordPress

כאשר הקבצים המתורגמים בידיכם, מקמו אותם נכון והגידו ל־WordPress היכן למצוא אותם. שם הקובץ בא קודם. WordPress מחפשת קובצי תרגום באמצעות תבנית מתן שמות ספציפית. שם קובץ שאינו תואם אומר שהקובץ לא ייטען.

הגדרת שמות הקבצים הנכונים

קודי locale עוקבים אחר הפורמט language_COUNTRY. de_DE הוא גרמנית (גרמניה). fr_FR הוא צרפתית (צרפת). pt_BR הוא פורטוגזית (ברזיל). zh_CN הוא סינית מפושטת. פורטל התרגומים של WordPress מפרט כל locale נתמך.

שם הקובץ הצפוי תלוי במיקום שבו תשימו את הקובץ:

מיקום	תבנית	דוגמה
תיקיית `/languages/` של התוסף	`{text-domain}-{locale}.mo`	`my-plugin-de_DE.mo`
תיקיית `/languages/` של התבנית	`{locale}.mo`	`de_DE.mo`
תיקיית השפות הגלובלית של WordPress (`/wp-content/languages/`)	`{text-domain}-{locale}.mo`	`my-plugin-de_DE.mo`

תבניות משתמשות במוסכמת שמות קצרה יותר כאשר הקבצים כלולים בתוך התבנית. בתיקיית השפות הגלובלית, גם תוספים וגם תבניות משתמשים בתבנית {text-domain}-{locale}.

טעינת תרגומים לתוספים (PHP)

רשמו את התרגומים ב־WordPress על ה־hook של init. אל תשתמשו ב־plugins_loaded. הוא מפעיל אזהרת deprecation בגרסאות הנוכחיות של WordPress:

add_action( 'init', function () {
    load_plugin_textdomain(
        'my-plugin',
        false,
        dirname( plugin_basename( __FILE__ ) ) . '/languages/'
    );
} );

טעינת תרגומים לתבניות (PHP)

השתמשו ב־load_theme_textdomain() המחובר ל־hook של after_setup_theme:

add_action( 'after_setup_theme', function () {
    load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );
} );

טעינת תרגומי JavaScript

לאחר רישום הסקריפט שלכם (שלב 3 למעלה), קראו ל־wp_set_script_translations(). לאחר מכן WordPress טוענת את תרגומי ה־JSON עבור ה־handle של הסקריפט הזה:

add_action( 'init', function () {
    wp_set_script_translations(
        'my-plugin-script',
        'my-plugin',
        plugin_dir_path( __FILE__ ) . 'languages'
    );
} );

אימות הטעינה

הגדירו את שפת אתר ה־WordPress שלכם ל־locale יעד. ההגדרה נמצאת תחת הגדרות > כללי > שפת האתר.
רעננו את ה־front end ואת עמודי הניהול שהתוסף או התבנית שלכם מרנדרים.
מחרוזות שעטופות ב־__() או esc_html__() אמורות להופיע בשפה החדשה.

אם משהו חסר, ראו תרגומי תוסף WordPress לא מופיעים? תיקון תרגומים חסרים לקבלת הגורמים הנפוצים ביותר.

העברת התרגומים שלכם למשתמשים: שני נתיבים

לאחר ש־PTC תרגמה את הקבצים שלכם, אתם משחררים אותם באחת משתי דרכים.

נתיב 1: פרסום תרגומים דרך חבילות השפה של WordPress.org (CLPTE)

זמן כולל: 4-6 ימים.

שלב 1: יצירת חשבון CLPTE

תפקיד ה־CLPTE (עורך תרגום פרויקט חוצה-שפות) מאפשר לכם להגיש תרגומים בשם התבנית או התוסף שלכם בכל שפות היעד מחשבון אחד. חשבון עורך תרגום (Translation Editor) רגיל הוא פר-שפה; CLPTE אינו כזה.

אם כבר יש לכם חשבון ב־WordPress.org, ייתכן שתיתקלו בבעיה שבה חשבון ה־CLPTE החדש שלכם מושבת. WordPress אינה מאפשרת ריבוי חשבונות. כדי לפתור זאת, שלחו דוא"ל אל forum-password-resets@wordpress.org והסבירו שאתם מנסים ליצור חשבון CLPTE. שיתוף התיעוד הרלוונטי של Polyglots עם המנהל (moderator) ותיוג של צוות Polyglots ב־Slack יכולים לעזור.

זמן משוער: כ־3-5 ימים (כולל זמן המתנה אם החשבון החדש שלכם מושבת).

שלב 2: בקשת גישת CLPTE בבלוג של Polyglots

כאשר החשבון שלכם מופעל, פרסמו בקשה בבלוג Polyglots של WordPress.org. עקבו אחר התבנית שלהם:

PTE/CLPTE Request

Plugin URL: https://wordpress.org/plugins/my-plugin/
Authors / Editors: @your-wp-username
Type of request: CLPTE

תקבלו התראה כאשר הבקשה שלכם תאושר.

זמן משוער: יום אחד (הצוות הגלובלי של Polyglots סוקר בקשות באצוות).

שלב 3: ייבוא קובצי ה־.po המתורגמים

התחברו אל https://translate.wordpress.org/ באמצעות חשבון ה־CLPTE שלכם.
עברו לעמוד פרויקט התרגום של התוסף או התבנית שלכם (לדוגמה, translate.wordpress.org/projects/wp-plugins/{your-plugin-slug}/).
פתחו את ה־local project עבור כל שפה שתרגמתם.
גללו למטה ולחצו על ייבוא תרגומים.
העלו את קובץ ה־.po (או .mo) שלכם.
סמנו את המחרוזות המיובאות כ־”current“ בעורך התרגום. מחרוזות מאושרות מצטרפות ליצירת חבילת השפה הבאה (בדרך כלל על בסיס יומי).
חזרו על הפעולה עבור כל שפת יעד. לכל locale יש עמוד תרגום משלו.

זמן משוער: כ־10-30 דקות לכל שפה.

לאחר חלון זמן של 24-48 שעות עבור חבילת השפה, אתרים שמריצים את התוסף שלכם מתחילים לקבל את התרגומים החדשים דרך עדכוני חבילות השפה האוטומטיים של WordPress. משתמשים אינם רואים שום בקשת שדרוג (upgrade prompt). התרגומים פשוט מופיעים.

מה CLPTE יעשה ולא יעשה עבורכם

אינכם יכולים להחליף תרגומי קהילה קיימים. רק מחרוזות שאינן מתורגמות מיובאות. עדכון תרגום קהילה קיים דורש את התהליך הסטנדרטי והמתנה לסקירה של צוות ה־locale.
עדכונים דורשים העלאות ידניות לכל שחרור גרסה. כל שחרור גרסה חדש אומר סבב חדש של העלאות.
יצירת החשבון ואישורו אורכים בדרך כלל 4-6 ימים בסך הכל.

נתיב 2: לכלול את קובצי ה־.mo בחבילה בתוך התוסף או התבנית שלכם

אם אתם צריכים שהתרגומים יעלו לאוויר מהר יותר ממה ש־CLPTE מאפשר, או אם אתם מעדיפים שלא להיות תלויים בצינור ההפצה של WordPress.org, כללו את קובצי ה־.mo ישירות בשחרור התוסף או התבנית שלכם. זמן כולל: 15-30 דקות.

שלב 1: הוספת קובצי ה־.mo לתיקיית ה־/languages/

מקמו את קובצי ה־.mo המקומפלים שלכם בתוך תיקיית ה־/languages/ של התוסף או התבנית שלכם כדי ש־WordPress תמצא אותם בעת טעינת ה־text domain שלכם:

my-plugin/
├─ my-plugin.php
├─ readme.txt
├─ languages/
│  ├─ my-plugin-es_ES.mo
│  ├─ my-plugin-es_ES.po
│  ├─ my-plugin-fr_FR.mo
│  ├─ my-plugin-fr_FR.po
│  ├─ my-plugin-de_DE.mo
│  └─ my-plugin-de_DE.po

השתמשו באותו text domain בשמות קובצי התרגום שלכם ובקריאות load_plugin_textdomain() או load_theme_textdomain() שלכם.

שלב 2: העדפת הקבצים הכלולים בחבילה שלכם על פני תרגומי קהילה

כברירת מחדל, WordPress נותנת עדיפות לתרגומי קהילה מ־WordPress.org על פני קבצים הכלולים בחבילה. כדי לוודא שהתוסף או התבנית שלכם משתמשים בקובצי ה־.mo הכלולים בחבילה במקום זאת, הוסיפו את ה־filter של load_textdomain_mofile.

עבור תוספים, הוסיפו לקובץ התוסף הראשי שלכם (לדוגמה, my-plugin.php):

function my_plugin_load_embedded_translation_file( $mofile, $domain ) {
    if ( 'my-domain' === $domain && false !== strpos( $mofile, WP_LANG_DIR . '/plugins/' ) ) {
        $locale = apply_filters( 'plugin_locale', determine_locale(), $domain );
        $local_mofile = WP_PLUGIN_DIR . '/' . dirname( plugin_basename( __FILE__ ) ) .
                        '/languages/' . $domain . '-' . $locale . '.mo';

        if ( file_exists( $local_mofile ) ) {
            return $local_mofile;
        }
    }
    return $mofile;
}
add_filter( 'load_textdomain_mofile', 'my_plugin_load_embedded_translation_file', 10, 2 );

עבור תבניות, הוסיפו ל־functions.php של התבנית שלכם:

function my_theme_load_embedded_translation_file( $mofile, $domain ) {
    if ( 'my-domain' === $domain && false !== strpos( $mofile, WP_LANG_DIR . '/themes/' ) ) {
        $locale = apply_filters( 'theme_locale', determine_locale(), $domain );
        $local_mofile = get_template_directory() . '/languages/' . $locale . '.mo';

        if ( file_exists( $local_mofile ) ) {
            return $local_mofile;
        }
    }
    return $mofile;
}
add_filter( 'load_textdomain_mofile', 'my_theme_load_embedded_translation_file', 10, 2 );

כמו כן, ודאו שהתוסף או התבנית שלכם טוענים את ה־text domain ב־hook הנכון:

add_action( 'init', function() {
    load_plugin_textdomain(
        'my-plugin',
        false,
        dirname( plugin_basename( __FILE__ ) ) . '/languages'
    );
} );

שלב 3: אימות טעינת התרגומים הכלולים בחבילה באתר בדיקות

התקינו את התוסף או התבנית שלכם באתר בדיקות והעבירו את WordPress לאחת מהשפות שסיפקתם:

עברו אל הגדרות > כללי > שפת האתר ובחרו שפה שקובץ ה־.mo שלה נמצא בתיקיית ה־/languages/ שלכם.
טענו עמוד או מסך שמכיל מחרוזות שאתם יודעים שהן מתורגמות.
ודאו שהמחרוזות מופיעות בשפה הנכונה ותואמות לתרגומים שהוספתם.

אם אתם עדיין רואים תרגומי קהילה ישנים, סקרו את קטע הקוד בשלב 2. הוא צריך להפנות את WordPress נכון אל קובצי ה־.mo הכלולים בחבילה שלכם.

בצעו commit לקובצי ה־.mo, תייגו שחרור גרסה (tag a release), ובצעו push ל־wordpress.org דרך SVN כפי שאתם עושים בדרך כלל.

הפשרה בין מהירות להפצה קנונית

יתרון: מיידי. תרגומים חדשים עולים לאוויר ברגע שמשתמשים מעדכנים את התוסף שלכם (או מתקינים אותו בפעם הראשונה). אין המתנה של מספר ימים ל־CLPTE. אין מחזור אישורים של צוות Polyglots.
יתרון: אתם שולטים בתהליך העבודה. קצב התרגום תואם בדיוק לתדירות שחרור הגרסאות שלכם.
יתרון: אין תלות בתג של התוסף. התרגומים עובדים בין אם לתוסף שלכם יש הרשאות CLPTE ובין אם לא.
חיסרון: גודל קובץ התוסף גדל. כל .mo הוא קטן (בדרך כלל 5-50KB), אך 20 שפות מוסיפות כ־500KB להורדה.
חיסרון: אין עדכון אוטומטי של תרגומים בין שחרורי גרסאות של התוסף. עם CLPTE, תרגומים שעודכנו ב־wordpress.org מופצים למשתמשים תוך 48 שעות, גם אם אינכם משחררים גרסה חדשה. עם הכללה בחבילה, התרגומים מתעדכנים רק כאשר אתם משחררים גרסה חדשה.
חיסרון: אין תג "מתורגם". WordPress.org מציגה תג של השלמת תרגום בדפי המוצר של תוספים על סמך כיסוי חבילות השפה, ולא על סמך קובצי .mo הכלולים בחבילה. הכללה בחבילה לבדה אינה מזכה בתג.

איזה נתיב תואם לתדירות שחרור הגרסאות שלכם?

מצב	המלצה
הפצה קנונית לטווח ארוך; אתם רוצים את תג התרגום	CLPTE - עברו דרך תהליך הבקשה של Polyglots
אתם משחררים עדכוני תוסף מדי חודש או לעיתים קרובות יותר, וקצב התרגום יכול להתאים	כללו קובצי MO בחבילה
אתם צריכים שהתרגומים יעלו לאוויר השבוע ואינכם יכולים לחכות ל־CLPTE	כללו קובצי MO בחבילה עכשיו, הגישו בקשה ל־CLPTE במקביל
אתם רוצים את שניהם	השתמשו בשניהם - הם אינם סותרים זה את זה

הגישה הכפולה היא נפוצה: לכלול קובצי MO בחבילה לזמינות מיידית, ולהגיש ל־CLPTE עבור הפצה קנונית. המשתמשים מקבלים את התרגומים הכלולים בחבילה בעת העדכון; שכבת ה־Language Pack מרעננת אותם בין שחרורי גרסאות.

שפות מימין לשמאל ופריסות דו-כיווניות

תהליך התרגום זהה עבור שפות מימין לשמאל (RTL). ערבית, עברית, פרסית ואורדו משתמשות באותו צינור POT/PO/MO.

השלב הנוסף הוא לוודא שהתבנית שלכם תומכת בסגנונות RTL. WordPress טוענת אוטומטית קובץ rtl.css אם קיים אחד בתיקיית התבנית שלכם. השתמשו בפונקציה is_rtl() כדי להחיל סגנונות או סקריפטים ייעודיים ל־RTL באופן מותנה.

לוקליזציה של תאריכים, מספרים ומטבעות

מחרוזת מתורגמת היא לא כל הסיפור. תאריכים, מספרים ומטבעות חייבים גם הם לעקוב אחר ה־locale של המשתמש. השתמשו בפונקציות העיצוב המובנות של WordPress במקום באלו המובנות ב־PHP:

date_i18n() מעצבת תאריכים בהתאם ל־locale הפעיל.
number_format_i18n() מעצבת מספרים עם מפרידי אלפים ועשרוניים מותאמי locale.

הפונקציות הללו אינן חלק מתהליך העבודה של קובצי התרגום. הן חשובות לחוויה שעברה לוקליזציה מלאה.

בינאום של בלוקים בעורך הבלוקים (Gutenberg)

בלוקים מוסיפים שני שלבים נוספים לצינור הסטנדרטי:

תרגומי JavaScript דורשים קובץ .json לכל locale. צרו אותו מתוך ה־.po בעזרת wp i18n make-json.
סקריפט העורך של הבלוק דורש wp_set_script_translations() ב־PHP. זה אומר ל־WordPress להגיש את ה־JSON לבלוק.

הפלט המרונדר של הבלוק ב־front end משתמש באותן קריאות __() כמו שאר ה־PHP שלכם. אין שם עבודה נוספת.

תרגום ה־README ועמוד התוסף ב־WordPress.org שלכם

קובץ ה־readme.txt שלכם אינו קובץ משאבים. WP-CLI לא יאסוף אותו בעת יצירת POT. כדי לתרגם אותו, השתמשו בפיצ'ר Paste to Translate של PTC. הדביקו את התוכן, בחרו את שפות היעד שלכם, והורידו את התוצאה. הודעות דוא"ל ללקוחות שנשלחות מהתוסף ותיאור עמוד התוסף ב־WordPress.org מתורגמים באותה דרך, כולם באותו פרויקט כדי שהטרמינולוגיה תישאר עקבית.

אם התוסף או התבנית שלכם מופיעים ב־WordPress.org, התיאור המתורגם מופיע בלשונית הפרטים (Details) של התוסף בשפת המשתמש. כדי שהתרגומים יעלו לאוויר שם, עקבו אחר תהליך הייבוא של WordPress.org.

תרגום תוכן משתמשים של התוסף בעזרת ה־API של PTC

תוספים ששומרים נתונים שנוצרו על ידי משתמשים (תוספי פורומים, תוספי ביקורות, תוספי תגובות) יכולים לתרגם את התוכן הזה עם הגעתו. ה־REST API של PTC מתרגם פוסטים, תגובות וביקורות של משתמשים לפי דרישה עם אימות טוקן Bearer, תוך שימוש באותו מילון מונחים וטון המותג כמו קובצי ה־.po שלכם.

סקירה חזותית של התרגום של התבנית או התוסף המרונדרים שלכם - לשחרר ללא QA ידני לכל שפה

קובץ .po מתורגם הוא הכרחי, אבל הוא אינו מספיק. התבנית או התוסף המתורגמים עדיין דורשים אימות:

תווית מתורגמת עלולה לגרום לגלישה (overflow) של כפתור בעמוד ההגדרות בגרמנית.
המילה “Submit” עשויה להיות מתורגמת כשם עצם בצרפתית כאשר פעולת מנהל המערכת דרשה פועל.
מחרוזת מוטמעת בקוד (hardcoded string) באנגלית מחוץ ל־__() תרונדר ללא תרגום ללא קשר למספר השפות שאתם משחררים.

סקירת התרגום החזותית של PTC מחליפה את סבב ה־QA הידני. תבניות ותוספים של WordPress מרונדרים בדפדפן (גם wp-admin וגם ה־front end). הווריאציה (flavor) הנכונה היא תוסף הדפדפן.

התקינו אותו פעם אחת. הקליטו מעבר (walkthrough) של התבנית או התוסף שלכם באתר בדיקות. כסו את עמודי ההגדרות, פעולות מנהל המערכת והפלט ב־front end. PTC מריצה מחדש את ההקלטה בכל שפת יעד לאחר כל עדכון תרגום. היא מצלמת כל מסך ומדווחת בחזרה על שני סוגים של תיקונים:

תיקונים בקובצי ה־.po כאשר PTC שולטת בהם. PTC מתרגמת מחדש משמעות שגויה, בוחרת מילה נרדפת קצרה יותר שנכנסת לכפתור, או יוצרת מחדש צורת רבים.
פרומפטים ל־Cursor או ל־Claude Code כאשר הבעיה נמצאת בקוד ה־PHP או ה־JavaScript שלכם. דוגמאות כוללות עטיפת __() חסרה, מחרוזת מוטמעת בקוד (hardcoded string) באנגלית, או משפט שנבנה על ידי שרשור שצריך להשתמש ב־sprintf( __( ... ) ).

אתם משחררים תוסף מאומת ורב־לשוני בכל שחרור גרסה. שאריות ה־QA הידני נעלמות.

תמחור: תקופת ניסיון של 30 יום, ואז Pay-As-You-Go

תקופת הניסיון מכסה 20,000 מילים ל־2 שפות ללא כרטיס אשראי. כאשר תקופת הניסיון מסתיימת, PTC מציעה Pay-As-You-Go. ללא מנוי. ללא התחייבות למינימום. 500 המילים הראשונות בכל חודש הן בחינם. אתם משלמים רק על השאר. בעמוד התמחור יש מחשבון עלויות. הירשמו עם דוא"ל חברה לקבלת תקופת ניסיון עסקית מורחבת.

מוכנים לשחרר תוסף או תבנית מאומתים?

PTC יוצרת את התרגומים וסוקרת את התוסף המרונדר. אתם מאשרים את התוצאה ומשחררים. הלולאה המלאה רצה ללא QA ידני:

צרו את קובץ ה־.pot שלכם בעזרת wp i18n make-pot.
העלו אותו ל־PTC וקבלו בחזרה קובצי .po, .mo, .l10n.php ו־.json תוך דקות.
התקינו את תוסף הדפדפן כדי לאמת את התוסף הפועל בכל שפת יעד.

התחילו תקופת ניסיון של 30 יום - 20,000 מילים על חשבוננו, ללא צורך בכרטיס אשראי.

קשורים:

תרגום קובצי PO אונליין עם בינה מלאכותית - העמוד הקנוני לתרגום PO/POT.
GlotPress מול PTC לתרגום תוספים/תבניות של WordPress - מתי לבחור בתרגומי קהילה לעומת PTC.
תרגומי תוסף WordPress לא מופיעים? תיקון תרגומים חסרים - מדריך לפתרון תקלות.
איך לייבא תרגומי תבניות ותוספים ל־WordPress.org - תהליך ה־CLPTE וחלופה מהירה יותר.
תיעוד ה־API של PTC - נקודות קצה (endpoints) של REST לאינטגרציית CI.

עודכן לאחרונה: 11 בנובמבר 2026