This is a static archive of a poll.

Koszyk na zakupy
0% (0 głosów)

Zamówienie
6% (1 głos)

Inne
6% (1 głos)

Koszyk
88% (14 głosów)

Razem głosów: 16

Groups audience: 

Comments

Na pierwszy rzut oka tłumaczenie oczywiste, ale jak się przyjrzeć całości sklepu i występującym w nim tłumaczeniom, to tłumaczenie "shopping cart" jako "zamówienie" nabiera sensu. Przykładowe zwroty: "Add to cart" -> "Dodaj do zamówienia", "Checkout" -> "Realizacja zamówienia".

proponuję tam gdzie da, cart przetłumaczyć jako koszyk. jest to standard w polskich sklepach, moim zdaniem nie ma co komplikować interface jako "koszyk na zakupy". w głosowaniu daję "inne"

Poprzez "zamówienie" celowałbym w całą grupę usług płatnych gdzie flow jest odmienny od sklepu internetowego, i w takim wypadku kupowanie poprzez "koszyk" wydaje się co najmniej dziwne. Przykład: W zeszłym roku robiłem na stronie konta premium z użyciem ubercarta, faktycznie wyglądało to tak że do koszyka trafiał jeden produkt który był usługą. Wyglądało to nie naturalnie. W Drupal Commerce istnieje spora dowolność w modyfikacji tego przepływu i integracji z rules(np. schowanie widoku koszyka i przechodzenie odrazu dalej). Właśnie dla takich zastosowań tłumaczenie jako "zamówienie" ma dużo sensu, a wcale nie psuje interfejsu w przypadku sklepu.

Chcesz rozwiązać problem przypadku użycia przez tłumaczenie - nie tędy droga. Czy myślisz, że jak anglik czyta słowo cart to myśli zamówienie? Zamówienie to order. W procesach zakupowych na zachodzie, często pojawia się jeszcze requisition (zapotrzebowanie), które w Polsce występuje rzadko.

Zwracam uwagę, że te dwa ostatnie terminy są w języku angielskim ściśle powiązane z procesami księgowymi i zarządzaniem przedsiębiorstwem. W Polsce takie standardy się dopiero wprowadza - nazywanie carta orderem to bzdura.

Moje główne argumenty dlaczego "zamówienie", a nie "koszyk":
- nie tylko sklepy będą z niego korzystały
- pasuje do różnych przypadków użycia,
- spójne i zrozumiałe tłumaczenie

Przykłady jak tłumaczenie wygląda w użyciu:
http://telepizza.pl/
http://www.coreeditor.pl/
http://www.lampy-ogrodowe.pl/

Skomentuję Twoje przykłady:
- Telepizza - w domu zawsze mówię "zamówmy pizzę" i przez telefon też "zamawiam do domu" więc naturalne jest "zamówienie" a nie "dodaj do koszyka pizzę", tu się zgodzę,
- edytor - tu zamówienie to jest 1 strona, nie łażę po witrynie i nie wrzucam do koszyka tylko od razu składam zamówienie,
- lampy - tu ktoś po prostu tak zadecydował, ale nie uważam, żeby to było lepsze/popularniejsze od koszyka,

Sęk w tym, że typowy standardowy sklep internetowy ma koszyk (amazon, euro rtv agd, empik, merlin - jakoś mnie bardziej przekonują oni niż Twoje przypadki, w końcu ktoś tam projektował, testował to tłumaczenie czy symbolikę), nawet często ikonka jest z tym symbolem, po co dezorientować klienta albo skazywać 95% twórców stron na tłumaczenie zamówienia na koszyk? Przypadek podobny jak z biuletynem - jak zrobimy takie tłumaczenie to znajdą się chętni i zadowoleni, ale większość będzie poszkodowana, rozgoryczona itd. :)

Zresztą, skorzystajmy z Google i:
"dodaj do zamówienia" - prawie 4 miliony
"dodaj do koszyka" - prawie 4 miliony... i jeszcze 60 :)

PS. Sam rozważam cały czas wdrożenie na jednej ze swoich stron systemu płatności i pewnie nie będę "dodawał do koszyka" tylko "kupował abonament" albo "zamawiał dostęp premium", ale to jest raptem kilkanaście napisów do przerobienia.

Obecnie rozważam stworzenie dwóch tłumaczeń, koszyk jako domyślne, oraz "zamówienie" jako wersja do ręcznego upload'u. Ilość pracy dodatkowej stosunkowo niewielka, a rozwiązuje wszystkie problemy.

świetny pomysł, taki sam można by zastosować do innych spornych słówek, tylko potrzebny jeszcze jakiś centralny punkt, z którego pobierałoby się alternatywne paczki z kompletem napisów. Można wygospodarować miejsce na głównej stronie polskiego ldo z odnośnikiem do takiego centrum, co Wy na to?

W moim przypadku alternatywne tłumaczenie będzie na pewno dostępne w odpowiednim module.
Muszę jeszcze rozwiązać kwestię aktualizacji tłumaczeń w wersji alternatywnej.

Pomysł ogólnie dobry, z tym że będzie miał zastosowanie do modułów które podobnie jak tutaj mają kilka kontekstów użycia, no. calendar.

Jak zamawiasz pizzę, to ty składasz zamówienie - fizycznie Pan(i) przy telefonie, dodaje produkt do koszyka:D

A tak poza tym - no kurde, każdy sklep ma koszyk, każdy sklep ma panel zamówienia - czy dodając produkt do nomen-omen Koszyka, wchodząc w listę dodanych produktów jesteśmy na stronie zamówienia?:D

Otóż nie, bo zamówienie składamy po wyłożeniu produktów na ladę:P A do tej pory mamy koszyk w łapkach:P

"Dodaj do zamówienia" wcale nie oznacza, że dodany produkt zostanie w tym zamówieniu zakupiony. Czy jak idziesz do sklepu i włożysz coś do koszyka, to jesteś pewny że to kupisz? A może zamienisz na coś innego.
Nie trzymajmy się standardu zachodniego w polskich sklepach, bo klienci są ni mniej ni więcej przyzwyczajeni do pewnych zachowań.
"Shopping cart" to koszyk, "Checkout" to Realizacja zamówienia. I akurat tego standardu w naszym kraju powinniśmy się trzymać.
Kto tłumaczył nie raz Drupala i pewnie frazy, wie, że niektóre z nich są tłumaczone zbyt dosłownie, co w naszym języku potrafi wynieść na ekran niezły bełkot, którego Polak nie zrozumie.

Cart to cart. Nie zmieniałbym tego, polscy użytkownicy sklepów mają już swoje nawyki i przyzwyczajenia. Inne tłumaczenie niż koszyk może powodować zakłopotanie. Poza tym koszyk jak dla mnie jest niezobowiązujący, mogę przy nim majstrować - dodawać, usuwać, zmieniać, często jest używany w celu porównań przedmiotów, zapamiętywania ich. Zamówienie to coś poważniejszego, w zamówieniu już deklarujesz się, że przedmiot kupisz - podajesz swoje dane i realizujesz płatność. Przynajmniej ja tak to rozumiem.