Zalogowany jako: gość

Forum

Wątek: Tłumaczenia Eltena

Wróć do listy wątków

2 z 2

Poprzednia

21 z 40: zvonimirek222

i jeszcze dodam rzecz o ktorej kiedys juz mowilo sie glosno.
Te tlumaczenia nie maja sensu, do poki elten nie dostanie wsparcia dla Unicode. Widac to teraz po moim pisaniu z niepolskiego systemuu.
Student studentowi wszystko
31.10.2018 11:17

22 z 40: pajper

Pracuję nad tym. :)
Wy pracujecie nad przekładami, ja nad wsparciem kodowań.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
31.10.2018 11:18

23 z 40: zvonimirek222

sorry, ale nie mozesz nie wymagac wersji pro od tlumacza, skoro chcesz, zeby ci tlumaczenie wygladalo profesionalnie.
Tak sie, przeciez nie da.
Student studentowi wszystko
31.10.2018 11:18

24 z 40: zvonimirek222

bo jezeli wersja pro poedita ma to, czego w wersji free nie ma,
to sorry, ale jest to wazny argument do tlumacza, zeby mogl sie w tym lapac.
To z wersja free naprawde jest dziwnie, bo moja strategia tlumaczenia wygladala tak:
1. Musialem dla calego pliku .po zaznaczyc, ze wszystkie stringi sa niepewne,
a potem tlumaczyc dalej wszystkie stringi, z czego zaznaczanie string po string jako niepewny zajmuje duzo czasu.
Student studentowi wszystko
31.10.2018 11:22

25 z 40: pajper

Oznacze wam nowe stringi jako niepewne przy generowaniu plików, tyle mogę. :)
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
31.10.2018 11:30

26 z 40: zvonimirek222

dobra, to tak rob, i w tym watku wysylaj o tym powiadomienia.
Student studentowi wszystko
31.10.2018 12:08

27 z 40: dorkakrac

Z tego co porównywałam Poedit z innymi programi typu CAT Software, podstawowa wersja pro nie jest jeszcze taka strasznie droga. Można byłoby się ewentualnie w nią zaopatrzyć, chyba, że nie ma takiej potrzeby.
"Dziś robota nie jest w cenie, dzisiaj liczy się myślenie."
31.10.2018 15:47

28 z 40: dorkakrac

Jak tekst źródłowy i docelowy jest rozwiązywany w plikach .po do NVDA? Przyznam, że nasz czytnik ekranu tłumaczy się wygodnie, bo tekst źródłowy jest na swoim miejscu, a wprowadzane np. przeze mnie tłumaczenie w swoim polu.
"Dziś robota nie jest w cenie, dzisiaj liczy się myślenie."
31.10.2018 15:50

29 z 40: dorkakrac

Może by się udało tymi plikami zasugerować w tworzeniu naszych eltenowych?
"Dziś robota nie jest w cenie, dzisiaj liczy się myślenie."
31.10.2018 15:51

30 z 40: pajper

Proszę tłumaczy na język rosyjski i chorwacki o uzupełnienie tłumaczeń o dokumenty, najlepiej wysłane w formie tekstowej do mnie:
plik czytaj mnie (menu, pomoc, czytaj mnie),
licencję użytkownika (menu, pomoc, licencja użytkownika),
wykaz skrótów klawiszowych (menu, pomoc, lista skrótów klawiszowych).
Z góry bardzo dziękuję.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
05.11.2018 21:29

31 z 40: grzezlo

@dorka: w NVDA jest to właśnie tak zrobione, jak pisał Zvonimir, że tekst do tłumaczenia, to jest angielska wersja łańcucha, będąca jednocześnie identyfikatorem tego komunikatu.
A w polu tłumaczenia, przy nowych tekstach nie ma nic, albo jest to, co sobie program mergujący nowełańcuchy i stare uznał za prawdopodobne tłumaczenie (oznaczane wówczas jako niepewne).
W Eltenie Dawid wprowadził inne rozwiązanie, że identyfikatorem wiadomości do tłumaczenia nie jest angielska wersja, tylko jakiś ciąg znaków mniej lub bardziej związany z treścią komunikatu, no a tłumaczenie domyślne, np. polskie, trzeba zastąpić innym.
Czyli mamy np.:
msgid "Authentication:head_disabled"
msgstr "Dwuetapowe uwierzytelnianie jest włączone dla tego konta."

