Skip to main content

โลคัลไลเซชันต่อเนื่องโดยไม่ใช้ TMS

โค้ดของคุณดีพลอยอย่างต่อเนื่อง คำแปลก็ควรเช่นกัน ต่อไปนี้คือวิธีทำให้โลคัลไลเซชันในเวิร์กโฟลว์พัฒนาเป็นอัตโนมัติ

โลคัลไลเซชันต่อเนื่องคืออะไร?

โลคัลไลเซชันต่อเนื่องคือแนวทางแปลข้อความใหม่โดยอัตโนมัติเป็นส่วนหนึ่งของเวิร์กโฟลว์พัฒนา แทนการรวมงานแปลเป็นชุดสำหรับเผยแพร่ตามรอบ เมื่อนักพัฒนาเพิ่มฟีเจอร์ใหม่พร้อมข้อความ UI ข้อความเหล่านั้นจะได้รับการแปลก่อนส่งฟีเจอร์ขึ้นใช้งาน

แนวทางแบบเดิม

ทีมส่วนใหญ่รวมงานแปลเป็นชุด โดยรวบรวมข้อความใหม่ ส่งออกไปยัง TMS รอนักแปล นำผลลัพธ์เข้า แล้วจึงส่งขึ้นใช้งาน วิธีนี้สร้างคอขวดด้านโลคัลไลเซชันที่ทำให้การเผยแพร่ระหว่างประเทศล่าช้าหลายวันหรือหลายสัปดาห์

1

นักพัฒนาเพิ่มข้อความใหม่ลงในไฟล์ภาษาต้นฉบับ

2

ส่งออกข้อความแล้วอัปโหลดไปยังแพลตฟอร์ม TMS

3

ระบบแจ้งนักแปลและนักแปลเริ่มทำงาน

4

ตรวจทานและอนุมัติคำแปล

5

ดาวน์โหลดไฟล์ที่แปลแล้วและผสานกลับ

6

ฟีเจอร์ส่งขึ้นใช้งานพร้อมคำแปลในอีกหลายวันหรือหลายสัปดาห์

Days to weeks

แนวทางที่ทำงานใน IDE

เมื่อใช้การแปลใน IDE นักพัฒนาจะแปลข้อความเป็นส่วนหนึ่งของเวิร์กโฟลว์เขียนโค้ดตามปกติ ไม่ต้องส่งออก อัปโหลด หรือรอ การแปลเกิดขึ้นในเซสชันเดียวกับการพัฒนา

1

นักพัฒนาเพิ่มข้อความใหม่ลงในไฟล์ภาษาต้นฉบับ

2

นักพัฒนาบอกให้ผู้ช่วย AI แปลไฟล์

3

ระบบเขียนไฟล์ที่แปลแล้วลงในโปรเจกต์โดยตรง

4

ฟีเจอร์ส่งขึ้นใช้งานพร้อมคำแปลในคอมมิตเดียวกัน

Same commit

แนวทางแบบเดิม

6 steps

Multiple tools and platforms

Days to weeks per cycle

แนวทางที่ทำงานใน IDE

4 steps

Inside your editor

Same commit

3

ตั้งค่าไปป์ไลน์การแปล

สำหรับทีมที่ต้องการการแปลอัตโนมัตินอกเหนือจาก IDE ให้เพิ่มขั้นตอน CI/CD ซึ่งแปลข้อความใหม่หรือข้อความที่เปลี่ยนแปลงทุกครั้งที่พุชไปยัง main วิธีนี้ใช้ได้กับ GitHub Actions, GitLab CI หรือระบบ CI/CD ใดก็ได้

ทีมขนาดเล็กควรเริ่มด้วยการแปลใน IDE เพิ่มระบบ CI/CD อัตโนมัติเมื่อทีมมีนักพัฒนามากกว่า 3-4 คน หรือเมื่อต้องรับประกันว่าทุกการผสานเข้า main มีคำแปล

