Tłumaczenie instrukcji obsługi. Jak przygotować pliki i terminologię?

Najpierw ustal przeznaczenie instrukcji i wymagania właściwe dla produktu

IEC/IEEE 82079-1 opisuje ogólne zasady przygotowywania informacji potrzebnych użytkownikom produktów. ISO 20607 dotyczy natomiast związanych z bezpieczeństwem części instrukcji maszyn. Zakres obu dokumentów jest różny, dlatego przed tłumaczeniem trzeba sprawdzić normy branżowe, przepisy i wymagania klienta odnoszące się do konkretnego produktu. Samo powołanie się na ogólny standard nie zastępuje takiej kwalifikacji.

Brief powinien wskazywać użytkownika, rynek, etap życia produktu i warunki użycia. Instalator, serwisant i osoba korzystająca z urządzenia po raz pierwszy potrzebują innego poziomu szczegółowości. Trzeba też nazwać rodzaj materiału, ponieważ podręcznik użytkownika, karta szybkiego startu, etykieta, komunikat interfejsu i instrukcja montażu pełnią odmienne funkcje.

Przygotuj specyfikację projektu, zanim przekażesz tekst do tłumaczenia

Specyfikacja projektu powinna określać język i jego odmianę, odbiorcę, formaty wejściowe i wynikowe, zasady terminologiczne, etapy kontroli oraz osobę zatwierdzającą pytania techniczne. Warto również ustalić, czy zakres kończy się na pliku tłumaczenia, czy obejmuje skład i sprawdzenie gotowej instrukcji. Takie ustalenia odpowiadają podejściu procesowemu opisanemu w ISO 17100, ale nie oznaczają certyfikacji Planet Natives ani konkretnego projektu.

W briefie trzeba wskazać hierarchię źródeł. Jeżeli nazwa części różni się między dokumentacją konstrukcyjną, katalogiem i stroną sprzedażową, tłumacz powinien wiedzieć, które źródło jest nadrzędne. Nierozstrzygnięta sprzeczność powinna trafić do osoby odpowiedzialnej za produkt, a nie zostać usunięta przez przypadkowy wybór jednego wariantu.

• Docelowy użytkownik, rynek i odmiana języka.
• Rodzaj dokumentu oraz etap życia produktu, którego dotyczy.
• Wymagane formaty, program źródłowy i sposób dostawy.
• Hierarchia źródeł terminologii i osoba zatwierdzająca pytania.
• Zakres rewizji, konsultacji technicznej, składu i kontroli końcowej.

Zamroź wersję źródłową i prowadź rejestr zmian

Podstawą pracy powinien być edytowalny plik z zachowaną strukturą, numerem wersji i datą zamrożenia treści. Skan PDF utrudnia rozpoznawanie powtórzeń, kontrolę zmian i ponowne umieszczenie tekstu w układzie. Gdy innego materiału nie ma, trzeba osobno przekazać grafiki, tabele, podpisy oraz informację o programie, w którym powstanie wersja finalna.

Zmiany wprowadzone po rozpoczęciu tłumaczenia należy zapisywać w jednym rejestrze. Każdy wpis powinien wskazywać zmieniony fragment, datę, przyczynę i modele produktu, których dotyczy. Pozwala to oddzielić aktualizację wspólną dla całej serii od poprawki właściwej tylko jednemu wariantowi.

• Edytowalny plik źródłowy, numer wersji i data zamrożenia treści.
• Lista produktów, modeli i rynków objętych instrukcją.
• Zdjęcia, schematy, tabele i kontekst ekranów.
• Poprzednie zatwierdzone tłumaczenia i aktualna specyfikacja.
• Rejestr zmian wprowadzanych podczas projektu.

Glosariusz powinien łączyć termin z funkcją i źródłem decyzji

Przy ważnym terminie zapisz zatwierdzony odpowiednik, definicję lub funkcję, model produktu, przykład użycia oraz źródło decyzji. Sama lista słów nie wyjaśnia, czy nazwa odnosi się do części, czynności, trybu pracy czy komunikatu systemowego. Dodatkowy kontekst ogranicza ryzyko wyboru odpowiednika poprawnego słownikowo, lecz błędnego w danym urządzeniu.

Spójność terminologii nie polega na automatycznym zastępowaniu każdego powtórzonego wyrazu tym samym słowem. Ten sam termin źródłowy może pełnić różne funkcje, a różne sformułowania źródłowe mogą nazywać jedną część. Glosariusz powinien chronić tożsamość produktu i znaczenie instrukcji, pozostawiając tłumaczowi swobodę potrzebną do zbudowania poprawnego zdania.

