Implementasi aplikasi multibahasa

Hari ini kita akan berbicara tentang multibahasa. Jadi apa itu?

Multilingualisme, dengan kata lain internasionalisasi , merupakan bagian dari pengembangan suatu aplikasi yang dapat diadaptasi untuk beberapa bahasa tanpa mengubah logika program. Pertimbangkan situasinya: Anda membuat aplikasi web untuk perusahaan perdagangan besar untuk penduduk di sejumlah besar negara yang, misalnya, menggunakan bahasa seperti Rusia, Inggris, dan Spanyol. Anda harus membuatnya nyaman bagi semua pengguna. Idenya adalah ini: pembaca berbahasa Rusia harus dapat melihat data Anda dalam bahasa Rusia, pembaca Amerika akan lebih nyaman membaca materi dalam bahasa Inggris, dan pembaca Spanyol - dalam bahasa Spanyol (tanpa diduga, bukan?) Mari kita pertimbangkan beberapa model internasionalisasi saat ini , dan salah satunya (yang paling saya suka :) Mari kita lihat implementasinya di Java. Sebagai kelinci percobaan, hari ini kita akan memiliki pelat data film. Jangan terlalu mesum, agar pembicara kita tidak banyak. Misalnya, tidak apa-apa. Dan kami akan menerjemahkan nama-nama filmnya (sutradara - untuk tambahan):

1. Tabel dengan terjemahan untuk setiap bahasa

Inti dari model ini: setiap bahasa memiliki tabel terpisah dalam database, yang berisi semua sel yang memerlukan terjemahan. Kerugian dari metode ini adalah setiap kali kita menambahkan bahasa baru, kita perlu menambahkan tabel baru. Artinya, bayangkan pelanggan kita bekerja dengan sangat baik, dan dia memperluas aplikasinya ke banyak negara (bahkan, bahasa) di dunia. Ini berarti Anda perlu menambahkan satu tablet per lidah. Hasilnya, kita akan memiliki database yang setengah atau hampir seluruhnya terdiri dari tabel terjemahan tambahan: Skema film itu sendiri: Tabel terjemahan:

• Rusia
• Orang Spanyol
• Bahasa inggris

2. Satu untuk semua

Di setiap tabel milik model tertentu, bidang dengan pengidentifikasi untuk pelat bahasa ditambahkan. Oleh karena itu, database juga berisi tabel ini dengan terjemahannya. Masalahnya adalah satu objek bisa berhubungan dengan beberapa terjemahan (bahasa). Akibatnya akan terjadi duplikasi entitas, dan ini sangat membingungkan dan memperumit logika, dan ini tidak baik. Kami melihat UML: Film tabel: Bahasa tabel:

3. Kolom per lidah

Kolom terjemahan terpisah dibuat untuk setiap kolom untuk setiap bahasa dalam tabel. Kerugian dari pendekatan ini adalah, sekali lagi, jika sejumlah besar bahasa ditambahkan, struktur database perlu diubah setiap saat, dan ini dianggap sebagai pendekatan yang buruk. Bayangkan juga betapa besarnya tanda-tanda yang menuntut internasionalisasi. Mungkin ada baiknya mempertimbangkan model yang jumlah bahasa yang didukung telah diketahui sebelumnya, jumlahnya tidak terlalu banyak, dan setiap model harus ada dalam semua variasi bahasa. UML: Tabel semua inklusif:

4. Terjemahan eksternal

