Apakah Anda berkembang dengan mempertimbangkan lokalisasi?

13

Ketika bekerja pada proyek perangkat lunak atau situs web, apakah Anda mengembangkannya dengan mempertimbangkan lokalisasi?

Maksud saya ini misalnya

Eksternalisasi semua string, termasuk pesan kesalahan.
Tidak menggunakan gambar yang mengandung teks.
Mendesain UI Anda dengan mempertimbangkan teks.
Menggunakan pseudo-translation untuk menguji UI Anda di awal proses.
dll.

Pada proyek yang Anda kerjakan, apakah ini dalam kategori 'baik untuk dimiliki' dan biarkan tim lokalisasi mengkhawatirkan sisanya, atau apakah Anda memiliki kesiapan pelokalan dalam proses pengembangan Anda? Saya tertarik mendengar bagaimana pengembang melihat lokalisasi secara umum.

internationalization

— Jimmy Collins
sumber

3

L10N-> lokalisasi ... mari kita gunakan bahasa Inggris yang tepat di sini, oke?

— Benteng

11

@Rook - Ini adalah singkatan industri yang umum dan terdapat dalam 'The American Heritage® Abbreviations Dictionary' - jadi saya ingin mendengar definisi Anda tentang 'Bahasa Inggris yang baik' (perhatikan huruf besar 'Bahasa Inggris' :-)).

— Jimmy Collins

5

@ Benteng Dan itu dieja Lokalisasi juga;)

— Rowland Shaw

2

@ Jimmy C - Tidak di Black's, tidak di Longman, tidak di Oxford, tidak di Merrian ... (dan percaya atau tidak, saya kesulitan memeriksa semuanya hanya untuk memastikan). Tapi sejujurnya, itu hanya jelek dan tidak menyerupai kata (tidak yakin pada yang ini, tapi saya cukup kuat karena kata-kata itu tidak memiliki angka).

— Rook

4

@Rook: Ini adalah singkatan numeronim. Sama dengan i18n untuk "internasionalisasi" dan g11n untuk "globalisasi". Apakah mereka jelek? Mungkin tidak. Faktanya, mereka dalam penggunaan umum.

— Andy

9

Saya bekerja untuk perusahaan besar Fortune 500 dan kami selalu memulai dengan lokalisasi dalam pikiran. Proyek kami biasanya hanya untuk AS, tetapi terlalu sering selama bertahun-tahun, kami akan menulis aplikasi untuk klien dan kemudian orang lain akan melihatnya dan berkata "hei, itu akan sangat cocok untuk negara X". Kemudian hal berikutnya yang Anda tahu adalah Anda akan melalui penambahan kode pelokalan. Ini benar-benar tidak membutuhkan waktu lagi untuk membangun aplikasi dengan itu dari awal, jadi kita lakukan saja. Ditambah manfaat tambahan adalah bahwa ketika klien datang kepada kami dan meminta aplikasi mereka (pilih bahasa Anda), kami menyerahkan mereka file dan memberitahu mereka untuk menerjemahkannya (pilih bahasa Anda) dan kami selesai .

— Walter
sumber

Benar. Tetapi untuk proyek pribadi, saya tidak. Hanya bahasa Inggris.

6

Saya pikir itu penting 10 tahun yang lalu. Teknologi terbaru memecahkan masalah .

Saya tinggal di negara di mana ada 3 bahasa nasional , dan hanya satu dari mereka adalah minoritas.

Untuk memahami masalah yang bisa terjadi karena itu, itu seperti memiliki bagian barat AS berbicara bahasa (sangat) berbeda dari bagian timur. Pikirkan bahwa di pusat negara, populasi agak bergabung, jadi Anda harus menggunakan kedua bahasa di mana-mana.

Memiliki 4 bahasa di aplikasi desktop dan situs web adalah dan masih sangat umum (3 bahasa nasional + Inggris). Terkadang itu kewajiban.

Saya sadar akan lokalisasi karena saya telah dikondisikan oleh lingkungan saya. Jadi ya, beberapa tahun yang lalu, saya mengkhawatirkannya.

Sekarang saya tidak terlalu peduli dengan lokalisasi karena alat IDE terbaru memungkinkan Anda untuk mengubah aplikasi statis apa pun menjadi yang sepenuhnya dilokalkan dengan sangat mudah.

Alat yang saya gunakan dengan Visual Studio .NET:

CodeRush , sebuah plugin Visual Studio yang memungkinkan Anda untuk memindahkan teks kode keras ke file sumber daya.
Easy Localizer , ekstrak label dalam file Excel di mana Anda menambahkan semua bahasa tambahan, lalu gabungkan kembali dalam file sumber daya Anda.

4

Betulkah? alat apa yang memungkinkan ini?

— David Weiser

Bagaimana dengan hal-hal seperti teks dalam gambar, dan menggunakan string seperti (misalnya) 'SMA Anda' dalam bentuk yang mungkin tidak dipahami di lokal tertentu? Pengembang masih perlu menyadari perbedaan budaya.

— Jimmy Collins

Di Visual Studio, saya menggunakan alat dari DevExpress bernama CodeRush. Ada juga alat lain yang saya gunakan untuk menerjemahkan seluruh aplikasi sekaligus: Easy Localizer: foss.kharkov.ua/products/easy_localizer/index.htm (saya akan menambahkannya untuk referensi dalam jawaban saya)

4

alat yang bagus, tetapi ada lebih dari itu - tata letak layar, misalnya, mungkin harus berubah karena panjang label yang berbeda; nilai-nilai pencarian basis data perlu diterjemahkan; dll

— Steven A. Lowe

@ Seven & JimmyC: tidak ada peluru perak di sini. Hanya alat bagus yang menghilangkan sebagian besar kerumitan. Harap perhatikan bahwa saya perhatikan sebuah pola dengan bertahun-tahun bekerja pada aplikasi yang dilokalkan: Anda tidak bisa tahu sebelumnya berapa banyak ukuran kata atau kalimat yang diberikan dalam bahasa yang tidak Anda ketahui. Percayalah, mereka dapat memiliki ukuran yang sangat berbeda. Anda menyesuaikan antarmuka & tata letak Anda selama pengujian.

4

Sebagian besar klien saya hanya membutuhkan satu bahasa, dan pada kenyataannya menentukan satu bahasa. Karenanya, kami tidak menghabiskan waktu untuk melokalkan aplikasi. Namun, itu tidak berarti kita dapat sepenuhnya mengabaikan bahasa lain. Jadi kami tetap dengan dasar-dasarnya:

Gunakan Unicode di mana-mana. Ini 2k10, tidak ada alasan untuk tidak melakukannya.
Desain untuk beberapa elastisitas dalam tata letak. Bahkan dengan semua bahasa Inggris, font yang berbeda memiliki jejak layar yang sangat berbeda pada ukuran titik yang sama.
Jauhkan fungsi aplikasi / pemodelan data dari lapisan tampilan

Secara pribadi, ketika bahasa pelokalan potensial secara fundamental berbeda dari yang dirancang aplikasi di sana ada lebih banyak terjadi daripada pemilihan teks sederhana. Sementara penggantian teks membantu dan akan memungkinkan perusahaan untuk mendapatkan implementasi "cepat dan kotor" di lokasi baru secara komparatif sebelumnya - itu tidak menyelesaikan perbedaan mendasar dalam cara berpikir pengguna dalam bahasa lain.

Saya sudah belajar bahasa Jepang, dan walaupun saya hanya bisa menganggap diri saya pemula dalam bahasa itu, saya cukup tahu bahwa ada beberapa konsep yang tidak ada terjemahan langsungnya. Ada beberapa ide berbeda tentang apa yang membuat sesuatu bisa digunakan. Meskipun konsep besar utama mungkin serupa, detailnya yang benar-benar membuat perbedaan dengan pengguna.

Untuk benar-benar mengatasi kebutuhan budaya yang sangat berbeda, Anda membutuhkan wajah yang sama sekali baru untuk aplikasi Anda. Itu sebabnya pemisahan Model / View / Controller menjadi lebih penting. Selama aplikasi berfungsi dengan cara yang sama, bagian tampilan dapat sepenuhnya diganti. Ketika itu terjadi, seseorang berencana membayar sejumlah uang nyata untuk mengatasi masalah dengan benar.

— Berin Loritsch
sumber

+1 untuk tetap berpegang pada dasar-dasar dan poin Anda tentang Unicode. Juga, Anda membuat poin bagus tentang 'banyak hal yang terjadi daripada pemilihan teks yang sederhana'. Ini terutama benar ketika melokalisasi aplikasi untuk bahasa yang ditulis dari Kanan ke Kiri (seperti bahasa Arab atau Ibrani), di mana seluruh UI perlu dicerminkan.