Ostrzeżenia i procedury wymagają osobnej ścieżki zatwierdzania

W treściach związanych z bezpieczeństwem trzeba zachować relację między zagrożeniem, działaniem użytkownika i możliwym skutkiem. Jeżeli źródło nie pozwala jej jednoznacznie odtworzyć, tłumacz powinien zgłosić pytanie. Nie wolno poprawiać sensu ostrzeżenia na podstawie domysłu ani osłabiać go tylko dlatego, że krótsza wersja lepiej mieści się w układzie.

Procedurę należy sprawdzić jako ciąg czynności. Numeracja, warunki wstępne, wyniki kroków, odsyłacze do ilustracji i momenty wymagające przerwania pracy muszą pozostać zgodne z produktem. Ostateczne potwierdzenie treści technicznej należy do kompetentnej osoby po stronie klienta.

Język kontrolowany stosuj wtedy, gdy wymaga go projekt

ASD-STE100 Simplified Technical English powstał dla dokumentacji technicznej i wykorzystuje reguły pisania oraz kontrolowany słownik. Jego celem jest ograniczenie niejednoznaczności w angielskich instrukcjach, szczególnie wtedy, gdy odbiorcy nie posługują się angielskim jako pierwszym językiem. Aktualnym wydaniem wskazanym przez organizację ASD jest Issue 9 ze stycznia 2025 roku.

STE nie jest uniwersalnym obowiązkiem dla każdej instrukcji. Jeżeli klient lub branża go nie wymaga, nadal można stosować jasne zasady redakcji technicznej, lecz nie należy przedstawiać dokumentu jako zgodnego z ASD-STE100. Decyzję o użyciu kontrolowanego języka trzeba zapisać w briefie razem z zasadami dotyczącymi terminów właściwych dla firmy i produktu.

Kontrola jakości kończy się na gotowym dokumencie

Rewizja dwujęzyczna porównuje przekład ze źródłem pod kątem kompletności, znaczenia, terminologii, liczb i jednostek. Osobny przegląd językowy sprawdza naturalność oraz czytelność tekstu docelowego. Po zatwierdzeniu obu warstw pozostaje kontrola finalnego pliku, która obejmuje między innymi odsyłacze, podpisy, kolejność czynności i zgodność ilustracji z tekstem.

Materiał trzeba sprawdzić ponownie po składzie lub wdrożeniu. Łamanie tekstu może oddzielić polecenie od grafiki, przesunąć ostrzeżenie na kolejną stronę albo uciąć ważny fragment tabeli. W ofercie powinno być wyraźnie zapisane, czy wykonawca kontroluje tylko plik tłumaczenia, czy również finalny PDF, interfejs lub system publikacyjny.

Potwierdzone doświadczenie: FOCUS Bikes i INVENTINI

Dla FOCUS Bikes przygotowaliśmy polskie tłumaczenia nazw produktów i części rowerowych z niemieckiego oraz angielskiego. Sama pierwsza partia obejmowała około 2000 wpisów. Projekt wymagał jednej polskiej nomenklatury dla dwóch języków źródłowych, proofreadingu i kontroli materiału po stronie klienta.

W realizacji INVENTINI tłumaczyliśmy stronę z polskiego na angielski, w tym terminy, opisy techniczne, zastosowania produktów i treści instruktażowe. Zakres wymagał zachowania relacji między nazwą produktu, parametrami, przeznaczeniem oraz sposobem użycia. Oba case studies pokazują, dlaczego pytania kontekstowe i spójna terminologia są częścią pracy, nie przeszkodą w jej realizacji.

Co przesłać do wyceny tłumaczenia instrukcji

Do pierwszej wyceny wystarczy reprezentatywny plik, para językowa, liczba słów lub stron, opis produktu oraz lista formatów. Podaj też rynek, odbiorcę, program źródłowy i oczekiwany zakres kontroli. Nie trzeba od razu przekazywać całej dokumentacji, jeśli wstępny materiał pokazuje strukturę i poziom trudności projektu.

Przy większym zestawie instrukcji warto rozpocząć od jednego modułu lub modelu. Taka partia pozwala ustalić terminologię, tryb zadawania pytań, sposób rewizji i format dostawy przed uruchomieniem całej serii. Planet Natives może na tej podstawie przygotować zakres przekładu, glosariusza, kontroli językowej oraz QA finalnego materiału.