Opsi ini diterapkan dengan menghubungkan alat eksternal (Google Translate, Bing Translate, dll.). Ini digunakan jika Anda perlu memberikan informasi kepada pengunjung sebanyak mungkin, dan informasi ini jumlahnya banyak. Sangat banyak. Dalam hal ini, Anda dapat memutuskan untuk tidak menyimpan informasi secara langsung dalam database dalam semua bahasa, namun menerjemahkannya secara dinamis. Namun perlu diingat bahwa kualitas terjemahan mesin seringkali buruk. Pilihan ini hanya dapat dianggap sangat ekonomis (bila tidak ada sumber daya untuk menerjemahkan setiap publikasi). Masalah umum dalam hal terjemahan yang benar adalah penerjemah yang tidak menguasai bahasa dengan baik memilih arti kata yang salah dan membingungkan pengguna, memaksanya untuk secara mandiri mencari tahu arti dari apa yang tertulis di tombol. Penting juga untuk tidak hanya menerjemahkan kalimat dengan benar, tetapi juga menyampaikan maknanya ke dalam bahasa dan kebangsaan tertentu. Pengembang memiliki banyak masalah terkait gender dalam beberapa bahasa. Mereka harus menduplikasi frasa dalam kode tergantung pada jenis kelamin pengguna, dan juga memperhitungkan bahwa tidak hanya kata benda yang memiliki jenis kelamin, tetapi kata sifat dan kata kerja juga memiliki infleksi yang berbeda. Ada kalanya, setelah memilih bahasa selain bahasa Inggris dalam aplikasi, beserta kata-kata dari bahasa yang dipilih, masih ada unsur yang belum diterjemahkan. Parahnya lagi jika ditampilkan beberapa bahasa dan ternyata semacam Babylon yang semuanya tercampur aduk dan pengguna tidak bisa memahami aplikasinya, contoh: https://cloud.google.com/translate/

5. File dukungan tingkat aplikasi

File terpisah dibuat untuk menyimpan terjemahan. Ini bisa berupa satu kikir per lidah atau satu kikir per lidah per tablet (penghancuran halus). Opsi ini sering digunakan karena banyak teks dapat disimpan dalam file ini, yang berarti tabel dan database itu sendiri tidak akan membengkak. Kenyamanannya juga terletak pada kenyataan bahwa Anda tidak perlu mengetuk database untuk bidang-bidang ini, dan dalam kode, file dapat diganti secara dinamis tergantung pada bahasa yang diminta. Hasilnya, file tersebut berfungsi sebagai kamus bagi kita, yang kuncinya adalah bahasanya, nilainya adalah teksnya. Namun kami tidak terbatas pada format ".properties" di bawah ini, dan format file ini bisa sangat bervariasi - JSON, XML, dll. Kerugiannya adalah dalam hal ini normalisasi database sangat berkurang. Selain itu, integritas data tidak lagi hanya bergantung pada database, tetapi juga pada mekanisme serialisasi. Artikel bagus tentang topik ini Contoh file kamus dengan terjemahan:

• Bahasa inggris
• Rusia
• Orang Spanyol

6. Tabel terjemahan tambahan untuk setiap tabel

Menurut saya, solusi paling fleksibel. Inti dari pendekatan ini adalah membuat tabel terpisah untuk bahasa. Jika diperlukan untuk mengimplementasikan kemungkinan terjemahan untuk tabel yang dimaksud, tautan dibuat dengan tabel bahasa, dan tabel tautan berisi id bahasa, id elemen, dan kolom dengan terjemahan. Ini tidak seseram kedengarannya. Pendekatan ini memungkinkan perluasan bahasa yang didukung secara cukup fleksibel. Mari kita lihat lebih dekat. UML: Tabel dengan film: Tabel bahasa: Tabel terjemahan: Dan, seperti yang saya katakan di atas, mari kita lihat implementasi salah satu opsi dalam kode Java (seperti yang Anda pahami, ini akan menjadi opsi terakhir). Tidak ada hal seperti itu dalam aplikasi itu sendiri: kita akan beralih dari pengontrol ke lapisan dao. Kita akan melihat metode pembuatannya - sebagai contoh, ini sudah cukup. Jadi ayo pergi)) Inti dari kita adalah sebuah film:

@Builder
@Getter
public class Movie {

   private Long id;

   private String producer;
}

Tidak ada yang menarik, hanya mengimplementasikan model tabel pertama. Pengontrol dengan konverter dto (Objek Transfer Data):

@RestController
@RequiredArgsConstructor
@RequestMapping(path = "/cities")
public class MovieController {

   private final MovieService movieService;

   @PostMapping
   public ResponseEntity<moviedto> create(MovieDTO movieDTO) {
       return new ResponseEntity<>(toDTO(movieService.create(fromDTO(movieDTO), movieDTO.getNameTranslations()), movieDTO.getNameTranslations()), HttpStatus.CREATED);
   }

   private Movie fromDTO(MovieDTO dto) {
       return Movie.builder()
               .id(dto.getId())
               .producer(dto.getProducer())
               .build();
   }

   private MovieDTO toDTO(Movie movie, Map<string, string=""> nameTranslation) {
       return MovieDTO.builder()
               .id(movie.getId())
               .producer(movie.getProducer())
               .nameTranslations(nameTranslation)
               .build();
   }
}

