Pelaksanaan aplikasi berbilang bahasa

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

Multilingualisme, dengan kata lain, pengantarabangsaan , adalah sebahagian daripada membangunkan aplikasi yang boleh disesuaikan untuk beberapa bahasa tanpa mengubah logik program. Pertimbangkan keadaan: anda sedang mencipta aplikasi web untuk syarikat perdagangan besar untuk penduduk sebilangan besar negara di mana, sebagai contoh, bahasa seperti Rusia, Inggeris dan Sepanyol digunakan. Anda perlu menjadikannya mudah untuk semua pengguna. Ideanya ialah: pembaca berbahasa Rusia seharusnya dapat melihat data anda dalam bahasa Rusia, seorang Amerika akan lebih selesa membaca bahan dalam bahasa Inggeris, dan seorang Sepanyol - dalam bahasa Sepanyol (tanpa diduga, bukan?) Mari kita pertimbangkan beberapa model pengantarabangsaan hari ini , dan untuk salah satu daripadanya (yang paling saya suka :) Mari lihat pelaksanaan di Jawa. Sebagai babi guinea, hari ini kita akan mempunyai plat data filem. Jangan terlalu terpesong, supaya kita tidak mempunyai banyak pembesar suara. Sebagai contoh, itu OK. Dan kami akan menterjemahkan nama-nama filem (pengarah - untuk tambahan):

1. Jadual dengan terjemahan untuk setiap bahasa

Intipati model ini: setiap bahasa mempunyai jadual berasingan dalam pangkalan data, yang mengandungi semua sel yang memerlukan terjemahan. Kelemahan kaedah ini ialah setiap kali kita menambah bahasa baru, kita perlu menambah jadual baru. Maksudnya, mari kita bayangkan bahawa pelanggan kami melakukannya dengan sangat baik, dan dia mengembangkan aplikasinya ke banyak negara (sebenarnya, bahasa) di dunia. Ini bermakna anda perlu menambah satu tablet setiap lidah. Akibatnya, kami akan mempunyai separuh pangkalan data atau hampir keseluruhannya terdiri daripada jadual terjemahan tambahan: Skema filem itu sendiri: Jadual terjemahan:

• bahasa Rusia
• bahasa Sepanyol
• Inggeris

2. Satu untuk semua

Dalam setiap jadual yang dimiliki oleh model tertentu, medan dengan pengecam untuk plat bahasa ditambahkan. Sehubungan itu, pangkalan data juga mengandungi jadual ini dengan terjemahan. Masalahnya ialah satu objek boleh sepadan dengan beberapa terjemahan (bahasa). Akibatnya, akan berlaku pertindihan entiti, dan ini sangat mengelirukan dan merumitkan logik, dan ini tidak baik. Kami melihat UML: Filem jadual: Bahasa jadual:

3. Lajur setiap lidah

Lajur terjemahan berasingan dibuat untuk setiap lajur untuk setiap bahasa dalam jadual. Kelemahan pendekatan ini ialah, sekali lagi, jika sejumlah besar bahasa ditambah, struktur pangkalan data perlu diubah setiap kali, dan ini dianggap sebagai pendekatan yang tidak baik. Bayangkan juga betapa melambungnya tanda-tanda yang menuntut pengantarabangsaan. Mungkin berbaloi untuk mempertimbangkan model di mana bilangan bahasa yang disokong diketahui terlebih dahulu, tidak terlalu banyak daripadanya, dan setiap model harus wujud dalam semua variasi bahasa. UML: Jadual semua termasuk:

4. Terjemahan luar

Pilihan ini dilaksanakan dengan menyambungkan alat luaran (terjemah Google, terjemahan Bing, dsb.). Ia digunakan jika anda perlu memberikan maklumat kepada seramai mungkin pelawat, dan terdapat banyak maklumat ini. Sangat banyak. Dalam kes ini, anda boleh memutuskan untuk tidak menyimpan maklumat secara langsung dalam pangkalan data dalam semua bahasa, tetapi untuk menterjemahkannya secara dinamik. Tetapi perlu diingat bahawa kualiti terjemahan mesin sering meninggalkan banyak perkara yang diingini. Pilihan itu hanya boleh dianggap sebagai sangat menjimatkan (apabila tiada sumber untuk menterjemah setiap penerbitan). Masalah yang kerap dari sudut terjemahan yang betul ialah penterjemah yang tidak mengetahui bahasa dengan baik memilih makna yang salah bagi sesuatu perkataan dan mengelirukan pengguna, memaksanya untuk secara bebas memikirkan makna apa yang ditulis pada butang. Ia juga penting bukan sahaja untuk menterjemah ayat dengan betul, tetapi juga untuk membawa maksudnya kepada bahasa dan kewarganegaraan tertentu. Pembangun mempunyai banyak masalah dengan jantina dalam sesetengah bahasa. Mereka perlu menduplikasi frasa dalam kod bergantung pada jantina pengguna, dan juga mengambil kira bahawa bukan sahaja kata nama mempunyai jantina, tetapi juga kata sifat dan kata kerja diubah secara berbeza. Terdapat kes apabila, setelah memilih bahasa selain bahasa Inggeris dalam aplikasi, bersama-sama dengan perkataan bahasa yang dipilih, masih terdapat unsur yang belum diterjemahkan. Lebih teruk lagi jika beberapa bahasa dipaparkan dan ternyata ia adalah sejenis Babylon, di mana segala-galanya bercampur-campur dan pengguna tidak dapat memahami aplikasi itu. Contohnya: https://cloud.google.com/translate/