เพิ่มการแปลเป็นขั้นตอนหนึ่งในไปป์ไลน์ CI/CD เดิม การแปลจะทำงานหลังบิลด์สำเร็จและก่อนดีพลอย เพื่อให้ทุกเวอร์ชันมีคำแปลล่าสุด
.github/workflows/translate.yml
# .github/workflows/translate.yml
name: Translate
on:
  push:
    branches: [main]
    paths: ['locales/en/**']

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Translate changed strings
        run: |
          npx i18n-agent translate locales/en.json \
            --to de,ja,es,fr,ko,zh-Hans \
            --api-key ${{ secrets.I18N_AGENT_API_KEY }}

      - name: Commit translations
        run: |
          git config user.name "github-actions"
          git config user.email "[email protected]"
          git add locales/
          git diff --cached --quiet || git commit -m "chore: update translations"
          git push
.gitlab-ci.yml
# .gitlab-ci.yml
translate:
  stage: deploy
  only:
    changes:
      - locales/en/**
  script:
    - npx i18n-agent translate locales/en.json
        --to de,ja,es,fr --api-key $I18N_AGENT_API_KEY
    - git add locales/ && git commit -m "chore: translations" && git push
4

เพิ่ม QA การแปลลงใน CI

การตรวจสอบอัตโนมัติในไปป์ไลน์ CI จะจับคำแปลที่หายไป ตัวยึดตำแหน่งเสียหาย และรูปแบบข้อความ ICU ไม่ถูกต้องก่อนถึงระบบจริง โดยเป็นสคริปต์ง่ายๆ ที่เปรียบเทียบไฟล์ภาษาต้นฉบับกับภาษาเป้าหมายทั้งหมด

หากไม่มีการตรวจสอบคำแปลระดับ CI คำแปลที่หายไปจะเข้าสู่ระบบจริงโดยไม่แจ้งเตือน ผู้ใช้เห็นคีย์ดิบอย่าง “settings.title” หรือข้อความว่างแทนข้อความที่แปลแล้ว การตรวจสอบ CI เพียง 5 นาทีป้องกันปัญหานี้ได้ทั้งหมด
check-translations.sh
#!/bin/bash
# check-translations.sh — Run in CI to catch missing translations

SOURCE="locales/en.json"
LANGS=("de" "ja" "es" "fr")
EXIT_CODE=0

# Extract all keys from source
SOURCE_KEYS=$(jq -r '[paths(scalars)] | map(join(".")) | .[]' "$SOURCE" | sort)
SOURCE_COUNT=$(echo "$SOURCE_KEYS" | wc -l)

for lang in "${LANGS[@]}"; do
  TARGET="locales/$lang.json"
  if [ ! -f "$TARGET" ]; then
    echo "❌ Missing: $TARGET"
    EXIT_CODE=1
    continue
  fi

  TARGET_KEYS=$(jq -r '[paths(scalars)] | map(join(".")) | .[]' "$TARGET" | sort)
  MISSING=$(comm -23 <(echo "$SOURCE_KEYS") <(echo "$TARGET_KEYS"))

  if [ -n "$MISSING" ]; then
    COUNT=$(echo "$MISSING" | wc -l)
    echo "❌ $lang: $COUNT missing keys"
    echo "$MISSING" | head -5
    EXIT_CODE=1
  else
    echo "✅ $lang: all $SOURCE_COUNT keys present"
  fi
done

exit $EXIT_CODE
check-placeholders.sh
#!/bin/bash
# check-placeholders.sh — Validate placeholder consistency

SOURCE="locales/en.json"
LANGS=("de" "ja" "es")

for lang in "${LANGS[@]}"; do
  TARGET="locales/$lang.json"

  # Compare placeholders like {{name}}, {count}, %s, %d
  jq -r 'paths(scalars) as $p | [($p | join(".")), (getpath($p))]
    | @tsv' "$SOURCE" | while IFS=$'\t' read -r key value; do
    SOURCE_PH=$(echo "$value" | grep -oE '\{\{[^}]+\}\}|%[sd@]' | sort)
    TARGET_VAL=$(jq -r "getpath($(echo $key | jq -R 'split(".")'))" "$TARGET")
    TARGET_PH=$(echo "$TARGET_VAL" | grep -oE '\{\{[^}]+\}\}|%[sd@]' | sort)

    if [ "$SOURCE_PH" != "$TARGET_PH" ]; then
      echo "❌ $lang/$key: placeholder mismatch"
      echo "   Source: $SOURCE_PH"
      echo "   Target: $TARGET_PH"
    fi
  done
done

ตรวจสอบคำแปลใน CI

เพิ่ม i18n-validate ลงในไปป์ไลน์ CI เพื่อจับคีย์ที่หายไป ตัวยึดตำแหน่งเสียหาย และปัญหาพหูพจน์โดยอัตโนมัติ ใช้ i18n-pseudo สร้างคำแปลจำลองสำหรับการทดสอบการถดถอยด้านภาพ
5

ตรวจหาและจัดการการคลาดเคลื่อนของคำแปล

การคลาดเคลื่อนของคำแปลเกิดขึ้นเมื่อข้อความต้นฉบับเปลี่ยนแต่คำแปลไม่อัปเดต ภาษาอังกฤษเขียนว่า “Save changes” แต่ภาษาเยอรมันยังเป็นข้อความเดิม การตรวจหาการคลาดเคลื่อนจะเปรียบเทียบเวลาของไฟล์ต้นฉบับกับไฟล์แปล หรือแฮชเนื้อหา

คำแปลเก่าแย่กว่าคำแปลที่หายไป คำแปลที่หายไปผิดอย่างเห็นได้ชัด ผู้ใช้จะเห็นคีย์หรือภาษาสำรอง แต่คำแปลเก่ากลับสื่อข้อความผิดอย่างน่าเชื่อถือ ซึ่งอาจทำให้ผู้ใช้เข้าใจผิดหรือสร้างปัญหาด้านการสนับสนุน
detect-drift.sh
#!/bin/bash
# detect-drift.sh — Find stale translations

SOURCE="locales/en.json"
SOURCE_HASH=$(md5sum "$SOURCE" | cut -d' ' -f1)
HASH_FILE=".translation-hashes"

# Compare current source hash with stored hash
if [ -f "$HASH_FILE" ]; then
  STORED_HASH=$(grep "^en:" "$HASH_FILE" | cut -d: -f2)
  if [ "$SOURCE_HASH" != "$STORED_HASH" ]; then
    echo "⚠️  Source strings changed since last translation"
    echo "   Run translations to update all locales"

    # Show which keys changed
    git diff HEAD~1 "$SOURCE" | grep '^[+-]' | grep -v '^[+-][+-]'
  fi
fi

# Update stored hash
echo "en:$SOURCE_HASH" > "$HASH_FILE"
6

เลือกแนวทางการแปล

เนื้อหาแต่ละชนิดไม่จำเป็นต้องใช้แนวทางการแปลเดียวกัน ข้อความ UI และป้ายเหมาะกับการแปลด้วย AI ข้อความการตลาดได้ประโยชน์จาก AI ร่วมกับการตรวจทานโดยมนุษย์ ส่วนข้อความกฎหมายและการปฏิบัติตามข้อกำหนดควรให้นักแปลมืออาชีพแปลเสมอ

การแปลด้วย AI จัดการข้อความทั่วไปในแอปได้มากกว่า 80% ด้วยคุณภาพพร้อมใช้งานจริง ให้นักแปลดูแลข้อความกฎหมาย น้ำเสียงของแบรนด์ และเนื้อหาที่อ่อนไหวทางวัฒนธรรมซึ่งความละเอียดอ่อนสำคัญที่สุด
Cost Comparison
Translation Approach Comparison:

Content Type         | Approach          | Cost/word  | Quality
─────────────────────┼───────────────────┼────────────┼──────────
UI strings, labels   | AI/LLM            | $0.001-01  | Production
Tooltips, help text  | AI/LLM            | $0.001-01  | Production
Marketing copy       | AI + human review | $0.05-0.15 | High
Legal / compliance   | Human translator  | $0.15-0.40 | Certified
Brand voice content  | Human translator  | $0.20-0.50 | Premium
7

เวิร์กโฟลว์ Git สำหรับคำแปล

แปลในสาขาฟีเจอร์ก่อนผสาน ไม่ใช่หลังผสาน วิธีนี้รับประกันว่าทุกการผสานเข้า main มีคำแปลครบถ้วน เพิ่มการตรวจสอบก่อนผสานเพื่อยืนยันความครบถ้วนของคำแปลในทุกภาษาที่รองรับ

ไฟล์ภาษา JSON ขนาดใหญ่ทำให้เกิดข้อขัดแย้งขณะผสานบ่อยเมื่อหลายสาขาแก้ไขพร้อมกัน เรียงคีย์ตามตัวอักษรและใช้หนึ่งคีย์ต่อบรรทัดเพื่อลดขนาดส่วนต่างและทำให้แก้ข้อขัดแย้งได้ง่ายขึ้น

ไฟล์แปลอยู่ในที่เก็บข้างโค้ด จึงอยู่ภายใต้การควบคุมเวอร์ชัน ตรวจทานได้ใน pull request และดีพลอยผ่านไปป์ไลน์เดียวกับทุกสิ่ง
.gitattributes + package.json
# .gitattributes — reduce merge conflicts in locale files
locales/*.json merge=union

# Sort keys alphabetically to minimize diffs:
# package.json script:
"sort-locales": "node -e \"
  const fs = require('fs');
  const f = process.argv[1];
  const d = JSON.parse(fs.readFileSync(f));
  const s = (o) => Object.keys(o).sort().reduce((r,k) =>
    ({...r, [k]: typeof o[k]==='object' ? s(o[k]) : o[k]}), {});
  fs.writeFileSync(f, JSON.stringify(s(d), null, 2)+'\\n');
\""

ข้อผิดพลาดที่พบบ่อย

มองโลคัลไลเซชันเป็นงานหลังการพัฒนา

ข้อผิดพลาดใหญ่ที่สุดคือรอให้พัฒนาเสร็จแล้วค่อยแปล วิธีนี้สร้างคอขวด ทำให้เผยแพร่ล่าช้า และทำให้การแปลเป็นเพียงสิ่งที่นึกถึงภายหลัง ควรแปลระหว่างพัฒนา ไม่ใช่หลังพัฒนา

ไม่มีการตรวจสอบคำแปลระดับ CI

หากไม่มีการตรวจสอบอัตโนมัติ คำแปลที่หายไป ตัวยึดตำแหน่งเสียหาย และรูปแบบไม่ถูกต้องจะเข้าสู่ระบบจริง เพิ่มการตรวจสอบความครบถ้วนและรูปแบบลงในไปป์ไลน์ CI

ออกแบบเกินความจำเป็นด้วย TMS

TMS ออกแบบมาเพื่อจัดการเวิร์กโฟลว์ของนักแปล หากใช้การแปลด้วย AI คุณอาจไม่ต้องแบกรับภาระของ TMS เริ่มแบบเรียบง่ายด้วยการแปลใน IDE หรือ CI/CD แล้วเพิ่ม TMS เฉพาะเมื่อต้องจัดการนักแปล

ไม่ติดตามความใหม่ของคำแปล

หากไม่ติดตามความใหม่ คุณจะไม่รู้ว่าคำแปลใดเก่า ข้อความต้นฉบับเปลี่ยนแต่คำแปลเดิมยังอยู่ ให้สร้างการตรวจหาการคลาดเคลื่อนในเวิร์กโฟลว์เพื่อจับเนื้อหาเก่า

ลองใช้ i18n Agent ตอนนี้

ลากและวางไฟล์แปลของคุณที่นี่

JSON, YAML, PO, XML, CSV, Markdown, Properties

หรือคลิกเพื่อเลือกไฟล์

ภาษาเป้าหมาย

ไม่ต้องลงทะเบียนประเมินราคาได้ทันที

คำถามที่พบบ่อย