Jak przetłumaczyć instrukcję obsługi, nie naruszając ostrzeżeń, schematów ani układu

Aby bezpiecznie przetłumaczyć instrukcję obsługi, traktuj ją jako kontrolowany artefakt produktowy, a nie jako zbiór zdań. Ustal wersję produktu, zachowaj system ostrzeżeń instrukcji, zablokuj terminologię produktu i interfejsu, zinwentaryzuj tekst na schematach oraz zweryfikuj każdy opis i każdy odsyłacz po ponownym zbudowaniu przetłumaczonego pliku.

Właściwy priorytet jest następujący:

1. wersja źródłowa i zakres;
2. bezpieczeństwo i znaczenie proceduralne;
3. nazwy produktów, elementy sterujące oraz pozycje, których nie należy tłumaczyć;
4. etykiety na schematach i odsyłacze;
5. kompletność i struktura;
6. jasność języka docelowego; oraz
7. układ wizualny.

Pobierz arkusz kontroli tłumaczenia instrukcji obsługi do rejestrowania ostrzeżeń, terminów, rysunków, odsyłaczy, właścicieli, dowodów i statusu ponownego testu.

Ustal wersję produktu i instrukcji obsługi

Dopracowane tłumaczenie niewłaściwej instrukcji nadal jest niewłaściwe. Przed tłumaczeniem zapisz:

• nazwę produktu, model, wersję sprzętu lub oprogramowania oraz rynek;
• tytuł instrukcji źródłowej, numer dokumentu, wydanie i datę publikacji;
• język docelowy i ustawienia regionalne;
• uwzględnione i wykluczone załączniki, etykiety, karty szybkiego startu oraz tekst gwarancji;
• format pliku źródłowego i połączone pliki obrazów; oraz
• osoba, która może odpowiedzieć na pytania dotyczące produktu.

Jeśli materiał źródłowy nadal się zmienia, ustal punkt odcięcia i rejestr zmian. Nowe zmiany w źródle powinny trafiać do wersji docelowej poprzez jawną rewizję, a nie przez wysyłanie e-mailem zastępczych zdań, których nikt nie uzgadnia z kompletnym plikiem.

Ten rejestr wersji jest pierwszym wierszem w arkuszu kontrolnym do pobrania, ponieważ od niego zależy każda późniejsza kontrola.

Zachowaj system ostrzeżeń przed tłumaczeniem tekstu

Ostrzeżenia tworzą system: słowo sygnałowe, zagrożenie, skutek, działanie zapobiegawcze, symbol, umiejscowienie i odwołanie. Nie tłumacz każdego elementu niezależnie, zakładając, że zależność między nimi się utrzyma.

ISO 20607:2019 odnosi się do części instrukcji obsługi maszyn istotnych dla bezpieczeństwa, ich struktury i prezentacji w całym cyklu życia maszyny. IEC/IEEE 82079-1:2019 przedstawia szersze zasady i wymagania dotyczące informacji przeznaczonych do użytkowania. Standardy te nie sprawiają, że tłumaczenie maszynowe staje się zgodne z wymaganiami; pokazują, dlaczego przygotowanie i walidacja instrukcji są dyscyplinami produkcyjnymi, a nie zastępowaniem zdań.

Dla każdego ostrzeżenia zanotuj:

• stały identyfikator ostrzeżenia;
• źródłowe i docelowe słowo sygnałowe;
• opis zagrożenia;
• opis skutku;
• instrukcję unikania;
• odniesienie do symbolu lub obrazu;
• strona, sekcja i procedura, w których się pojawia; oraz
• wymagany recenzent.

Zachowaj hierarchię stopni ważności ze źródła. Nie zastępuj pochopnie jednego słowa sygnałowego innym, bardziej znajomym synonimem. W przetłumaczonym układzie sprawdź, czy ostrzeżenie nie zostało oddzielone od kroku, rysunku lub warunku, którego dotyczy.

Utwórz trzy kontrolowane listy

Jeden glosariusz nie wystarczy. Rozdziel trzy rodzaje kontroli.

Zatwierdzona terminologia

Zapisz termin źródłowy, zatwierdzony termin docelowy, definicję, kontekst, wielkość liter, zasadę tworzenia liczby mnogiej lub odmiany oraz odrzucone warianty. Stosuj jeden termin do jednego pojęcia produktowego, chyba że źródło celowo rozróżnia dwa pojęcia.

Aktualne wytyczne Microsoft dotyczące ostrożnego używania terminów technicznych zalecają spójne terminy i definicje, gdy są potrzebne. Ta sama zasada jest jeszcze ważniejsza w tłumaczeniu: przechodzenie między dwoma prawdopodobnymi terminami docelowymi może sprawić, że czytelnik uzna, iż instrukcja odnosi się do dwóch różnych części.

Elementy, których nie należy tłumaczyć

Wskaż ciągi znaków, które muszą pozostać bez zmian, takie jak:

• numery modeli i numery części;
• wartości wiersza poleceń, rozszerzenia plików i kod;
• znaki towarowe lub nazwy produktów określone przez projekt;
• identyfikatory regulacyjne;
• dosłowne etykiety interfejsu, które nie zostały zlokalizowane; oraz
• oznaczenia złączy, portów lub elementów sterujących, które znajdują się fizycznie na produkcie.

