Czy rozwijasz się z myślą o lokalizacji?

13

Czy pracując nad projektem oprogramowania lub stroną internetową, rozwijasz się z myślą o lokalizacji?

Rozumiem przez to np

  • Eksternalizacja wszystkich ciągów, w tym komunikatów o błędach.
  • Nieużywanie obrazów zawierających tekst.
  • Projektowanie interfejsu użytkownika z myślą o rozszerzaniu tekstu.
  • Korzystanie z pseudo-tłumaczenia w celu przetestowania interfejsu użytkownika na wczesnym etapie procesu.
  • itp.

Czy w przypadku projektów, nad którymi pracujesz, są one w kategorii „miło mieć” i pozwalają zespołowi lokalizacyjnemu martwić się resztą, czy też masz gotowość do lokalizacji wbudowaną w proces rozwoju? Chciałbym usłyszeć, jak programiści ogólnie postrzegają lokalizację.

Jimmy Collins
źródło
3
L10N-> lokalizacja ... zastosujmy tutaj poprawny angielski, prawda?
Gawron
11
@Rook - Jest to popularny skrót branżowy i jest zawarty w „The American Heritage® Abbreviations Dictionary” - dlatego chciałbym usłyszeć twoją definicję „właściwego języka angielskiego” (zwróć uwagę na wielkie litery „angielski” :-)).
Jimmy Collins,
5
@Rook I jest też przeliterowana Lokalizacja;)
Rowland Shaw
2
@ Jimmy C - Nie u Blacka, nie u Longmana, nie u Oksfordu, nie u Merriana ... (i wierzcie lub nie, z trudem sprawdziłem je wszystkie, żeby się upewnić). Ale, rzecz jasna, jest po prostu brzydki i nie przypomina słowa (nie jestem pewien w tym, ale jestem dość silny, że słowa nie mają liczb).
Wieża
4
@Rook: Jest to skrót liczbowy. To samo i18n dla „internacjonalizacji” i g11n dla „globalizacji”. Czy są brzydcy? Może, może nie. Faktem jest, że są one w powszechnym użyciu.
Andy

Odpowiedzi:

9

Pracuję dla dużej firmy z listy Fortune 500 i zawsze zaczynamy od lokalizacji. Nasze projekty są zwykle tylko dla USA, ale zbyt wiele razy na przestrzeni lat, napiszemy aplikację dla klienta, a potem ktoś inny ją zobaczy i powie „hej, to byłoby świetne dopasowanie do kraju X”. Następnie wiesz, że przechodzisz przez kod dodający lokalizację. Naprawdę nie zajmuje to więcej czasu, aby zbudować aplikację od samego początku, więc po prostu to robimy. Dodatkową korzyścią jest to, że kiedy klient przychodzi do nas i prosi o włączenie aplikacji (wybierz język), wręczamy mu plik i mówimy, aby go przetłumaczył (wybierz język) i gotowe. .

Walter
źródło
Prawdziwe. Ale nie w przypadku osobistych projektów. Tylko angielski.
6

Myślę, że to było ważne 10 lat temu. Najnowsza technologia rozwiązała problem .

Mieszkam w kraju, w którym są 3 języki narodowe , a tylko jeden z nich jest mniejszością.

Aby zrozumieć problemy, które mogą wystąpić z tego powodu, to tak, jakby zachodnia część USA mówiła (bardzo) innym językiem niż wschodnia część. Pomyśl, że w środku kraju populacja jest nieco scalona, ​​dlatego musisz używać obu języków wszędzie.

Posiadanie 4 języków w aplikacjach komputerowych i witrynach było i nadal jest bardzo powszechne (3 języki narodowe + angielski). Czasami jest to obowiązek.

Miałem świadomość lokalizacji, ponieważ uwarunkowało mnie moje środowisko. Tak, kilka lat temu martwiłem się o to.

Teraz nie dbam o lokalizację, ponieważ najnowsze narzędzia IDE pozwalają bardzo łatwo przekonwertować dowolną aplikację statyczną na w pełni zlokalizowaną.

Narzędzia, których używam z Visual Studio .NET:

  • CodeRush , wtyczka Visual Studio, która pozwala przenosić na stałe zakodowane teksty do plików zasobów.
  • Easy Localizer , wyodrębnij etykiety w pliku Excel, w którym dodajesz cały dodatkowy język, a następnie scal ponownie pliki zasobów.