Rozwiązanie znane m.in. z NVDA, które też zastosowałem w Grmapie, ma tę zaletę, że jeśli jakiś komunikat nie jest przetłumaczony, to pojawi się jego angielska wersja, która jest identyfikatorem.
Nie wiem co byłoby w przypadku Eltena: czy wyświetliłby się tekst polski, czy ten identyfikator, który niewiele mówi użytkownikowi.
No i drugi plus, że jeśli w dwóch miejscach się pojawia ten sam komunikat angielski, to do tłumaczenia wystąpi tylko raz, a w podejściu z pliku elten.po, jesli ten sam tekst będzie miał trochę inny klucz, no to wówczas się swobodnie może powtarzać, a nawet musi, chyba, że jakimś osobnym narzędziem Dawid wykrywa takie rzeczy.

A trzeci, to czytelność kodu źródłowego, gdzie od razu widać o co chodzi, a nawet można go rozbudować o wskazówki dla tłumaczy, które się później pojawiają w pliku .po, np.:
//Translators: confirmation question before opening mail client
_('Do you want to create message to {eml} in default mail client?'),
(...)
gdzie w Eltenie mamy w kodzie źródłowym enigmatyczne
_("Account:head_status")
równie niejasne dla ewentualnego tłumacza, co programisty, bez podglądnięcia obok w pliku z jakimś tłumaczeniem co ten łańcuch miał oznaczać w praktyce.
No w każdym razie, ciekawe podejście do tematu, nie spotkałem się z nim wcześniej, a nie wiedziałem też, że w Linux go stosują... To już teraz rozumiem, dlaczego mimo, że jest to opensource, to stabilność mechanizmów dostępności w tym systemie operacyjnym jest jaka jest (żarcik).

05.11.2018 22:39

32 z 40: zvonimirek222

@grzezlo!
w linuxie, a dokladniej w orce, tlumaczenie robi sie normalnie, i jest to zrobione na podstawie
zrodlowy tekst jest w polu tylko do odczytu, ale tlumaczenie uzupelniasz w innym polu,
czyli identifikatorow nie ma
--Cytat (grzezlo):
@dorka: w NVDA jest to właśnie tak zrobione, jak pisał Zvonimir, że tekst do tłumaczenia, to jest angielska wersja łańcucha, będąca jednocześnie identyfikatorem tego komunikatu.
A w polu tłumaczenia, przy nowych tekstach nie ma nic, albo jest to, co sobie program mergujący nowełańcuchy i stare uznał za prawdopodobne tłumaczenie (oznaczane wówczas jako niepewne).
W Eltenie Dawid wprowadził inne rozwiązanie, że identyfikatorem wiadomości do tłumaczenia nie jest angielska wersja, tylko jakiś ciąg znaków mniej lub bardziej związany z treścią komunikatu, no a tłumaczenie domyślne, np. polskie, trzeba zastąpić innym.
Czyli mamy np.:
msgid "Authentication:head_disabled"
msgstr "Dwuetapowe uwierzytelnianie jest włączone dla tego konta."

Rozwiązanie znane m.in. z NVDA, które też zastosowałem w Grmapie, ma tę zaletę, że jeśli jakiś komunikat nie jest przetłumaczony, to pojawi się jego angielska wersja, która jest identyfikatorem.
Nie wiem co byłoby w przypadku Eltena: czy wyświetliłby się tekst polski, czy ten identyfikator, który niewiele mówi użytkownikowi.
No i drugi plus, że jeśli w dwóch miejscach się pojawia ten sam komunikat angielski, to do tłumaczenia wystąpi tylko raz, a w podejściu z pliku elten.po, jesli ten sam tekst będzie miał trochę inny klucz, no to wówczas się swobodnie może powtarzać, a nawet musi, chyba, że jakimś osobnym narzędziem Dawid wykrywa takie rzeczy.

A trzeci, to czytelność kodu źródłowego, gdzie od razu widać o co chodzi, a nawet można go rozbudować o wskazówki dla tłumaczy, które się później pojawiają w pliku .po, np.:
//Translators: confirmation question before opening mail client
_('Do you want to create message to {eml} in default mail client?'),
(...)
gdzie w Eltenie mamy w kodzie źródłowym enigmatyczne
_("Account:head_status")
równie niejasne dla ewentualnego tłumacza, co programisty, bez podglądnięcia obok w pliku z jakimś tłumaczeniem co ten łańcuch miał oznaczać w praktyce.
No w każdym razie, ciekawe podejście do tematu, nie spotkałem się z nim wcześniej, a nie wiedziałem też, że w Linux go stosują... To już teraz rozumiem, dlaczego mimo, że jest to opensource, to stabilność mechanizmów dostępności w tym systemie operacyjnym jest jaka jest (żarcik).

--Koniec cytatu

Student studentowi wszystko
05.11.2018 22:42

33 z 40: pajper

