Wykład 4: Terminologia i lokalizacyjne formaty danych

Wykład 4: Terminologia i lokalizacyjne formaty danych dr inż. Agenor Hofmann-Delbor

Plan wykładu • Omówienie najważniejszych problemów związanych z terminologią • Wprowadzenie pojęcia konceptu terminologicznego • Podział formatów lokalizacyjnych: UI - UA • Metodyka lokalizacji formatów UI • Metodyka lokalizacji formatów UA • Strony kodowe w lokalizacja oprogramowania • Konwersje danych

Rodzaje terminów • Zorientowany na koncept • „Jaka jest nazwa dla...?“ • Zorientowany na hasło • Co oznacza ...?“ • Synonim • Dwa terminy odnoszące się do tej samej rzeczy • Homonim • Dwa identyczne terminy odnoszące się do różnych rzeczy

Terminologia w tabeli – jak radzić sobie z synonimami? Dodać kolumnę? Gdzie wstawić termin Taste?

Terminologia w tabeli – jak radzić sobie z synonimami? Dodać wiersz? Ręczne dopisywanie – tworzenie duplikatów

Terminologia w tabeli – jak radzić sobie z synonimami? Dodać w tej samej komórce? Wyszukiwanie słowa „Taste”przy pozycji Schaltfläche na literę „S”

Terminologia w tabeli – jak radzić sobie z synonimami? Dodać identyfikator?

Terminologia w tabeli – jak radzić sobie z synonimami? Dodanie ID – c.d., posortowanie A-Z powoduje problemy z wyszukiwaniem ? ? ?

Terminologia w tabeli – pola atrybutowe • Dodawanie dodatkowych pól np. przykładów spowoduje znaczne skomplikowanie formy arkusza z terminologią w postaci tabelki

Podejście strukturalne – koncept terminologiczny

Od terminologii do lokalizacji • Najczęściej podstawowa terminologia jest ustalana jeszcze przed rozpoczęciem tłumaczenia, ale przy nowych produktach jest ona często wypadkową dyskusji między zleceniodawcą a firmą lokalizacyjną – vide „ribbon – wstęga” • W projektach lokalizacyjnych najczęściej bazy terminologiczne powstają z tekstów wyciągniętych z plików UI (User Interface). Umożliwia to pracę tłumaczy nad dokumentacją (UA – User Assistance) z zachowaniem spójności z produktem, który dopiero powstaje. Ogólny, umówny podział projektów to: SW (UI) i DOC (UA). • Bazy terminologiczne i pamięci tłumaczeń funkcjonują niezależnie, ale korzystanie z bazy terminologicznej w konsekwencji nasyca pamięć tłumaczeń tłumaczeniami zawierającymi zatwierdzoną terminologię, więc terminologia znajdzie się też w pamięci tłumaczeń.

Lokalizacja plików UI • Specjalistyczne narzędzia • Edycja na poziomie projektów przed kompilacją lub już po skompilowaniu (rzadziej) • Pliki exe, dll, res, resx, properties, projekty .NET, Java etc. • Resizing okien dialogowych i formularzy • Kontrola poprawności wprowadzanych danych • Testy i eliminowanie konfliktów

Lokalizacja plików UA • Dawniej format Microsoft WinHelp (bazujący na RTF plik hlp, obsługiwany do Win XP), obecnie wyłącznie format HTML Help – chm: • Oparty na liście plików html • Zawiera aktywne odsyłacze, spis treści, skorowicz i system wyszukiwania • Plik definicji archiwum (*.hhp) • Plik skorowidza (*.hhk) • Dedykowany kompilator HTML Help Workshop (możliwa jest dekompilacja archiwum chm do plików źródłowych) • Archiwa można uruchamiać wyłącznie w środowisku Windows • W innych sytuacjach lokalizowane są „zrzuty” z systemów CMS w postaci plików xml. Najczęściej jednak lokalizuje się źródłowe pliki rtf, doc i html.

Strony kodowe a lokalizacja Zestawiając znaki pisarskie (litery, cyfry, itp.) z odpowiadającymi im kodami tworzymy zestaw znaków. Ułatwia to konwersję na postać cyfrową. Takich tabel powstawało z czasem bardzo wiele, co więcej – bywały niespójne. Powodowało to liczne problemy z wyświetlaniem znaków. Do zapisu znaków wykorzystywano maksymalnie jeden bajt, co oznaczało możliwość zapisania do 256 znaków z uwzględnieniem kodów sterujących. W praktyce więc do wyświetlania znaków z różnych alfabetów konieczne było przełączanie strony kodowej. Unicode stopniowo rozwiązuje ten problem. W założeniu ma obejmować wszystkie znaki ze wszystkich alfabetów świata. Jest ciągle rozwijany, a grupa współtwórców standardu obejmuje zarówno korporacje, uniwersytety, jak i indywidualnych entuzjastów tematu. Standardem w dokumentach xml/html stał się w praktyce UTF-8, w ramach którego alfabet łaciński wymaga użycia 1 bajtu do zapisu, znaki spoza alfabetu (np. polskie ś, ą, ź itd.) 2 bajtów, a znaki CJK (chiński, japoński, koreański) aż 3 bajtów. Możliwe jest bezpieczne konwertowanie znaków między różnymi stronami kodowymi, przy założeniu, że deklarowane kodowanie jest zgodne z faktycznym

Konwersje danych w ramach projektów lokalizacyjnych • Różne standardy, wymagania i sposoby przechowywania danych wymuszają konieczność licznych konwersji danych. Najczęściej konwertuje się: • Pliki bilingwalne z jednego sposobu segmentacji na inny • Fragmenty dokumentów nie wymagające lokalizacji blokuje się do edycji dla tłumacza poprzez konwersję tekstu na tekst ukryty (w ramach specjalnego stylu) • Konwersje dotyczą też materiału w różnych stronach kodowych, formatach etc. • Ogólna zasada – jeśli tylko jesteśmy w stanie wyodrębnić tekst źródłowy i odpowiadający mu tekst docelowy w sposób umożliwiający kopiowanie, to jest możliwe praktycznie nieograniczone przekształcenie tekstu np. w postać pliku importu pamięci tłumaczeń lub bazy terminologicznej • Przy konwersji należy zwrócić uwagę na problem potencjalnej utraty dodatkowych informacji lub na problem wersji danych (które zachować na koniec, które nadpisać)

Bibliografia + przydatne linki Michael Wetzel „Structuring Termbases” – Webinar (www.sdl.com) http://pl.wikipedia.org/wiki/HTML_Help http://pl.wikipedia.org/wiki/Zestaw_znak%C3%B3w http://pl.wikipedia.org/wiki/UTF-8 http://pl.wikipedia.org/wiki/Kategoria:Kodowania_znak%C3%B3w

Pytania, kontakt agenorh@zpsb.szczecin.pl

Wykład 4: Terminologia i lokalizacyjne formaty danych