Proces lokalizacji katalogu produktów

Zamroź źródło przed tłumaczeniem

Wyeksportuj katalog i zachowaj niezmienną migawkę źródła. Zapisz jego pochodzenie, czas eksportu oraz rewizję lub hash pliku. Każdemu wariantowi nadaj stabilną tożsamość i przed utworzeniem zadań językowych sprawdź brakujące lub zduplikowane identyfikatory. Prowadź manifest par produkt-locale, które zamierzasz przetworzyć.

Przygotowanie źródła oddziel od tłumaczenia. Sprzeczne wymiary, brakujące jednostki i niepoparte twierdzenia rozstrzygnij najpierw z właścicielem produktu. Normalizacja eksportu dostawcy może być konieczna; zapisz te poprawki jako zmiany źródła i uzyskaj akceptację właściciela dla wynikowej bazy przed rozpoczęciem pracy językowej.

Oddziel chronione fakty od edytowalnego tekstu

Utwórz chroniony rekord dla SKU, ceny, waluty, jednostki, relacji wariantów i innych wartości operacyjnych. Generuj wyłącznie patch tekstu. W czasie składania kopiuj chronione wartości bezpośrednio ze źródła i porównuj je ponownie, aby model nie stał się autorytetem dla pola, które jedynie widział jako kontekst.

Uczyń również twierdzenia śledzalnymi. Zatwierdzone stwierdzenia przechowuj z odwołaniami do dowodów, a etap tworzenia szkicu niech zgłasza wszystko, co jest niepoparte. Poniższa konfiguracja jest przykładową polityką pipeline'u, a nie plikiem akceptowanym przez Shopify lub WooCommerce. Adapter musi zmapować ją na rzeczywisty kontrakt celu.

{
  "identity": ["product_id", "variant_id", "locale"],
  "protected": ["sku", "price_minor", "currency", "unit", "parent_id"],
  "editable": ["title", "description", "care_text"],
  "revisionInputs": ["source", "glossary", "prompt"],
  "releaseRequires": ["field_checks", "fact_review", "language_review"],
  "destinationWrite": "separate_authorization"
}

Dołącz glosariusz i brief locale

Brief locale powinien wskazywać odbiorców, ton, zatwierdzoną terminologię i reguły prezentacji. Pojęcia produktowe trzymaj osobno od preferowanej pisowni. W3C ITS definiuje terminologię i metadane tłumaczeń, które mogą zasilać bogatszy system lokalizacji; ten proces używa prostszego, wersjonowanego rekordu redakcyjnego.

Niejednoznaczne terminy rozstrzygaj przykładami z rzeczywistej kategorii. Gdy wpis glosariusza się zmieni, wskaż dotkniętych kandydatów i zdecyduj, czy wymagają ponownego generowania, czy ukierunkowanej edycji. Każde locale powiąż z tą samą zatwierdzoną wersją źródła. Nie pozwól, aby jedno przetłumaczone wydanie stało się nieprzejrzanym źródłem pośrednim dla pozostałych.

Przypadek lokalny: 20 produktów, 40 patchy językowych

Zamrożony katalog 20 syntetycznych produktów został przetłumaczony na 20 japońskich i 20 niemieckich patchy przez agenta tłumaczeniowego jawnie skonfigurowanego dla gpt-5.6-luna z rozumowaniem xhigh. Każdy patch zawiera tylko sku, locale, title i description. Składacz kopiuje price, currency, material i dimensions z source.json, więc zachowanie tych faktów jest właściwością pipeline'u, a nie zadaniem kopiowania zleconym modelowi.

Zapisane validated-ja.json i validated-de.json zawierają po 20 wierszy i pustą listę failures. Ponowne składanie tylko do odczytu jest zgodne z oboma zapisanymi wynikami. Użyj tego wzorca we własnej partii: zachowaj rewizję źródła, zapisuj patche językowe osobno, a przed złożeniem pakietu przeglądowego zweryfikuj pokrycie i dozwolone pola.

Uruchom deterministyczne kontrole przed przeglądem redakcyjnym

Zweryfikuj schemat wyniku, dozwolone pola, mapowanie identyfikatorów, rewizję źródła, wymagany tekst i chronione wartości. Porównuj liczbę placeholderów z użyciem rzeczywistej gramatyki szablonów aplikacji. Parsuj znaczniki zamiast stosować ogólną zamianę tekstu w HTML. Wstrzymuj niepoprawne rekordy, zamiast prosić importer o ich naprawę.

W przypadku arkuszy OWASP dokumentuje ryzyko wstrzyknięcia formuł i brak uniwersalnej bezpiecznej transformacji CSV. Użyj przejrzanej polityki eksportu dla wybranego narzędzia arkuszowego i trzymaj ten artefakt osobno od importu maszynowego. Dodanie prefiksu escape do widoku człowieka nie może przypadkiem zmienić SKU w ładunku sklepu.

Powiąż decyzje przeglądu z rewizjami treści

Daj recenzentom fakty źródłowe, kontekst glosariusza, kandydata i ustrukturyzowane problemy. Wymagaj osobnych decyzji faktograficznych i językowych. Zapisz, kto zaakceptował treść i które rewizje widział. Recenzent może zaakceptować lokalne sformułowanie, jednocześnie wstrzymując twierdzenie wymagające dowodu; rekord powinien wyrażać to rozróżnienie.

W lokalnym przypadku przegląd AI poprawił japoński DEMO-003 z sformułowania sugerującego tekturę falistą na sformułowanie zgodne ze źródłową podkładką kartonową. Wyjaśnił również DEMO-010 jako oznaczające łącznie dwa uchwyty. Oryginalny wynik pozostaje w raw-ja.json. Oba złożone języki nadal mają review_status: unreviewed i translation_semantic_review: pending: te poprawki nie są akceptacją rodzimego użytkownika języka ani sprzedawcy.

Złóż i zweryfikuj pakiet celu

Wybierz kandydatów zaakceptowanych i aktualnych względem źródła, a następnie przekształć wyłącznie ich dozwolone pola. API tłumaczeń Shopify używa kontraktu zasobu i digestu; wdrożenie WooCommerce wymaga mapowania produktów, a dla wielu języków zweryfikowanej warstwy lokalizacji. Ogólny pakiet przeglądowy nie jest sam w sobie uniwersalnym importem sklepu.

Przetestuj mały autoryzowany import na staging. Zapisz wynik importera, odczytaj ponownie wskazane pola i przejrzyj zachowanie produktu oraz locale. Uzgodnij planowany zbiór produktów z zapisanymi wynikami. Nieudane wiersze trzymaj osobno i zachowaj poprzednie wartości do starannie ograniczonego odwrócenia, jeśli będzie potrzebne.

Zapisz wynik i jego granice

Ukończony manifest powinien łączyć źródło, glosariusz, prompty, kandydatów, kontrole, akceptacje i wyniki celu. Dla każdej próby zapisuj rzeczywiste użycie, gdy dowody są dostępne, w tym ponowienia. Brakujące użycie i brakujące wyniki przeglądu pozostaw jawnie nieznane. Plik, który można sparsować, nie dowodzi, że sklep go zaakceptował.

W ograniczonym przypadku lokalnym wybranym modelem była Luna, nie Astra, i nie było wywołania gatewaya ani rzeczywistego importu sklepu. Użycie API, identyfikatory żądań i rozliczenia nie były udostępnione; model_api_usage i model_api_cost pozostają null, a nie zero. Następnym krokiem jest akceptacja semantyczna, a po niej osobno autoryzowany test celu.

Częste pytania