Skoro przedstawiono plusy sposobu stosowanego m.in. w NVDA, z którymi kłócił się nie będę, przedstawię teraz plusy podejścia Eltenowego.
Przede wszystkim łatwo zmieniać treść oryginalną - polską czy angielską - bez zastanawiania się, ile tłumaczeń trzeba ruszać.
I po drugie chodzi o wieloznaczności. W języku np. polskim wiele słów może oznaczać jedno w angielskim.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
05.11.2018 22:43

34 z 40: pajper

Najprostszy przykład:
Kiedy mamy wersję polską, zależnie od płci ustawionej w profilu, komunikat to "otrzymałeś nową wiadomość" lub "otrzymałaś nową wiadomość".
Po angielsku jest to ta sama fraza "You've received a new message".
Przy podejściu do tłumaczeń znanego z NVDA niemożliwe byłoby takie spersonalizowanie informacji.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
05.11.2018 22:44

35 z 40: grzezlo

Z ruszaniem tłumaczenia nie ma tragedii, bo zmieniając jedno czy dwa słowa w dłuższym komunikacie, ulepszając go w ten sposób, powodujemy, że się pojawi jako fuzzy i załatwia to gettext. Więc pozostaje korekta takiego niepewnego łańcucha.
A co do słów oznaczających to samo w różnym kontekście, to przecież właśnie po to jest msgctx w Gettext.


05.11.2018 22:47

36 z 40: pajper

Istnieje wiele sposobów podejścia do Gettextu i każdy woli swoje.
Niektórzy preferują tłumaczenie frazowe, ja kluczowe, bo jest dla mnie elastyczniejsze po prostu.
Plus nie ryzykujemy wieloznaczności.
Bo msgctx sprawdzi się tylko i wyłącznie wtedy, gdy ja jako autor jestem świadom wieloznaczności, a nie znam przecież każdego jednego języka.
Pamiętam, że przykłąd tego mieliśmy w Klango, zarówno lista użytkowników zbanowanych, jak i informacja przy użytkowniku zbanowanym to "użytkownicy zbanowani".
Dlaczego? Bo fraza msgid brzmiała po prostu "banned".
Dlatego ja zawsze przychylałem się do konceptu msgid jako tzw. structurized keys.
Nie wykluczam, że nawyk stąd pochodzi, iż głównie z takimi projektami pracowałem.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
05.11.2018 22:50

37 z 40: grzezlo

Programiści mają swój świat, a tłumacze swój. Elastyczność owszem, czemu nie, ale jednak tłumaczom to rozwiązanie utrudnia, nie ułatwia życia. Chyba żeby napisać jakiś kolektor tych komunikatów, pewnie jako moduł samego Eltena, że na tym samym kluczu byłyby powiązane komunikaty w różnych językach, no i wtedy taki plusik, że każdy mógłby tłumaczyć z dowolnego języka na dowolny.

05.11.2018 22:55

38 z 40: pajper

Już o tym całkiem poważnie myślałem i nie wykluczam, ale najpierw niech te tłumaczenia w ogóle zadziałają, a więc prędzej Elten 2.3 Beta 2, która nadciąga wielkimi krokami.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
05.11.2018 22:56

39 z 40: Julitka

Tutaj muszę faktycznie przyznać, że rozwiązanie zastosowane przez Dawida jest dość niewygodne dla tłumacza. Jeden fałszywy krok i właściwie nie wiesz, co masz przetłumaczyć...
***Niezależnie od tego, czy zbudujesz swój dom na piasku czy na skale, przyjdzie burza.
06.11.2018 08:31

40 z 40: dorkakrac

To prawda, 2 różne światy. :-D Tylko musimy pamiętać o tym, ż dopóki powstają programy o mniej lub bardziej globalnym zasięgu, te 2 światy muszą ze sobą współpracować i wypracowywać rozwiązania możliwie wygodne zarówno dla programistów, jak i dla tłumaczy. (grzezlo):
Programiści mają swój świat, a tłumacze swój. Elastyczność owszem, czemu nie, ale jednak tłumaczom to rozwiązanie utrudnia, nie ułatwia życia. Chyba żeby napisać jakiś kolektor tych komunikatów, pewnie jako moduł samego Eltena, że na tym samym kluczu byłyby powiązane komunikaty w różnych językach, no i wtedy taki plusik, że każdy mógłby tłumaczyć z dowolnego języka na dowolny.

--Koniec cytatu

"Dziś robota nie jest w cenie, dzisiaj liczy się myślenie."
10.11.2018 19:16

Wróć do listy wątków

2 z 2

Poprzednia

Nawigacja


Copyright (©) 2014-2024, Dawid Pieper