בינאום WordPress: איך לתרגם תבניות ותוספים

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

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

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

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

מהו בינאום ב־WordPress?

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

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

עטפו כל מחרוזת שמוצגת למשתמש בפונקציות 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 עם תרגומים שנוספו עבור שפה ספציפית אחת. טקסט פשוט, קריא לבני אדם. 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, השתמשו בווריאציות שעברו escaping. תקני הקידוד של WordPress ממליצים על echo esc_html__() על פני _e(). הצורה שעברה escaping הופכת את ה־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() עם מציין מיקום. הוסיפו הערה למתרגם כדי שמתרגמים ידעו מה %s מייצג:

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

צורות רבים. צורות רבים באנגלית הן פשוטות (one comment, two comments). שפות אחרות אינן כאלה. השתמשו ב־_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 כתלות:

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 שלכם. מנקודה זו ואילך אינכם מעלים קבצים באופן ידני:

# .github/workflows/translate.yml
name: Regenerate POT for PTC
on:
  push:
    branches: [main]
    paths:
      - 'languages/my-plugin.pot'
jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Generate POT
        run: |
          wp i18n make-pot . languages/my-plugin.pot --domain=my-plugin
      - name: Translate with PTC
        run: |
          cat > .ptc-config.yml <<'EOF'
          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
          EOF
          curl -fsSL https://raw.githubusercontent.com/OnTheGoSystems/ptc-cli/main/ptc-cli.sh -o ptc-cli.sh
          chmod +x ptc-cli.sh
          ./ptc-cli.sh --config-file .ptc-config.yml --api-token="${{ secrets.PTC_API_TOKEN }}"

יש לכם שתי דרכים להפוך זאת לאוטומטי. בעזרת אינטגרציית 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`

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

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

רשמו את התרגומים ב־WordPress על ה־hook של init. אל תשתמשו ב־plugins_loaded. הוא מפעיל אזהרת הוצאה משימוש (deprecation warning) בגרסאות 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 עבור אותו script 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 לא מופיעים? תיקון תרגומים חסרים עבור הגורמים הנפוצים ביותר.

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

תהליך העבודה של התרגום זהה עבור שפות מימין לשמאל (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 מתרגם פוסטים של משתמשים, תגובות וביקורות לפי דרישה (on demand) עם אימות טוקן Bearer, תוך שימוש באותו מילון מונחים וטון המותג כמו בקובצי ה־.po שלכם.

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

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

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

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

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

תיקונים בקובצי ה־.po כאשר PTC שולטת בהם. PTC מתרגמת מחדש משמעות שגויה, בוחרת מילה נרדפת קצרה יותר שמתאימה לכפתור, או יוצרת מחדש צורת רבים.
פרומפטים עבור Cursor או Claude Code כאשר הבעיה נמצאת בקוד ה־PHP או ה־JavaScript שלכם. דוגמאות כוללות עטיפת __() חסרה, מחרוזת hardcoded באנגלית, או משפט שנבנה על ידי שרשור שאמור להשתמש ב־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.