מחקר תהליך תרגום מוצרי Shopify בעזרת AI

Updated 2026-09-05

השתמשו ב-Translate & Adapt לעריכה שמנוהלת בידי סוחר, או בנו צינור תרגום שנבדק סביב מזהי משאבים ו-digests של מקור ב-Shopify. המדריך ממפה את שני המסלולים.

בחרו את נתיב התרגום שאתם צריכים

השתמשו בכלי הסוחר של Shopify כאשר עורך יכול לנהל תרגומים ישירות. השתמשו ב-GraphQL Admin API כאשר אתם זקוקים לתור בדיקה חיצוני חוזר ומפתח יכול לתחזק את היישום. בנתיב ה-API לקוח מודל נפרד מנסח טקסט בעוד Shopify מטפל בתרגומים שנשמרים.

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

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

בחרו תהליך סוחר או יישום

התיעוד של Translate & Adapt ב-Shopify מתאר עריכה ידנית ותרגום אוטומטי, עם בדיקה לפני פרסום. זה עשוי להספיק כאשר הסוחר רוצה שליטה עריכתית ישירה בלי לבנות יישום. אינטגרציה מותאמת הגיונית רק כאשר דרישה מסוימת, כגון תור בדיקה חיצוני, מצדיקה בעלות על המחבר.

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

נתיבמי הבעלים של התהליך?ההתאמה הטובה ביותר
Translate & Adaptכלי הסוחר ו-Shopifyניהול עריכתי ישיר
טיוטה חיצונית שנבדקה לצד עורךהסוחר מעתיק שדות מאושריםאצוות קטנות שנבדקות מבחוץ
יישום תרגום מותאםמפתח אחראי לאימות, מיפוי ובדיקהמסירה חוזרת שמודעת ל-revision

תכננו גבולות אימות וגרסה

ההפניה translatableResource דורשת read_translations; המוטציה translationsRegister דורשת write_translations. השתמשו בחנות פיתוח ותעדו התקנת יישום, גרסת API ו-scopes שהוענקו בזמן בדיקה. פרטי גישה ל-LLM gateway אינם מאמתים בקשת Shopify Admin API, ואסור לשלוח token של Shopify ל-endpoint של המודל.

התחילו בגישת קריאה לגילוי כאשר תכנון היישום מאפשר זאת. הוסיפו רק הרשאות הדרושות לתהליך המורשה המאוחר. קבעו גרסת API נתמכת לאחר בדיקת ההפניה שלה, במקום לפרוס מול alias latest שלא תועד. שמרו tokens בצד השרת והחריגו אותם מייצואי בדיקה ומיומני בקשות.

קראו שדות ניתנים לתרגום עם ה-digests שלהם

השאילתה המתועדת מחזירה מזהה משאב ורשומות ניתנות לתרגום עם key, value, digest ו-locale. שמרו את ה-digests הספציפיים לשדה עם snapshot המקור. הם מחברים תרגום מוצע לתוכן שנקרא בפועל, ולא לכותרת מוצר שהועתקה מגיליון.

השאילתה שלהלן מותאמת מהסכמה הרשמית כדוגמת read-only. ספקו GID מורשה של מוצר בסביבת פיתוח. בדקו מפתחות שהוחזרו והשתמשו ב-allowlist שדות מפורש; השתמשו ב-locale המקור שהוחזר במקום להסיק אותו משפת הדפדפן.

query TranslationSource($resourceId: ID!) {
  translatableResource(resourceId: $resourceId) {
    resourceId
    translatableContent {
      key
      value
      digest
      locale
    }
  }
}

צרו מועמד תרגום מחוץ ל-Shopify

בנו רשומת מועמד פנימית שמכילה resource ID, field key, source digest, locale יעד, revision מילון וערך טיוטה. שלחו למודל רק את הטקסט והקשר המוצר הנחוץ. השאירו SKU, מחיר, מטבע, מלאי וזהות וריאנט מחוץ לתיקון שנוצר.

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

רשמו רק תרגומים מאושרים ועדכניים

המוטציה translationsRegister מקבלת שדות מתורגמים עם translatableContentDigest. התוצאה המתועדת שלה כוללת userErrors. מתאם חייב לבדוק את התוצאה הזו במקום להתייחס לתגובת HTTP לבדה כהוכחה לרישום מוצלח.

לפני כתיבה מורשית השוו את המקור הנוכחי ל-snapshot שנבדק. אם הוא השתנה, החזיקו את המועמד וקבלו בדיקה חדשה. שמרו רשימה מפורשת של שינויי שדה מיועדים ותרגומים קודמים להתאוששות. התחילו בשדה אחד בחנות הפיתוח וקראו אותו בחזרה לפני הרחבת התיקון.

אמתו את החנות בנפרד

תרגום שנשמר וזמינותו בחנות הם נקודות בדיקה נפרדות בתהליך המתועד של Shopify. תכננו את הגדרת ה-locale ובדיקות ה-theme עם הסוחר. שמירת ערך מתורגם אינה צריכה לאשר אוטומטית פרסום שפה או שינוי הגדרות שוק.

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

ראיות ומגבלות המחבר

ההפניות הרשמיות מבססות את ממשקי התרגום של Shopify. יישום שמחובר ל-APIsRouter לא נבדק כאן, והמקורות שנבדקו אינם מבססים הגדרת baseURL שרירותית של gateway ב-Shopify או ב-Translate & Adapt. התייחסו לנתיב היישום המותאם כמחקר מחבר עד שתהיה לו תוצאה בחנות פיתוח.

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

שאלות נפוצות

האם אפשר להדביק base URL של APIsRouter ב-Shopify?

המקורות הרשמיים שנבדקו כאן לא ביססו הגדרה כללית כזו ב-Shopify. תהליך שמבוסס gateway דורש לקוח מודל נפרד ואינטגרציית חנות מאומתת.

אילו scopes של Shopify רלוונטיים?

שאילתת הקריאה המוזכרת דורשת read_translations והמוטציה לרישום דורשת write_translations. בדקו את גרסת ה-API שקיבעתם ואת דרישות היישום המלאות לפני התקנה.

מדוע לשמור את source digest?

Shopify כוללת digest לכל שדה מקור שניתן לתרגום ודורשת אותו בקלט התרגום. שמרו אותו עם המקור שנבדק כדי שהמתאם לא ישלח מועמד בלי הקשר המקור שלו.

האם API התרגום יעדכן מחירי מוצר?

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

מה לעשות כשהמוצר במקור משתנה?

אחזרו את השדות הנוכחיים שניתנים לתרגום והשוו אותם ל-snapshot שנבדק. החזיקו מועמדים מושפעים וחדשו אישור לפני רישום.

האם דף מתורגם בדפדפן מוכיח ייבוא?

לא. בדקו את התרגום שנשמר ואת ה-locale המיועד בחנות. תרגום שמרונדר בדפדפן יכול לשנות את מה שעורך רואה בלי לשמור תוכן סוחר.