— Jimmy Collins

Dari sudut pandang useability, hanya mirroring UI mungkin bukan pilihan terbaik. Anda mungkin harus memesan ulang beberapa elemen untuk mematuhi konvensi lokal dan mengurangi kurva belajar untuk pengguna Anda. Proyek internasionalisasi / pelokalan yang serius perlu mempertimbangkan dampaknya terhadap pengguna di lokasi itu. Jika tidak, aplikasi tidak akan menerima adopsi yang diharapkan pemasar.

— Berin Loritsch

3

Kami telah melakukannya sesuai kebutuhan: hal-hal yang berhubungan dengan pelanggan sekarang semuanya dilakukan dengan mempertimbangkan i18n, karena kami telah memperluas pasar kami, dan beberapa hal internal sekarang mampu i18n, sehingga karyawan yang menggunakan itu tidak perlu berbicara bahasa Inggris.

Jadi, kami melakukannya berdasarkan kebutuhan, sebagai startup.

— David Thornley
sumber

2

Kedengarannya orang-orang melakukan upaya yang sulit. Terutama ketika menggunakan bahasa Inggris sebagai bahasa asli, mudah untuk mengabaikan fakta bahwa bahasa lain biasanya membutuhkan 30-40% lebih banyak ruang untuk teks. Ini membutuhkan penerjemah untuk menggunakan singkatan yang tidak mudah dimengerti yang tentu saja buruk untuk pengalaman pengguna.

— petteri
sumber

1

Biasanya, saya menambahkan internasionalisasi nanti ketika saya membutuhkannya, bahkan jika saya tahu dari awal bahwa saya akan membutuhkannya. Dengan bahasa yang saya gunakan, tidak terlalu sulit untuk melakukannya dalam fase terpisah, dan saya bisa menjaga satu aspek rumit dari fase konstruktif awal.

— pengguna281377
sumber

2

Tidak yakin ini adalah pendekatan terbaik - bagaimana jika Anda mendapatkan permintaan untuk beberapa bahasa yang mungkin menyusahkan, mungkin beberapa bahasa byte ganda seperti Jepang, Korea, dll.?

— Jimmy Collins

1

Jimmy C: Saat ini, untuk jenis proyek yang sedang saya kerjakan, dukungan untuk bahasa Eropa seperti Inggris, Jerman, Prancis, Spanyol, Polandia dll sudah cukup. Saya hanya tidak cukup tahu tentang bahasa Jepang dan bahasa "bermasalah" lainnya (misalnya, menulis arahan, dll.) Untuk membuat semua persiapan yang diperlukan dalam perangkat lunak; dan tidak masuk akal menghabiskan banyak waktu dan uang untuk sesuatu yang mungkin tidak pernah terjadi. BTW, byte ganda bukan masalah kami, kami menggunakan Unicode di mana-mana: D

— user281377

Masuk akal kalau skenario itu kurasa.

— Jimmy Collins

Anda benar-benar tidak perlu tahu banyak tentang bahasa Arab dan Jepang untuk bersiap menghadapi internasionalisasi. Ada pedoman umum yang biasanya cukup baik. Jika Anda mendukung beberapa bahasa Eropa, dan menggunakan Unicode, kemungkinan besar Anda berada di sana.

— David Thornley

1

Saya menulis aplikasi android, dan lokalisasi cukup mudah menggunakan file string gaya java. Hampir tidak ada upaya untuk internasionalisasi penuh pada semua bahasa Android.

— Orang
sumber

Memang benar bahwa teknologi platform yang lebih baru telah dirancang dengan mempertimbangkan lokalisasi. Dalam pengalaman saya dengan iOS, ini adalah prosedur yang cukup sederhana untuk melokalkan jenis aplikasi ini.

— Jimmy Collins

1

Jawab: Ya. Meskipun di lingkungan saya bekerja (Python / Zope / Plone) sangat mudah untuk melokalisasi string setelahnya, jadi saya melewatkannya jika itu bukan persyaratan dari awal.

Tapi saya menyimpan teks dalam objek unicode, dll.

Jadi iya. Saya memastikan aplikasi saya cukup mudah untuk dilokalkan dan bahkan jika tidak dilokalkan akan berfungsi dalam pengaturan internasional. Tidak melakukan itu adalah kesalahan, karena upaya yang diperlukan kecil, dan manfaatnya besar.

— Lennart Regebro
sumber