Poruszaliśmy ostatnio temat tworzenia prawidłowych powiązań między pisaniem dokumentacji a jej lokalizowaniem. W praktyce zdarzają się również takie scenariusze:
- Pracujesz w dziale dokumentacji (technical writingu). WTEM! Pod koniec projektu dostajesz dodatkowe zadanie: weź to tam daj do tłumaczenia. Na siedem języków i żeby było do końca miesiąca. No cóż, pewnie trzeba będzie wysłać PDF-a do jakiegoś biura tłumaczeń.
- Masz doświadczenie w tłumaczeniach, postanawiasz przekwalifikować się na dokumentalistę (technical writera). W Twoim nowym miejscu pracy wszyscy bardzo się cieszą, że wniesiesz doświadczenie na temat lokalizacji, która dzięki Tobie będzie przebiegać lekko, łatwo i przyjemnie i nikt o niej więcej nie usłyszy.
W każdej z tych sytuacji potrzebne będzie zdefiniowanie sposobu przygotowania dokumentacji do tłumaczenia – i w trakcie pisania, i tuż przed wysłaniem tekstu do tłumaczy – oraz stworzenie takiej instrukcji dla pozostałych pisarzy, żeby nie trzeba było wymyślać tego koła za każdym razem na nowo.
Przykładem instrukcji jest strona Prepare DITA content for localization autorstwa Łukasza Drobnika, która koncentruje się na treściach w formacie DITA, pisanych w edytorze Oxygen i tłumaczonych w wybranym narzędziu CAT (memoQ). Treść strony została napisnia w Oxygenie w formacie DITA 🙂 Do publikacji posłużyło środowisko GitHub Pages.
Strona powstała jako projekt zaliczeniowy na studiach podyplomowych Komunikacja Techniczna w Akademii Finansów i Biznesu Vistula, natomiast przykłady są w pełni zgodne z najnowszymi wytycznymi ministerialnymi dla Szkoły Magii i Czarodziejstwa w Hogwarcie.
