Pagpapatupad ng multilinggwal na aplikasyon

Ngayon ay pag-uusapan natin ang multilinggwalismo. Kaya ano ito?

Multilingualism, sa madaling salita, internationalization , ay bahagi ng pagbuo ng isang application na maaaring iakma para sa ilang mga wika nang hindi binabago ang logic ng programa. Isaalang-alang ang sitwasyon: lumilikha ka ng isang web application para sa isang malaking kumpanya ng kalakalan para sa mga residente ng isang malaking bilang ng mga bansa kung saan, halimbawa, ang mga wika tulad ng Russian, English, at Spanish ay sinasalita. Kailangan mong gawin itong maginhawa para sa lahat ng mga gumagamit. Ang ideya ay ito: ang isang mambabasa na nagsasalita ng Ruso ay dapat magkaroon ng pagkakataon na makita ang iyong data sa Russian, magiging mas maginhawa para sa isang Amerikano na basahin ang materyal sa Ingles, at para sa isang Espanyol - sa Espanyol (nang hindi inaasahan, tama ba?) Hayaan. Isinasaalang-alang ang ilang mga modelo ng internasyonalisasyon ngayon , at para sa isa sa mga ito (na ang pinaka gusto ko :) Tingnan natin ang pagpapatupad sa Java. Bilang guinea pig ngayon magkakaroon tayo ng movie data board. Huwag tayong masyadong magpakaperwisyo, para hindi tayo magkaroon ng maraming tagapagsalita. Halimbawa, ayos lang. At isasalin namin ang mga pangalan ng mga pelikula (mga direktor - para sa mga dagdag):

1. Talahanayan na may pagsasalin para sa bawat wika

Ang kakanyahan ng modelong ito: ang bawat wika ay may hiwalay na talahanayan sa database, na naglalaman ng lahat ng mga cell na nangangailangan ng pagsasalin. Ang kawalan ng pamamaraang ito ay ang bawat oras na magdaragdag tayo ng bagong wika, kailangan nating magdagdag ng bagong talahanayan. Ibig sabihin, isipin natin na napakahusay ng ating customer, at pinapalawak niya ang kanyang aplikasyon sa maraming bansa (sa katunayan, mga wika) sa mundo. Nangangahulugan ito na kakailanganin mong magdagdag ng isang tablet sa bawat dila. Bilang resulta, magkakaroon tayo ng database na kalahati o halos ganap na binubuo ng mga auxiliary translation table: Schematic of the films itself: Translation tables:

• Ruso
• Espanyol
• Ingles

2. Isa para sa lahat

Sa bawat talahanayan na kabilang sa isang partikular na modelo, may idaragdag na field na may identifier para sa plate ng wika. Alinsunod dito, naglalaman din ang database ng talahanayang ito na may mga pagsasalin. Ang problema ay ang isang bagay ay maaaring tumutugma sa ilang mga pagsasalin (mga wika). Bilang isang resulta, magkakaroon ng pagdoble ng mga entity, at ito ay lubos na nakalilito at nagpapalubha sa lohika, at ito ay hindi mabuti. Tinitingnan namin ang UML: Mga pelikula sa talahanayan: Mga wika sa talahanayan:

3. Hanay bawat dila

Ang isang hiwalay na hanay ng pagsasalin ay nilikha para sa bawat hanay para sa bawat wika sa talahanayan. Ang kawalan ng diskarte na ito ay, muli, kung ang isang malaking bilang ng mga wika ay idinagdag, ang istraktura ng database ay kailangang baguhin sa bawat oras, at ito ay itinuturing na isang masamang diskarte. Isipin din kung gaano kalaki ang mga palatandaan na humihiling ng internasyonalisasyon. Maaaring sulit na isaalang-alang ang isang modelo kung saan ang bilang ng mga sinusuportahang wika ay alam nang maaga, hindi masyadong marami sa kanila, at ang bawat modelo ay dapat na umiiral sa lahat ng mga pagkakaiba-iba ng wika. UML: All inclusive na talahanayan:

4. Panlabas na pagsasalin

Ang pagpipiliang ito ay ipinatupad sa pamamagitan ng pagkonekta ng mga panlabas na tool (Google translate, Bing translate, atbp.). Ginagamit ito kung kailangan mong magbigay ng impormasyon sa pinakamaraming bisita hangga't maaari, at marami ang impormasyong ito. Ang dami. Sa kasong ito, maaari kang magpasya na hindi direktang mag-imbak ng impormasyon sa database sa lahat ng mga wika, ngunit dynamic na isalin ito. Ngunit ito ay nagkakahalaga ng pag-alala na ang kalidad ng pagsasalin ng makina ay madalas na nag-iiwan ng maraming nais. Ang opsyon ay maaari lamang ituring na napakatipid (kapag walang mapagkukunan upang isalin ang bawat publikasyon). Ang isang karaniwang problema sa mga tuntunin ng tamang pagsasalin ay ang mga tagasalin na hindi nakakaalam ng wikang mahusay na pumili ng maling kahulugan ng isang salita at malito ang gumagamit, na pinipilit siyang malayang malaman ang kahulugan ng kung ano ang nakasulat sa pindutan. Mahalaga rin hindi lamang ang wastong pagsasalin ng pangungusap, ngunit din upang dalhin ang kahulugan nito sa isang partikular na wika at nasyonalidad. Maraming problema ang mga developer sa mga kasarian sa ilang wika. Kailangan nilang i-duplicate ang parirala sa code depende sa kasarian ng gumagamit, at isinasaalang-alang din na hindi lamang mga pangngalan ang may kasarian, kundi pati na rin ang mga adjectives at pandiwa ay naiiba. May mga kaso kung kailan, nang pumili ng isang wika maliban sa English sa application, kasama ang mga salita ng napiling wika, mayroon pa ring mga hindi naisalin na elemento. Mas malala pa kung maraming wika ang ipinapakita at ito ay lumabas na isang uri ng Babylon, kung saan ang lahat ay halo-halong at hindi maintindihan ng user ang application. Halimbawa: https://cloud.google.com/translate/