„Nie tłumaczyć” nie znaczy „ignorować”. Zweryfikuj ciąg znak po znaku i zadbaj o jasność otaczającej go konstrukcji gramatycznej.

Etykiety interfejsu i fizycznych elementów sterujących

Utwórz osobne mapowanie dla przycisków, elementów menu, etykiet ekranowych, pokręteł, wskaźników i oznaczeń nadrukowanych na produkcie. Zapisz, czy interfejs docelowy istnieje.

Jeśli interfejs użytkownika produktu nadal wyświetla Settings, przetłumaczenie instrukcji z podręcznika jako „Open Preferences” powoduje problem z odnalezieniem tej opcji, nawet jeśli oba wyrażenia są językowo poprawne. Zdecyduj, czy podręcznik powinien przytaczać etykietę źródłową, etykietę zlokalizowaną, czy obie.

W przypadku długich dokumentów workflow spójności terminologicznej zapewnia strukturę wielokrotnego użytku dla form zatwierdzonych i odrzuconych.

Sporządź wykaz tekstów, które nie należą do głównego toku tekstu

Podręczniki ukrywają treści przeznaczone do tłumaczenia w:

• diagramach i zrzutach ekranu;
• etykietach objaśniających;
• polach tekstowych i panelach bocznych;
• komórkach tabel;
• nagłówkach i stopkach;
• generowanych spisach treści;
• podpisy pod ilustracjami;
• grafiki z odnośnikami;
• eksporty CAD; oraz
• zeskanowane strony.

Utwórz identyfikator zasobu dla każdej ilustracji. Zapisz, czy jej tekst jest edytowalny, osadzony w obrazie, czy przedstawiony za pomocą numerowanych odsyłaczy. Jeśli obrazu źródłowego nie da się edytować, zdecyduj, czy odtworzyć go na nowo, dodać przetłumaczoną legendę, czy pozostawić go z zatwierdzonym wyjaśnieniem.

Nie twierdź, że translator dokumentów odrysuje każdy schemat. BookTranslator może zachować obrazy i strukturę dokumentu tam, gdzie jest to obsługiwane, ale tekst wewnątrz obrazów i złożona grafika produkcyjna mogą wymagać oddzielnej edycji i przeglądu.

Wybierz format źródłowy na podstawie tego, co musi pozostać edytowalne

Użyj oryginalnego, edytowalnego pliku źródłowego, jeśli go posiadasz. PDF jest przydatny jako wizualny punkt odniesienia, ale często stanowi słaby zamiennik pliku autorskiego. Jeśli istnieje tylko plik PDF oparty na tekście, postępuj zgodnie z przepływem pracy tłumaczenia PDF z zachowaniem formatowania. Jeśli plik źródłowy jest w formacie DOCX, zachowaj style i edytowalne struktury, korzystając z przepływu pracy tłumaczenia dokumentu Word.

Najpierw przetłumacz reprezentatywną sekcję testową

Wybierz sekcję zawierającą kilka potencjalnych punktów awarii:

• co najmniej jedno ostrzeżenie;
• procedurę numerowaną;
• diagram z odnośnikami;
• tabelę;
• odsyłacz;
• etykietę interfejsu; oraz
• stronę o ciasnym układzie.

Przetłumacz i odbuduj tę sekcję przed przetwarzaniem całej instrukcji. Użyj jej, aby odpowiedzieć na pytania:

• Czy glosariusz pasuje do rzeczywistych zdań?
• Czy ostrzeżenia są nadal kompletne wizualnie i semantycznie?
• Czy język docelowy zmieści się bez zastosowania nieczytelnej czcionki?
• Czy etykiety odpowiadają produktowi i interfejsowi użytkownika?
• Czy diagramy można zaktualizować przy użyciu dostępnych plików źródłowych?
• Czy format wyjściowy obsługuje wymagany przegląd?

Jeśli sekcja testu warunków skrajnych nie przejdzie, zmień workflow, zanim ten błąd zostanie powielony na 200 stronach.

Najpierw sprawdź strukturę, potem styl

Po zakończeniu pełnego tłumaczenia uzgodnij kompletną wersję docelową ze źródłem.

1. Porównaj liczbę sekcji, procedur, ostrzeżeń, tabel i rysunków.
2. Sprawdź pierwszy i ostatni element treści w każdej głównej sekcji.
3. Rozwiąż każde odwołanie typu „patrz sekcja”, „patrz rysunek” i „patrz tabela”.
4. Zweryfikuj ponumerowane kroki, wypunktowania, wymagania wstępne i rezultaty.
5. Wyszukaj pozostałości języka źródłowego i porównaj je z listą DNT.
6. Wyszukaj każdy zatwierdzony i odrzucony wariant terminologiczny.
7. Sprawdź liczby, jednostki, tolerancje, wartości momentu dokręcania, temperatury, daty, adresy URL i identyfikatory.
8. Potwierdź, że nagłówki, stopki, kody rewizji i informacje prawne zawierają prawidłowe dane wydania.