Di DTO kami meneruskan terjemahan sebagai peta, key adalah singkatan bahasa, value adalah nilai terjemahan (nama film). DTO:

@Builder
@Getter
@NoArgsConstructor
@AllArgsConstructor
public class MovieDTO {

   @JsonProperty("id")
   private Long id;

   @JsonProperty("name")
   private String producer;

   @JsonProperty("nameTranslations")
   private Map<String, String> nameTranslations;//example = "{'en': 'The Matrix', 'ru' : 'Матрица'}"
}

Di sini kita melihat kelas dto itu sendiri, seperti yang ditulis di atas, peta untuk terjemahan, bidang yang tersisa adalah tampilan model Film. Mari beralih ke layanan film:

public interface MovieService {

   Movie create(Movie movie, Map nameList);
}

Implementasinya:

@Service
@RequiredArgsConstructor
public class MovieServiceImpl implements MovieService {

   private final MovieDAO movieDAO;
   private LanguageService languageService;

   @Override
   public Movie create(Movie movie, Map<string, string=""> nameList) {
       movieDAO.create(movie);
       Map<Long, String> map = new HashMap<>();
       nameList.forEach((x, y) -> map.put(languageService.getIdByLangCode(x), y));
       movieDAO.createTranslator(movie.getId(), map);
       return movie;
   }
}

Di sini kita melihat penggunaan layanan LanguageService pihak ketiga untuk mengambil id bahasa berdasarkan singkatannya. Dan dengan pengidentifikasi ini kami menyimpan terjemahan kami (juga dalam bentuk peta) ke dalam tabel koneksi. Mari kita lihat DAOnya:

public interface MovieDAO {

   void create(Movie movie);

   void createTranslator(Long movieId, Map<Long,String> nameTranslations);
}

Penerapan:

@RequiredArgsConstructor
@Repository
public class MovieDAOImpl implements MovieDAO {
   private final JdbcTemplate jdbcTemplate;

   private static final String CREATE_MOVIE = "INSERT INTO movies(id, producer) VALUES(?, ?)";

   private static final String CREATE_TRANSLATOR = "INSERT INTO movies_translator(movies_id, language_id, name) VALUES(?, ?, ?)";

   @Override
   public void create(Movie movie) {
       jdbcTemplate.update(CREATE_MOVIE, movie.getId(), movie.getProducer());
   }

   @Override
   public void createTranslator(Long movieId, Map<Long, String> nameTranslations) {
       nameTranslations.forEach((x, y) -> jdbcTemplate.update(CREATE_TRANSLATOR, movieId, x, y));
   }
}

Di sini kita melihat kelestarian esensi dan bahasanya (kamus). Dan ya, Spring JDBC digunakan di sini: Saya menganggapnya lebih baik untuk pemula, karena lebih transparan. Mari beralih ke layanan "pihak ketiga". Layanan bahasa:

public interface LanguageService {

   Long getIdByLangCode(String lang);
}

Penerapan:

@Service
@RequiredArgsConstructor
public class LanguageServiceImpl implements LanguageService {
   private final LanguageDAO languageDAO;

   @Override
   public Long getIdByLangCode(String lang) {
       return languageDAO.getIdByLangCode(lang);
   }
}

Tidak ada yang istimewa, cari berdasarkan nama singkat. DAO:

public interface LanguageDAO {

   Long getIdByLangCode(String lang);
}

Penerapan:

@RequiredArgsConstructor
@Repository
public class LanguageDAOImpl implements LanguageDAO {
   private final JdbcTemplate jdbcTemplate;

   private static final String FIND_ID_BY_LANG_CODE = "SELECT id FROM languages WHERE lang_code = ?";

   @Override
   public Long getIdByLangCode(String lang) {
       return jdbcTemplate.queryForObject(FIND_ID_BY_LANG_CODE, Long.class, lang);
   }
}

Struktur: Semua model yang dijelaskan di atas mempunyai hak untuk hidup. Anda perlu memutuskan mana yang akan digunakan berdasarkan situasinya. Tentu saja, bukan hanya itu saja: masih banyak lagi pendekatan yang berbeda, termasuk penggunaan database yang berbeda untuk bahasa yang berbeda, penggunaan cache, kerangka kerja yang berbeda, dan seterusnya. Itu saja untukku hari ini dan...