Көп тилдүү колдонууну ишке ашыруу

Бүгүн биз көп тилдүүлүк жөнүндө сүйлөшөбүз. Анда бул эмне?

Көп тилдүүлүк, башкача айтканда, интернационалдаштыруу , программа логикасын өзгөртпөстөн, бир нече тилдерге ылайыкташа турган тиркемени иштеп чыгуунун бир бөлүгү. Кырдаалды карап көрөлү: сиз, мисалы, орус, англис жана испан тилдеринде сүйлөгөн көптөгөн өлкөлөрдүн жашоочулары үчүн ири соода компаниясы үчүн веб тиркеме түзүп жатасыз. Сиз аны бардык колдонуучулар үчүн ыңгайлуу кылышыңыз керек. Идея мындай: орус тилдүү окурман сиздин маалыматтарыңызды орус тorнде көрүү мүмкүнчүлүгүнө ээ болушу керек, америкалыкка материалды англис тorнде, ал эми испаниялыктар үчүн испан тorнде окуганы ыңгайлуураак болот (күтүүсүз, туурабы?) Бүгүнкү күндө бир нече интернационалдаштыруу моделдерин карап көрөлү , жана алардын бири үчүн (бул мага эң жагат :) Келгиле, Java тorнде ишке ашырууну карап көрөлү. Гвинея чочкосу катары бүгүн бизде кино маалымат тактасы болот. Өтө бузуку болуп кетпейли, ошондуктан бизде көп сүйлөгөндөр болбойт. Мисалы, бул жакшы. Ал эми тасмалардын атын которобуз (режиссёрлор - кошумчалар үчүн):

1. Ар бир тил үчүн котормосу бар table

Бул моделдин маңызы: ар бир тилде маалымат базасында өзүнчө table бар, анда которууну талап кылган бардык уячалар камтылган. Бул ыкманын кемчorги – жаңы тилди кошкон сайын жаңы table кошуу керек. Башкача айтканда, биздин кардар абдан жакшы иштеп жатат деп элестетип көрөлү жана ал өзүнүн колдонуусун дүйнөнүн көптөгөн өлкөлөрүнө (чындыгында, тилдерге) жайылтып жатат. Бул ар бир тилге бир таблетка кошуу керек дегенди билдирет. Натыйжада, биз жарым же дээрлик толугу менен көмөкчү котормо tableларынан турган маалымат базасына ээ болобуз: Тасмалардын схемасы: Котормо tableлары:

• Орусча
• Испанча
• Англисче

2. Баары үчүн бир

Белгилүү бир моделге тиешелүү болгон ар бир tableда тил tableсы үчүн идентификатору бар талаа кошулат. Демек, маалымат базасы котормолору менен бул tableны да камтыйт. Маселе бир an object бир нече котормолорго (тилдерге) туура келиши мүмкүн. Натыйжада, субъекттердин кайталанышы пайда болот жана бул логиканы абдан чаташтырат жана татаалдаштырат, бул жакшы эмес. Биз UMLди карайбыз: Стол тасмалары: Таблица тилдери:

3. Тил үчүн тилке

Таблицадагы ар бир тил үчүн ар бир тилке үчүн өзүнчө котормо тилкеси түзүлөт. Бул ыкманын кемчorги, дагы бир жолу, көп сандагы тилдер кошулса, маалымат базасынын структурасын ар бир жолу өзгөртүү керек болот жана бул жаман мамиле болуп эсептелет. Ошондой эле интернационалдаштырууну талап кылган белгилер канчалык чоң болорун элестетип көрүңүз. Колдоого алынган тилдердин саны алдын ала белгилүү болгон моделди карап чыгууга арзырлык болушу мүмкүн, алардын саны өтө көп эмес жана ар бир модель бардык тил вариацияларында болушу керек. UML: Баарын камтыган table:

4. Тышкы котормо

Бул параметр тышкы куралдарды (Google translate, Bing translate ж.б.) туташтыруу аркылуу ишке ашырылат. Эгер мүмкүн болушунча көбүрөөк конокторго маалымат берүү керек болсо колдонулат жана бул маалымат көп. Абдан көп. Бул учурда, сиз бардык тилдерде маалымат базасында маалыматты түз сактоону эмес, аны динамикалык түрдө которууну чечсеңиз болот. Бирок, машина которуунун сапаты көп учурда каалаган нерсени калтырарын эстен чыгарбоо керек. Опцияны өтө үнөмдүү катары гана кароого болот (ар бир басылманы которуу үчүн ресурстар жок болгондо). Туура которуу жагынан жалпы көйгөй тилди жакшы билбеген котормочулар сөздүн туура эмес маанисин тандап алып, колдонуучуну чаташтырып, баскычта жазылган нерсенин маанисин өз алдынча аныктоого мажбурлоодо. Сүйлөмдү туура которуу гана эмес, анын маанисин белгилүү бир тилге, улутка жеткирүү да маанилүү. Иштеп чыгуучулардын кээ бир тилдерде гендердик көйгөйлөрү көп. Алар колдонуучунун жынысына жараша codeдогу сөз айкашын кайталашы керек, ошондой эле зат атоочтор гана эмес, сын атоочтор менен этиштер да ар түрдүүчө түшөт. Тиркемеде англис тorнен башка тилди тандап алып, тандалган тилдин сөздөрү менен бирге дагы эле которула элек элементтер бар болгон учурлар бар. Андан да жаманы, эгерде бир нече тилдер көрсөтүлсө жана ал Вавилондун бир түрү болуп чыкса, анда баары аралашып, колдонуучу тиркемени түшүнө алbyte. Мисалы: https://cloud.google.com/translate/