5. Mga file ng suporta sa antas ng aplikasyon

Ang mga hiwalay na file ay ginawa upang mag-imbak ng mga pagsasalin. Maaari itong maging isang file bawat dila o isang file bawat dila bawat tablet (pinong pagdurog). Ang pagpipiliang ito ay madalas na ginagamit dahil sa katotohanan na maraming mga teksto ang maaaring maimbak sa mga file na ito, na nangangahulugan na ang mga talahanayan at ang database mismo ay hindi magiging namamaga. Ang isa pang kaginhawahan ay hindi mo kailangang kumatok sa database para sa mga field na ito, at ang mga file sa code ay maaaring dynamic na palitan depende sa hiniling na wika. Bilang resulta, ang file ay nagsisilbing isang diksyunaryo para sa amin, kung saan ang susi ay ang wika, ang halaga ay ang teksto. Ngunit hindi kami limitado sa ".properties" na format sa ibaba, at ang mga format ng file na ito ay maaaring mag-iba-iba - JSON, XML, atbp. Ang mga disadvantages ay na sa kasong ito ang normalisasyon ng database ay lubhang nabawasan. Gayundin, ang integridad ng data ay hindi na nakasalalay lamang sa database, kundi pati na rin sa mekanismo ng serialization. Napakahusay na artikulo sa paksang ito Halimbawa ng mga file ng diksyunaryo na may mga pagsasalin:

• Ingles
• Ruso
• Espanyol

6. Pantulong na talahanayan ng pagsasalin para sa bawat talahanayan

Sa aking opinyon, ang pinaka-kakayahang umangkop na solusyon. Ang kakanyahan ng diskarteng ito ay lumikha ng isang hiwalay na talahanayan para sa mga wika. Kapag kinakailangan na ipatupad ang posibilidad ng mga pagsasalin para sa talahanayang pinag-uusapan, isang link ang gagawin kasama ang talahanayan ng wika, at ang talahanayan ng link ay naglalaman ng language id, element id at mga column na may mga pagsasalin. Hindi ito nakakatakot gaya ng tunog. Ang diskarte na ito ay nagbibigay-daan para sa medyo nababaluktot na pagpapalawak ng mga sinusuportahang wika. Tingnan natin nang maigi. UML: Talahanayan na may mga pelikula: Talaan ng mga wika: Talaan ng mga pagsasalin: At, gaya ng sinabi ko sa itaas, tingnan natin ang pagpapatupad ng isa sa mga opsyon sa Java code (tulad ng naiintindihan mo, ito ang magiging huling opsyon). Walang ganoon sa application mismo: pupunta tayo mula sa mga controller hanggang sa mga layer ng dao. Titingnan natin ang paraan ng paglikha - para sa isang halimbawa ay sapat na ito. Kaya tayo)) Ang ating kakanyahan ay isang pelikula:

@Builder
@Getter
public class Movie {

   private Long id;

   private String producer;
}

Walang kawili-wili, ipinapatupad lamang ang modelo ng unang talahanayan. Controller na may dto (Data Transfer Object) converter:

@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();
   }
}

Sa DTO ipinapasa namin ang mga pagsasalin bilang mga mapa, ang susi ay ang pagdadaglat ng wika, ang halaga ay ang halaga ng pagsasalin (pangalan ng pelikula). 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' : 'Матрица'}"
}

Dito makikita natin ang mismong klase ng dto, tulad ng nakasulat sa itaas, mapa para sa mga pagsasalin, ang natitirang mga field ay isang pagpapakita ng modelo ng Pelikula. Lumipat tayo sa serbisyo ng pelikula:

public interface MovieService {

   Movie create(Movie movie, Map nameList);
}

Pagpapatupad nito:

@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;
   }
}

Dito makikita natin ang paggamit ng medyo third-party na serbisyo sa LanguageService upang makuha ang language id sa pamamagitan ng pagdadaglat nito. At gamit ang identifier na ito, nai-save namin ang aming mga pagsasalin (sa anyo din ng isang mapa) sa talahanayan ng koneksyon. Tingnan natin ang DAO:

public interface MovieDAO {

   void create(Movie movie);

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

Pagpapatupad:

@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));
   }
}

Dito makikita natin ang pangangalaga ng kakanyahan at mga wika para dito (diksyonaryo). At oo, Spring JDBC ay ginagamit dito: Itinuturing kong ito ay mas kanais-nais para sa mga nagsisimula, dahil ito ay mas transparent. Lumipat tayo sa isang "third-party" na serbisyo. Serbisyo sa wika:

public interface LanguageService {

   Long getIdByLangCode(String lang);
}

Pagpapatupad:

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

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

Walang espesyal, maghanap sa pamamagitan ng pinaikling pangalan. DAO:

public interface LanguageDAO {

   Long getIdByLangCode(String lang);
}

Pagpapatupad:

@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);
   }
}

Istraktura: Ang lahat ng mga modelong inilarawan sa itaas ay may karapatan sa buhay. Kailangan mong magpasya kung alin ang gagamitin batay sa sitwasyon. Siyempre, hindi lang iyon: marami pang iba't ibang diskarte, kabilang ang paggamit ng iba't ibang database para sa iba't ibang wika, paggamit ng mga cache, iba't ibang mga framework, at iba pa. Iyon lang para sa akin ngayon at...