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

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ę.

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. .

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.

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.

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.

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.

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.

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.

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.