5. Колдонмо деңгээлиндеги колдоо файлдары

Котормолорду сактоо үчүн өзүнчө файлдар түзүлөт. Бул тилге бир файл же планшетке бир тилге бир файл болушу мүмкүн (майда майдалоо). Бул параметр көбүнчө бул файлдарда көптөгөн тексттерди сактоого мүмкүн болгондуктан колдонулат, бул tableлар жана маалымат базасы шишип кетпейт. Дагы бир ынгайлуулугу - бул талаалар үчүн маалымат базасын тыкылdateунун кереги жок жана codeдогу файлдар суралган тилге жараша динамикалык түрдө алмаштырылышы мүмкүн. Натыйжада, файл биз үчүн сөздүк катары кызмат кылат, анда ачкыч тил, баалуулук текст. Бирок биз төмөндөгү ".properties" форматы менен чектелбейбиз жана бул файл форматтары ар түрдүү болушу мүмкүн - JSON, XML ж.б. Кемчorктер бул учурда базанын нормалдашуусу абдан азаят. Ошондой эле, маалыматтардын бүтүндүгү мындан ары маалымат базасына гана көз каранды эмес, ошондой эле сериялаштыруу механизмине. Бул тема боюнча сонун макала Котормолору бар сөздүк файлдарынын мисалы:

• Англисче
• Орусча
• Испанча

6. Ар бир table үчүн көмөкчү котормо tableсы

Менин оюмча, эң ийкемдүү чечим. Бул ыкманын маңызы тилдер үчүн өзүнчө table түзүү болуп саналат. Каралып жаткан table үчүн котормолордун мүмкүнчүлүгүн ишке ашыруу зарыл болгондо, тил tableсы менен шилтеме түзүлөт, ал эми шилтеме tableсында тил идентификатору, элементтин идентификатору жана котормолору бар мамычалар камтылган. Бул сезилгендей коркунучтуу эмес. Бул ыкма колдоого алынган тилдердин кыйла ийкемдүү кеңейүүсүнө мүмкүндүк берет. Келгиле, жакыныраак карап көрөлү. UML: Тасмалар менен table: Тилдер tableсы: Котормолордун tableсы: Жана мен жогоруда айткандай, Java codeундагы варианттардын биринин ишке ашырылышын карап көрөлү (сиз түшүнгөндөй, бул акыркы вариант болот). Колдонмонун өзүндө мындай эч нерсе жок: биз контроллерлордон тао катмарларына өтөбүз. Биз түзүү ыкмасын карап чыгабыз - мисалы, бул жетиштүү болот. Анда кетели)) Биздин маңызыбыз тасма:

@Builder
@Getter
public class Movie {

   private Long id;

   private String producer;
}

Кызыктуу эч нерсе жок, жөн гана биринчи столдун моделин ишке ашыруу. dto (Data Transfer Object) конвертерлери бар контроллер:

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

DTOдо биз котормолорду карта катары өткөрөбүз, ачкыч – тилдин аббревиатурасы, маани – котормо мааниси (фильмдин аты). 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' : 'Матрица'}"
}

Бул жерде биз dto классынын өзүн көрөбүз, жогоруда жазылгандай, котормолордун картасы, калган талаалар Кино моделинин дисплейи. Келгиле, кино кызматына өтөбүз:

public interface MovieService {

   Movie create(Movie movie, Map nameList);
}

Аны ишке ашыруу:

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

Бул жерде биз анын аббревиатурасы боюнча тил идентификаторун алуу үчүн салыштырмалуу үчүнчү тараптын LanguageService кызматын колдонууну көрөбүз. Жана бул идентификатор менен биз котормобузду (ошондой эле карта түрүндө) байланыш tableсына сактайбыз. Келгиле, DAO карап көрөлү:

public interface MovieDAO {

   void create(Movie movie);

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

Ишке ашыруу:

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

Бул жерде биз анын маңызын жана тилдеринин сакталышын көрөбүз (сөздүк). Ооба, бул жерде Spring JDBC колдонулат: мен аны үйрөнчүктөр үчүн артыкчылыктуу деп эсептейм, анткени ал ачык-айкын. Келгиле, "үчүнчү тараптын" кызматына өтөбүз. Тил кызматы:

public interface LanguageService {

   Long getIdByLangCode(String lang);
}

Ишке ашыруу:

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

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

Өзгөчө эч нерсе жок, кыскартылган аты боюнча издөө. ДАО:

public interface LanguageDAO {

   Long getIdByLangCode(String lang);
}

Ишке ашыруу:

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

Структура: Жогоруда сүрөттөлгөн бардык моделдер жашоого укуктуу. Сиз кырдаалга жараша кайсынысын колдонууну чечишиңиз керек. Албетте, бул баары эмес: дагы көптөгөн ар кандай ыкмалар бар, анын ичинде ар кандай тилдер үчүн ар кандай маалымат базаларын колдонуу, кэштерди, ар кандай алHowтарды жана башкалар. Мунун баары мен үчүн бүгүн жана...