źródło
4
Naprawdę? które narzędzia na to pozwalają?
David Weiser
A co z tekstem na obrazach i używaniem ciągów takich jak (na przykład) „Twoja szkoła średnia” w formach, które mogą nie być zrozumiane w niektórych lokalizacjach? Deweloper wciąż musi zdawać sobie sprawę z różnic kulturowych.
Jimmy Collins,
W Visual Studio korzystam z narzędzia DevExpress o nazwie CodeRush. Jest też inne narzędzie, którego używam do tłumaczenia całej aplikacji naraz: Easy Localizer: foss.kharkov.ua/products/easy_localizer/index.htm (dodam je w celach informacyjnych w mojej odpowiedzi)
4
dobre narzędzia, ale to coś więcej - na przykład układy ekranu mogą wymagać zmiany z powodu różnych długości etykiet; wartości wyszukiwania w bazie danych będą musiały zostać przetłumaczone; itp.
Steven A. Lowe,
@Steven & JimmyC: tutaj nie ma srebrnych kul. Po prostu dobre narzędzia, które usuwają najwięcej problemów. Zwróć uwagę, że zauważyłem pewien wzorzec z latami pracy nad zlokalizowanymi aplikacjami: Nie możesz z góry wiedzieć, jak duży rozmiar dane słowo lub zdanie przyjmie w nieznanych językach. Uwierz mi, że mogą mieć bardzo różne rozmiary. Podczas testów dostosowujesz swoje interfejsy i układy.
4

Większość moich klientów wymaga tylko jednego języka i faktycznie określa ten język. Dlatego nie tracimy czasu na lokalizację aplikacji. Nie oznacza to jednak, że możemy całkowicie ignorować inne języki. Trzymamy się więc podstaw:

  • Używaj Unicode wszędzie. Jest 2k10, nie ma wymówki, żeby tego nie robić.
  • Projektuj, aby uzyskać pewną elastyczność w układzie. Nawet w całym języku angielskim różne czcionki mają bardzo różne ślady ekranu w tym samym rozmiarze w punktach.
  • Zachowaj funkcje aplikacji / modelowanie danych poza warstwą widoku

Osobiście, gdy potencjalny język lokalizacji różni się zasadniczo od języka, w którym została zaprojektowana aplikacja, dzieje się o wiele więcej niż zwykły wybór tekstu. Podczas gdy zamiana tekstu pomaga i pozwoli firmie uzyskać „szybką i brudną” implementację w nowej lokalizacji stosunkowo wcześniej - nie rozwiązuje ona podstawowych różnic w sposobie myślenia użytkowników w innym języku.

Uczyłem się japońskiego i chociaż mogę uważać się za początkującego w tym języku, wiem wystarczająco dużo, że istnieją pewne koncepcje, dla których nie ma bezpośredniego tłumaczenia. Istnieją różne pomysły na to, co czyni coś użytecznym. Podczas gdy duże główne koncepcje mogą być podobne, to szczegóły naprawdę wpływają na użytkowników.

Aby naprawdę zaspokoić potrzeby zupełnie innej kultury, potrzebujesz zupełnie nowego oblicza swojej aplikacji. Dlatego separacja Model / Widok / Kontroler staje się jeszcze ważniejsza. Tak długo, jak aplikacja działa w ten sam sposób, część widoku można całkowicie wymienić. Kiedy tak się dzieje, ktoś planuje zapłacić prawdziwe pieniądze, aby właściwie rozwiązać problem.

Berin Loritsch
źródło
+1 za trzymanie się podstaw i swoje zdanie na temat Unicode. Ponadto masz rację, mówiąc, że „dzieje się o wiele więcej niż zwykły wybór tekstu”. Jest to szczególnie prawdziwe podczas lokalizowania aplikacji dla języków pisanych od prawej do lewej (takich jak arabski lub hebrajski), w których cały interfejs użytkownika musi być dublowany.
Jimmy Collins,
Z punktu widzenia użyteczności po prostu dublowanie interfejsu użytkownika może nie być najlepszą opcją. Być może trzeba będzie zmienić kolejność niektórych elementów, aby zachować zgodność z lokalnymi konwencjami i zmniejszyć krzywą uczenia się dla użytkowników. Poważne projekty dotyczące internacjonalizacji / lokalizacji muszą uwzględniać wpływ na użytkowników w tym regionie. Jeśli nie, aplikacja po prostu nie otrzyma przyjęcia, na które liczyli marketerzy.
Berin Loritsch,
3

