Graj Po Polsku - forum autorskich spolszczeń gier

nie ma API dla skryptów. GUI w skryptach to Swing, a dostępne funkcje to wszystko to co znajdziesz w źródłach Omegi - odwołujesz się bezpośrednio do tych samych modułów/obiektów, jakie używa Omega w czasie działania.

Tyle, że czasem są drobne różnice w sposobie odwoływania do globalnych zmiennych i tu trzeba się posiłkować przykładami.

dzięki za info o jythonie - chociaż nie mam problemów z javą, to większość kodu w ostatnich latach robię w pythonie, a do tego groovy jest lekko wkr&*^& jeśli chodzi o tworzenie GUI w Swingu.

Akurat robienie gui i podpinanie pod eventy to coś, czego składni nie mogę rozgryźć przy używaniu Jythona. Nie, żebym miał na to wielkie zapotrzebowanie w tej chwili, ale miło byłoby to kiedyś rozgryźć :)

łatwiej jest napisać kilka regex-ów czy parser w pythonie, niż za każdym razem kolejny filtr do Omegi;-)

Zdecydowanie, ja istniejące tłumaczenia z reguły eksportuję do .po, bo jest to po prostu wygodny format, który spełnia większość moich oczekiwań, a konwersja w drugą stronę to pryszcz.

A ja mam takie pytanie (z pozoru proste i głupie, jednak dla mnie istotne) - załóżmy, że otrzymałem od twórców gry angielski skrypt, zawierający wypowiedzi postaci, opisy przedmiotów i komunikaty silnika gry. Jednak znajdują się w nim jeszcze 'znaczniki', typu 'SYSENGINE000', 'LINE000' i podobne. Po przetłumaczeniu skryptu muszę go oddać w takiej samej formie, czyli podmianie mają ulec jedynie 'właściwe' teksty z gry, a 'znaczniki' mają pozostać. Skonfigurowanie odpowiednich filtrów w Omedze, a co za tym idzie wydobycie tekstów z gry nie stanowi problemu. Ale nie mam pojęcia, jak postąpić po przetłumaczeniu? Eksportować segmenty do TXT, po czym ręcznie dodawać odpowiednie wpisy przed każdą linijką? A może istnieją jakieś filtry pozwalające na konwersję zwrotną?

Etykiety są pewnie oddzielone od właściwych tekstów jakimś tabulatorem albo czymś innym? Wtedy idąc po linii najmniejszego oporu, możesz ustawić segmentację, żeby dzieliła w tym miejscu. Oczywiście wtedy wszystkie etykiety pozostają widoczne w tekście, co może nie być do końca wygodne przy tłumaczeniu.

Praktycznie nie są niczym oddzielone od tekstu właściwego, wyróżnia je w niektórych przypadkach użycie wersalików w całej etykiecie, we wszystkich czterocyfrowe liczby porządkowe. Możliwe, że w ogóle odpuszczę pomysł tłumaczenia tego w OmegaT, bo coś to ciężko się 'ujarzmia' ;)

EDIT

Aye, jednak są oddzielone :)

Na wszelki wypadek poślij próbkę na maila albo jako załącznik PW.

polecam zapoznanie się z Tag Validation -> Regular expression for custom tags. pozwala zdefiniowac regexa definiującego tagi użytkownika. tego typu tag jest przez omegę wyróżniany, a jeśli nie jest włączona edycja tagów, to nie można go również zepsuć. to tak na szybko. docelowo polecałbym Okapi i ekstrakcję samych tekstów.

Przychylałbym się bardziej do drugiego rozwiązania, bo akurat etykiety jest właśnie lepiej przekonwertować tak, żeby w ogóle nie były widoczne w gołym tekście, tylko oddelegowane do pola msgctxt w .po. Swoją drogą, ustawienia tych regexów powinno dać się definiować na poziomie projektu, a nie globalnie.

na pewno byłoby łatwiej, ale na to też jest sposób. zajrzyj do helpa i przyjrzyj się komendzie wiersza poleceń: --config-dir. proteza? tak, ale działa i pozwala na personalizację innych globalnych ustawień zależnie od projektu.

Cóż, segmentację i filtry też konfigurowało się kiedyś globalnie, aż ktoś poszedł po rozum do głowy. Myślę więc, że miałoby sens też postąpienie tak samo z ustawieniem tego regexa. Może nie kłóciłoby się to z założeniami Didlera :) A proteza jak to proteza, dla kogoś technicznego to nie problem, ale dla niektórych tłumaczy, którzy za pan brat z wierszem poleceń i plikami wsadowymi nie są, może to być problem. Stąd będę postulował o dodanie tego atrybutu na poziomie projektu.

znasz miejsce gdzie zgłaszać błędy i prośby o funkcjonalność;-) a do tego czasu trzeba sobie radzić jak się da.