| Pages in topic: [1 2] > | Dopuszczony i nie dopuszczalny Thread poster: Andrzej Mierzejewski
|
|---|
Adobe Reader X, wersja 10.1.6.
Zabezpieczenia dokumentu:
Drukowanie: Dopuszczone
Zestaw dokumentów: Nie dopuszczalny
Komentowanie zawartości...: Dopuszczone
Wydzielanie stron: Nie dopuszczalny
Komentowanie: Dopuszczone
Wypełnianie pól formularza: Dopuszczone
Podpisywanie: Nie dopuszczalny
Tworzenie stron szablonowych: Nie dopuszczalny
Patrzę i jestem zdziwiony.
O ile pamiętam, w starszych programach, np... See more Adobe Reader X, wersja 10.1.6.
Zabezpieczenia dokumentu:
Drukowanie: Dopuszczone
Zestaw dokumentów: Nie dopuszczalny
Komentowanie zawartości...: Dopuszczone
Wydzielanie stron: Nie dopuszczalny
Komentowanie: Dopuszczone
Wypełnianie pól formularza: Dopuszczone
Podpisywanie: Nie dopuszczalny
Tworzenie stron szablonowych: Nie dopuszczalny
Patrzę i jestem zdziwiony.
O ile pamiętam, w starszych programach, np. Adobe Acrobat Reader, w tym miejscu stosowano przymiotniki "dozwolone" i "zabronione" - w rodzaju nijakim, który bardzo dobrze pasował do kontekstu.
Zdaje się, że ktoś wpadł na pomysł ulepszenia, a może nawet zmodernizowania tych przymiotników. Efektem jest bzdura z błędami, bo:
1. "Nie" z przymiotnikiem w stopniu równym pisze się razem, więc dlaczego tutaj jest oddzielnie? Internetowy SJP nie zna hasła "nie dopuszczalny", natomiast istnieje wyraz "niedopuszczalny" = «taki, którego nie można tolerować».
2. Internetowy SJP podaje takie znaczenia czasownika "dopuszczać":
dopuścić — dopuszczać
1. «pozwolić zbliżyć się do kogoś lub czegoś»
2. «przystać na coś, nie przeszkodzić czemuś»
3. «uznać coś za możliwe»
(W SJP nie istnieje hasło "dopuszczony").
3. Jeżeli jakaś czynność jest "dopuszczona", to jest tolerowana, wiąże się z ograniczeniami, warunkami, analogicznie do "dopuszczenia do egzaminu". W przeciwieństwie do "dopuszczonego", przymiotnik "dozwolony" wyraża zgodę bez warunków.
3. Dlaczego rodzaj męski, gdy do opisu czynności (komentowanie, wydzielanie, kopiowanie, wypełnianie, itd.) pasuje rodzaj nijaki? Obawiam się, że Google Translate już rządzi.
Nie jestem polonistą, więc nie mam pewności, czy nie przyczepiam się bez powodu - bo kolokacja, korpus, itp., itd.
Jakie są Wasze opinie? ▲ Collapse
| | | | Adam Podstawczynski (X) 
Local time: 02:51
Polish to English
+ ...
Pewie że tak, to są oczywiste błędy.
Błąd tłumacza widzę jeden: "Nie dopuszczalny" -> "Nieopuszczalny".
Pozostałe problemy z tym kawałkeim wynikają stąd, że tłumacze pracowali bez kontekstu. Mieli listę stringów do przetłumaczenia, bez kontekstu, zapewne nawet w złej kolejności. Ewentualnie mieli do dyspozycji jakiś komentarz programisty, który często jest totalnie niezrozumiały. Ewentualnie ścieżkę stringu lub nazwę pliku, w którym string wy... See more Pewie że tak, to są oczywiste błędy.
Błąd tłumacza widzę jeden: "Nie dopuszczalny" -> "Nieopuszczalny".
Pozostałe problemy z tym kawałkeim wynikają stąd, że tłumacze pracowali bez kontekstu. Mieli listę stringów do przetłumaczenia, bez kontekstu, zapewne nawet w złej kolejności. Ewentualnie mieli do dyspozycji jakiś komentarz programisty, który często jest totalnie niezrozumiały. Ewentualnie ścieżkę stringu lub nazwę pliku, w którym string wystąpił -- informacje równie mało pomocne.
Dlatego uznałbym je za błędy na etapie QA, nie na etapie tłumaczenia. ▲ Collapse
| | | | | Błędy są oczywiste | Apr 29, 2013 |
Adam, to, że tłumacze pracowali "bez kontekstu" to nie jest wytłumaczenie w tym przypadku, bo przecież wcześniejsze wersje Adobe Readera były przetłumaczone poprawnie, a nie sądzę, by tłumacze nie wiedzieli, że tłumaczą ten program. W tym przypadku zawiodła współpraca ludzi "na całej linii". Pewnie odbywało się to na zasadzie "termin goni, więc nieważne jak, byle było terminowo zrobione".
| | | | Adam Podstawczynski (X)
Local time: 02:51
Polish to English
+ ...
| Niekoniecznie | Apr 29, 2013 |
Przy dużych projektach lokalizacyjnych to, że coś było już przetłumaczone prawidłowo, nie znaczy, że do następnej wersji zostaną podstawione te same przetłumaczone stringi. Nawet jeśli z perspektywy użytkownika wydają się identyczne. Często po zmianach w UI zmienia się też "string ID" i taki tekst jest traktowany jako nowy; w związku z tym może zostać podstawiony z zupełnie innego źródła -- choć użytkownik zobaczy go w aplikacji w tym samym miejscu co ostatnio.
<... See more Przy dużych projektach lokalizacyjnych to, że coś było już przetłumaczone prawidłowo, nie znaczy, że do następnej wersji zostaną podstawione te same przetłumaczone stringi. Nawet jeśli z perspektywy użytkownika wydają się identyczne. Często po zmianach w UI zmienia się też "string ID" i taki tekst jest traktowany jako nowy; w związku z tym może zostać podstawiony z zupełnie innego źródła -- choć użytkownik zobaczy go w aplikacji w tym samym miejscu co ostatnio.
Każda nowa wersja oprogramowania powinna na nowo przechodzić etap LQA.
Dalej: tak, zdarza się, że tłumacz nie wie, jaki program tłumaczy -- albo jest mu trudno do tego dojść. Nie powinno tak być, ale tak bywa.
I jeszcze: w oryginale powyższego jest "Allowed" i "Not Allowed". Nie zdziwiłbym się, gdyby "Not Allowed" było faktycznie złożone z dwóch stringów, "Not" i "Allowed". To wyeliminowałoby nam wspomniany błąd tłumacza .
Wreszcie: stringi "Allowed" i "Not Allowed" nie muszą pochodzić z Adobe Readera. Mogą pochodzić z biblioteki wspólnej dla wszystkich programów Adobe.
Tak czy siak, widzę tu brak etapu LQA lub niechlujne jego przeprowadzenie. ▲ Collapse
| | |
|
|
|
| Wszystko naraz | Apr 29, 2013 |
Po prostu kapitalizm w akcji. Wystąpiły wszystkie lub niektóre z poniższych sytuacji:
Programista zrobił składak z dwóch słów. Być może nikt mu nie wyjaśnił pułapek lokalizacji albo kazano mu zminimalizować ilość tekstu idącą do przetłumaczenia.
Tłumacz się pospieszył albo był niedoświadczony -- napisał po polskawemu.
Testu UI nie było, został odwalony na szybko albo nie objął pewnych elementów.
Poprawienie błęd... See more Po prostu kapitalizm w akcji. Wystąpiły wszystkie lub niektóre z poniższych sytuacji:
Programista zrobił składak z dwóch słów. Być może nikt mu nie wyjaśnił pułapek lokalizacji albo kazano mu zminimalizować ilość tekstu idącą do przetłumaczenia.
Tłumacz się pospieszył albo był niedoświadczony -- napisał po polskawemu.
Testu UI nie było, został odwalony na szybko albo nie objął pewnych elementów.
Poprawienie błędu wymagało nakładu pracy większego niż użycie Ctrl+H lub odpowiednika, więc zostało odłożone do nieokreślonej przyszłej wersji. ▲ Collapse
| | | |
... zgłoszenie błędu do Adobe.
| | | | | Trochę zabawy z kodem | Apr 29, 2013 |
Adam Podstawczynski wrote:
Wreszcie: stringi "Allowed" i "Not Allowed" nie muszą pochodzić z Adobe Readera. Mogą pochodzić z biblioteki wspólnej dla wszystkich programów Adobe.
Tak czy siak, widzę tu brak etapu LQA lub niechlujne jego przeprowadzenie.
Gdyby w angielskiej wersji "not" szło z biblioteki, to byłoby sporo zabawy z uzdatnianiem kodu źródłowego do wersji polskiej. Nic by nie dało QA, trzeba byłoby to wysłać do programistów, żeby tam wprowadzili trochę operacji na stringach.
| | | | | Tzw. postęp... | Apr 29, 2013 |
Adam Podstawczynski wrote:
Przy dużych projektach lokalizacyjnych to, że coś było już przetłumaczone prawidłowo, nie znaczy, że do następnej wersji zostaną podstawione te same przetłumaczone stringi.
Myślę, że to "przy dużych" jest tutaj kluczowe.
Tzn. tak naprawdę nikt nad tym nie panuje, a nawet często tłumacz dostaje w tyłek za to, że myśli kontekstowo, bo jest "niespójny".
Lepiej to konformistycznie olać, niż się tłumaczyć.
Nawet jeśli z perspektywy użytkownika wydają się identyczne.
Kto myśli o perspektywie użytkownika?
Mnie niby takie jedne Japońce podsyłają zrzuty ekranu do absolutnie każdego stringu z UI, ale oni są absolutnym wyjątkiem.
I tych stringów nie jest dużo.
Takie podejście przy standardowym dużym projekcie jest de facto niewykonalne w perspektywie cięcia kosztów, więc bardzo dużo rzeczy idzie na zasadzie "shit in, shit out".
Już nawet jako juzer na to nie zwracam bardzo uwagi, zwłaszcza jak się śpieszę.
Po prostu kolejny standardowy knot.
Np. ostatnio przy czymś się mocno turlałem z powodu MS Office, ale naprawdę nie pamiętam...
Wystarczy przejść przez kilka podstawowych okien i coś znajdziecie.
Często po zmianach w UI zmienia się też "string ID" i taki tekst jest traktowany jako nowy; w związku z tym może zostać podstawiony z zupełnie innego źródła -- choć użytkownik zobaczy go w aplikacji w tym samym miejscu co ostatnio.
Tego już chyba nikt nie kontroluje.
Po prostu środowiska programistyczne stają się coraz bardziej rozproszkowane i coraz mniej w nich struktury i wizji ogólnej.
Każda nowa wersja oprogramowania powinna na nowo przechodzić etap LQA.
Kpisz chyba.
Takie "niepotrzebne" koszty?
Cały "translation ecosystem", o którym np. bredzi(ł) SDL polega na tym, żeby ten etap pominąć...
Dalej: tak, zdarza się, że tłumacz nie wie, jaki program tłumaczy -- albo jest mu trudno do tego dojść. Nie powinno tak być, ale tak bywa.
Nawet jak wie, to czasem ni w cholerę się nie zorientuje, jaki jest kontekst.
Jeśli porządne przetłumaczenie dwóch słów wymaga minuty, to łatwiej piernicznąć difolt.
Tłumaczenie "porządnie" jest totalnie nieopłacalne przy obecnym sposobie kształtowania cen "od słowa".
I jeszcze: w oryginale powyższego jest "Allowed" i "Not Allowed". Nie zdziwiłbym się, gdyby "Not Allowed" było faktycznie złożone z dwóch stringów, "Not" i "Allowed". To wyeliminowałoby nam wspomniany błąd tłumacza .
Jaaaa.
Składanie stringów to jest chyba jedna z pierwszych lekcji programowania, nie wiem jaki debil to wymyślił, bo to nieodwracalnie skrzywia większość programistów.
Albo tzw. optymalizacja stringów.
Od początku roku miałem kilka sporych projektów, w których np. każda zmienna była wyrzucona poza segment, żeby się te "standardowe" kawałki między zmiennymi mogły powtarzać, żeby zbić koszty.
Od razu zgłaszałem, że to kretyństwo, ale klient wiedział lepiej.
To mają, czego chcieli.
(...)
Tak czy siak, widzę tu brak etapu LQA lub niechlujne jego przeprowadzenie.
Dla mnie to nie jest etap QA, tylko rozsądne przygotowanie tłumaczenia.
A ten etap niknie.
Zresztą tzw. "ewolucja" języków programowania to przyśpiesza.
Jak porównuję np. C/C++ z C# tj. z .Net, to degradacja środowiska dla tłumacza jest porażająca.
Gdyby nie lata doświadczenia, to bym chyba nie wiedział, jak może wyglądać to, co tłumaczę.
Zdrówkot
GG
| | |
|
|
|
| Reakcja Adobe | Apr 29, 2013 |
Zdrówkot, ciekawe, czy Adobe odpowie Andrzejowi
| | | |
Lucyna Długołęcka wrote: Zdrówkot, ciekawe, czy Adobe odpowie Andrzejowi
Andrzej jest prawdopodobnie zbyt kulturalny i go oleją.
Lepiej byłoby zrobić głośną akcję, że proces tłumaczeń dla Adobe robią jakieś głupie fiuty.
Tzn. nie atakujesz bezpośrednio tłumaczy, bo oni są w tym wg mnie najmniej winni, tylko brutalnie walisz w korporację.
Jeśli im na czymkolwiek zależy, to oprócz kasy jest to PR.
Sprawdzone.
Działa.
Ale ktoś musi zagrać chama, żeby zauważyli.
Zdrówkot
GG
| | | | Adam Podstawczynski (X)
Local time: 02:51
Polish to English
+ ...
| Zależy od kasy i chęci - da się | Apr 29, 2013 |
Grzegorz Gryc wrote: Każda nowa wersja oprogramowania powinna na nowo przechodzić etap LQA. Kpisz chyba. Takie "niepotrzebne" koszty? Cały "translation ecosystem", o którym np. bredzi(ł) SDL polega na tym, żeby ten etap pominąć...
Są firmy, które to robią. Dowolny minor update => pełne LQA przynajmniej zmodyfikowanych okienek.
Tak, to kosztuje, ale mówimy o sytuacji idealnej.
Zresztą Adobe do biednych nie należy.
| | | | Adam Podstawczynski (X)
Local time: 02:51
Polish to English
+ ...
Grzegorz Gryc wrote: Lucyna Długołęcka wrote: Zdrówkot, ciekawe, czy Adobe odpowie Andrzejowi Andrzej jest prawdopodobnie zbyt kulturalny i go oleją. Lepiej byłoby zrobić głośną akcję, że proces tłumaczeń dla Adobe robią jakieś głupie fiuty. Tzn. nie atakujesz bezpośrednio tłumaczy, bo oni są w tym wg mnie najmniej winni, tylko brutalnie walisz w korporację. Jeśli im na czymkolwiek zależy, to oprócz kasy jest to PR. Sprawdzone. Działa. Ale ktoś musi zagrać chama, żeby zauważyli.
Procesu tłumaczeń dla Adobe nie robią głupie fiuty
Problem w tym, że Adobe nie wszystko wrzuca na LQA.
Źle przydzielony budżet.
| | |
|
|
|
| Zależy, jak kto rozumie... | Apr 29, 2013 |
Grzegorz Gryc wrote: Lucyna Długołęcka wrote: Zdrówkot, ciekawe, czy Adobe odpowie Andrzejowi Andrzej jest prawdopodobnie zbyt kulturalny i go oleją.
Tzn. nie chodzi o to, że Andrzej jest prawdopodobnie kulturalny w ogóle, bo tu nie mam wątpliwości, że jest, tylko że jest zbyt kulturalny dla korporacji, więc go prawdopodobnie oleją, bo nie wygląda na to, żeby mógł zrobić globalne bydło...
Zdrówkot
GG
| | | |
(...)
Adam Podstawczynski wrote: Procesu tłumaczeń dla Adobe nie robią głupie fiuty Problem w tym, że Adobe nie wszystko wrzuca na LQA. Źle przydzielony budżet.
Dobra.
To w takm razie menydżment to głupie fiuty.
Lepiej?
Zdrówkot
GG
| | | | | Kwestia podejścia... skala... | Apr 29, 2013 |
Adam Podstawczynski wrote: Grzegorz Gryc wrote: Każda nowa wersja oprogramowania powinna na nowo przechodzić etap LQA. Kpisz chyba. Takie "niepotrzebne" koszty? Cały "translation ecosystem", o którym np. bredzi(ł) SDL polega na tym, żeby ten etap pominąć... Są firmy, które to robią. Dowolny minor update => pełne LQA przynajmniej zmodyfikowanych okienek. Tak, to kosztuje, ale mówimy o sytuacji idealnej.
Moje Japońce tak zwykle robią.
Nie zawsze, ale i tak robią rzeczy zwykle niemożliwe tj. przynajmniej opisują stringi.
Wszystkie.
To im musi godziny zajmować.
Rekord to prawie pół strony wyjaśnień do dosłownie 2 słów.
Ale oni mają tego naprawdę niedużo i trudno to porównać np. do takiego Fotoszopa.
Swoją drogą, zawsze się uśmiecham, jak dostaję tę robotę, bo dla tego biura zawsze robiłem tylko FR-PL, a EN-PL dostałem kiedyś przez pomyłkę i tak zostało...
Zdrówkot
GG
| | | | | Pages in topic: [1 2] > | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Dopuszczony i nie dopuszczalny | Protemos translation business management system | Create your account in minutes, and start working! 3-month trial for agencies, and free for freelancers!
The system lets you keep client/vendor database, with contacts and rates, manage projects and assign jobs to vendors, issue invoices, track payments, store and manage project files, generate business reports on turnover profit per client/manager etc.
More info » |
| | TM-Town | Manage your TMs and Terms ... and boost your translation business
Are you ready for something fresh in the industry? TM-Town is a unique new site for you -- the freelance translator -- to store, manage and share translation memories (TMs) and glossaries...and potentially meet new clients on the basis of your prior work.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