Zrobiliśmy to w razie potrzeby: wszystko, co dotyczy klienta, zostało teraz zrobione z myślą o i18n, ponieważ rozszerzyliśmy nasze rynki, a niektóre rzeczy wewnętrzne są teraz przystosowane do i18n, więc pracownicy, którzy używają tego, nie muszą mówić po angielsku.

Zrobiliśmy to w razie potrzeby, jako startup.

David Thornley
źródło
2

Brzmi, że ludzie podejmują wysiłki na poziomie 10 lżej. Zwłaszcza w przypadku używania języka angielskiego jako języka oryginalnego łatwo jest zignorować fakt, że inne języki zwykle wymagają nawet 30–40% więcej miejsca na tekst. Wymaga to od tłumaczy korzystania ze skrótów, które nie są tak łatwe do zrozumienia, co oczywiście jest niekorzystne dla wygody użytkownika.

petteri
źródło
1

Zazwyczaj internacjonalizację dodaję później, gdy jej potrzebuję, nawet jeśli od początku wiem, że będę jej potrzebować. W przypadku języków, których używam, nie jest to trudne do zrobienia w osobnej fazie i mogę powstrzymać jeden nieporęczny aspekt od wczesnych faz konstrukcyjnych.

użytkownik 281377
źródło
2
Nie jestem pewien, czy jest to najlepsze podejście - co zrobić, jeśli otrzymasz prośby o niektóre języki, które mogą być kłopotliwe, może niektóre języki dwubajtowe, takie jak japoński, koreański itp.?
Jimmy Collins,
1
Jimmy C: Obecnie dla tego rodzaju projektu, nad którym pracuję, wsparcie dla języków europejskich, takich jak angielski, niemiecki, francuski, hiszpański, polski itp. Jest wystarczające. Po prostu nie wiem wystarczająco dużo o języku japońskim i innych „kłopotliwych” językach (np. Pisanie wskazówek itp.), Aby wykonać wszystkie niezbędne przygotowania w oprogramowaniu; i nie ma sensu wydawać dużej ilości czasu i pieniędzy na coś, co prawdopodobnie nigdy się nie wydarzy. BTW, podwójny bajt nie jest naszym problemem, wszędzie używamy Unicode: D
user281377
Wydaje mi się, że ten scenariusz ma sens.
Jimmy Collins,
Naprawdę nie musisz dużo wiedzieć o języku arabskim i japońskim, aby przygotować się do internacjonalizacji. Istnieją ogólne wytyczne, które zazwyczaj są wystarczająco dobre. Jeśli obsługujesz wiele języków europejskich i używasz Unicode, prawdopodobnie jesteś w większości przypadków.
David Thornley,
1

Piszę aplikacje na Androida, a lokalizacja jest dość prosta przy użyciu plików ciągów w stylu Java. Prawie zero wysiłku na rzecz pełnej internacjonalizacji we wszystkich językach Androida.

Chłopak
źródło
To prawda, że ​​nowsze technologie platform zostały zaprojektowane z myślą o lokalizacji. Z mojego doświadczenia z iOS jest to dość prosta procedura, aby zlokalizować tego rodzaju aplikacje.
Jimmy Collins,
1

Odpowiedź: Tak Chociaż w środowisku, w którym pracuję (Python / Zope / Plone) bardzo łatwo jest później zlokalizować ciągi, więc pomijam to, jeśli nie jest to wymagane od samego początku.

Ale przechowuję tekst w obiektach Unicode itp.

Więc tak. Upewniam się, że moje aplikacje są dość łatwe do zlokalizowania, a nawet jeśli nie zostaną zlokalizowane, będą działać w środowisku międzynarodowym. Nieprzestrzeganie tego jest błędem, ponieważ potrzebny wysiłek jest niewielki, a korzyści ogromne.

Lennart Regebro
źródło