בינאום ב־WordPress: איך לתרגם ערכות נושא ותוספים

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

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

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

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

מהו בינאום ב־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 עם תרגומים שנוספו עבור שפה ספציפית אחת. טקסט פשוט, קריא לבני אדם. PTC מחזירה קובץ PO אחד לכל שפת יעד.
MO (Machine Object). הגרסה הבינארית המקומפלת של קובץ PO. WordPress קוראת קובצי MO בזמן ריצה מכיוון שהם נטענים מהר יותר מאשר טקסט של PO.
JSON. המקבילה ב־JavaScript ל־MO. 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, השתמשו בגרסאות שעברו escape. תקני הקידוד של WordPress ממליצים על echo esc_html__() על פני _e(). הצורה שעברה escape הופכת את ה־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 שלכם. מנקודה זו ואילך אינכם מעלים קבצים באופן ידני.

בצעו 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

לאחר מכן, הוסיפו את ה־action של PTC Translate ל־workflow שלכם. הוא מכיל בתוכו גרסה מקובעת של ה־CLI של PTC, כך שה־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 שלכם במקום זאת, השתמשו ב־CLI של PTC - הוא מעלה את הקובץ שהשתנה, ממתין לסיום התרגום ומוריד את הקבצים המתורגמים. תבניות 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 מפיקה אותם בכל הרצת תרגום. הוסיפו אותם למעקב גרסאות רק אם אתם רוצים שקבצים מתורגמים יופיעו בהיסטוריית הגרסאות.

טעינת תרגומים ב־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. הוא גורם לאזהרת הוצאה משימוש בגרסאות הנוכחיות של 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 יעד. ההגדרה נמצאת תחת הגדרות > כללי > שפת האתר.
רעננו את צד המשתמש ואת עמודי הניהול שהתוסף או התבנית שלכם מרנדרים.
מחרוזות העטופות ב־__() או ב־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 לבלוק.

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

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

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

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

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