5. Fail sokongan peringkat aplikasi

Fail berasingan dicipta untuk menyimpan terjemahan. Ia boleh menjadi satu fail bagi setiap lidah atau satu fail setiap lidah setiap tablet (penghancuran halus). Pilihan ini sering digunakan kerana fakta bahawa banyak teks boleh disimpan dalam fail ini, yang bermaksud bahawa jadual dan pangkalan data itu sendiri tidak akan menjadi kembung. Kemudahan lain ialah anda tidak perlu mengetuk pangkalan data untuk medan ini, dan fail dalam kod boleh diganti secara dinamik bergantung pada bahasa yang diminta. Akibatnya, fail berfungsi sebagai kamus untuk kami, di mana kuncinya ialah bahasa, nilainya ialah teks. Tetapi kami tidak terhad kepada format ".properties" di bawah dan format fail ini boleh berbeza-beza secara meluas - JSON, XML, dsb. Kelemahannya ialah dalam kes ini normalisasi pangkalan data sangat berkurangan. Selain itu, integriti data tidak lagi bergantung hanya pada pangkalan data, tetapi juga pada mekanisme bersiri. Artikel yang sangat baik mengenai topik ini Contoh fail kamus dengan terjemahan:

• Inggeris
• bahasa Rusia
• bahasa Sepanyol

6. Jadual terjemahan tambahan bagi setiap jadual

Pada pendapat saya, penyelesaian yang paling fleksibel. Intipati pendekatan ini adalah untuk mencipta jadual berasingan untuk bahasa. Apabila perlu untuk melaksanakan kemungkinan terjemahan untuk jadual yang dimaksudkan, pautan dibuat dengan jadual bahasa dan jadual pautan mengandungi id bahasa, id elemen dan lajur dengan terjemahan. Ia tidak seram seperti yang didengari. Pendekatan ini membolehkan pelanjutan yang agak fleksibel bagi bahasa yang disokong. Mari kita lihat lebih dekat. UML: Jadual dengan filem: Jadual bahasa: Jadual terjemahan: Dan, seperti yang saya katakan di atas, mari kita lihat pelaksanaan salah satu pilihan dalam kod Java (seperti yang anda faham, ini akan menjadi pilihan terakhir). Tiada apa-apa seperti itu dalam aplikasi itu sendiri: kita akan beralih daripada pengawal ke lapisan dao. Kami akan melihat kaedah cipta - sebagai contoh ini sudah memadai. Jadi mari kita pergi)) Intipati kami ialah sebuah filem:

@Builder
@Getter
public class Movie {

   private Long id;

   private String producer;
}

Tiada apa-apa yang menarik, hanya melaksanakan model jadual pertama. Pengawal dengan penukar dto (Objek Pemindahan 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();
   }
}

Dalam DTO kami menghantar terjemahan sebagai peta, kunci ialah singkatan bahasa, nilai ialah nilai terjemahan (nama filem). 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, medan yang tinggal ialah paparan model Filem. Mari kita beralih kepada perkhidmatan filem:

public interface MovieService {

   Movie create(Movie movie, Map nameList);
}

Pelaksanaannya:

@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 perkhidmatan LanguageService pihak ketiga yang agak ketiga untuk mendapatkan semula id bahasa mengikut singkatannya. Dan dengan pengecam ini kami menyimpan terjemahan kami (juga dalam bentuk peta) ke dalam jadual sambungan. Mari lihat DAO:

public interface MovieDAO {

   void create(Movie movie);

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

Pelaksanaan:

@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 pemeliharaan intipati dan bahasa untuknya (kamus). Dan ya, Spring JDBC digunakan di sini: Saya menganggapnya lebih baik untuk pemula, kerana ia lebih telus. Mari beralih kepada perkhidmatan "pihak ketiga". Perkhidmatan bahasa:

public interface LanguageService {

   Long getIdByLangCode(String lang);
}

Pelaksanaan:

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

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

Tiada yang istimewa, cari mengikut nama yang dipendekkan. DAO:

public interface LanguageDAO {

   Long getIdByLangCode(String lang);
}

Pelaksanaan:

@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 diterangkan di atas mempunyai hak untuk hidup. Anda perlu memutuskan yang mana satu untuk digunakan berdasarkan situasi. Sudah tentu, bukan itu sahaja: terdapat banyak lagi pendekatan yang berbeza, termasuk menggunakan pangkalan data yang berbeza untuk bahasa yang berbeza, menggunakan cache, rangka kerja yang berbeza dan sebagainya. Itu sahaja untuk saya hari ini dan...