Zmienione oznaczenie wywołania może stworzyć ukrytą wadę. Jeśli w źródle jest napisane „Naciśnij element 4”, a na przetłumaczonym rysunku zostanie on przenumerowany na 5, zarówno zdanie, jak i diagram mogą wyglądać wiarygodnie, podczas gdy instrukcja stanie się bezużyteczna.

Redaguj z myślą o użyciu w języku docelowym, a nie o symetrii względem języka źródłowego

Gdy informacje kontrolowane są już ustabilizowane, zredaguj procedury pod kątem przejrzystości w języku docelowym. W miarę możliwości zachowuj jedno działanie na krok. Umieszczaj warunki przed działaniami, jeśli zapobiega to niewłaściwemu użyciu. Zachowuj zamierzone powtórzenia, gdy wskazują tę samą część lub ten sam element sterujący.

Wytyczne Microsoft dotyczące pisania globalnego zalecają krótkie, jasne zdania, spójną konstrukcję oraz unikanie idiomów i odniesień specyficznych kulturowo w technicznych treściach przeznaczonych do tłumaczenia. Nie „ulepszaj” instrukcji w języku docelowym przez dodawanie różnorodności, która osłabia spójność terminologii.

W tym miejscu postedycja wykonywana przez człowieka ma swoje miejsce: po zweryfikowaniu kompletności i treści kontrolowanej, a nie zamiast tych kontroli.

Zweryfikuj odtworzoną instrukcję jako produkt

Przeprowadź trzy oddzielne zatwierdzenia.

Weryfikacja językowa i techniczna

• Znaczenie odpowiada źródłu.
• Terminologia produktowa i etykiety elementów sterujących są zatwierdzone.
• Ostrzeżenia zachowują rodzaj zagrożenia, konsekwencję i działanie zapobiegawcze.
• Jednostki, wartości i identyfikatory są poprawne.
• Procedury w języku docelowym są jasne dla zamierzonego użytkownika.

Weryfikacja strukturalna

• Obecna jest każda procedura, każde ostrzeżenie, każda tabela, każdy rysunek, każdy aneks i każda uwaga.
• Odsyłacze prowadzą do właściwego elementu docelowego.
• Pozycje spisu treści i zakładki otwierają właściwe sekcje.
• Odwołania do elementów na rysunkach odpowiadają otaczającym je instrukcjom.

Weryfikacja wizualna i kontrola przed dostarczeniem

• Żadne ostrzeżenie, tabela, podpis ani instrukcja nie są obcięte.
• Podziały stron nie oddzielają warunków wstępnych od działań.
• Czcionki obsługują docelowe pismo i są dopuszczone do dostarczenia.
• Plik PDF lub DOCX otwiera się w aplikacjach, których będzie używać odbiorca.
• Nazwa pliku, rewizja, ustawienia regionalne i pakiet wydania są zgodne z rejestrem dostarczenia.

W przypadku pliku PDF dostosuj listę kontrolną QA tłumaczenia PDF zamiast wymyślać osobny standard wizualny podczas końcowej korekty.

Gdzie pasuje BookTranslator

BookTranslator potrafi przetłumaczyć kompletny plik PDF lub DOCX oparty na tekście, użyć automatycznego glosariusza dla powtarzających się terminów oraz zapewnić wynik dwujęzyczny tam, gdzie jest to obsługiwane. Prześlij reprezentatywny plik źródłowy przez tłumacz PDF lub tłumacz DOCX, sprawdź zwróconą strukturę i zweryfikuj sekcję obciążeniową przed skalowaniem workflow.

W przypadku zeskanowanych instrukcji tryb OCR służy do odzyskania i przetłumaczenia czytelnej treści, a nie do odtworzenia każdej oryginalnej współrzędnej, czcionki ani etykiety na diagramie. Instrukcje związane z bezpieczeństwem, objęte regulacjami lub przeznaczone do użytku publicznego nadal wymagają odpowiedniej weryfikacji technicznej, językowej i zgodności.

Końcowa bramka publikacji instrukcji użytkownika

Publikuj tylko wtedy, gdy:

• wersje produktu i instrukcji są zamrożone i odnotowane;
• ostrzeżenia, terminologia, pozycje DNT, elementy sterujące i etykiety interfejsu mają przypisanych właścicieli;
• dla każdego rysunku i każdego zasobu z osadzonym tekstem określono sposób postępowania;
• liczby dla pełnego pliku i odwołania krzyżowe są zgodne;
• recenzenci techniczni i docelowego języka zamknęli główne kwestie;
• ostateczny plik PDF lub DOCX przeszedł kontrolę wizualną i funkcjonalną; oraz
• pakiet publikacyjny identyfikuje dokładne źródło, język docelowy, ustawienia regionalne i rewizję.

Zasada nadrzędna jest prosta: tłumaczenie instrukcji użytkownika jest udane wtedy, gdy użytkownik może wykonać prawidłowe działanie przy użyciu właściwej wersji produktu. Płynny styl jest konieczny, ale nie jest podstawowym kryterium akceptacji.