Kuidas lahendada infosüsteemis andmete tõlkimine?

Question

Ülesanne selline, et tarvis andmebaasis muuta teatud väljad tõlgitavaks. Nt toote nimi ja kirjeldus, kliendi nimi, mõõtühik jne.

Pähe tulevad järgmised variandid:

Iga keele jaoks omaette veerg tabelis
- uut keelt lisada keeruline
- tuleb kasutada erinevaid välju nt otsingu korral
Täiendav tõlgete tabel, kus igale originaalkeeles tekstile seatakse vastavusse tõlge
- uut keelt lisada lihtne
- päringu ja otsingu puhul tuleb teha left join tõlgete tabeliga iga tõlkitava välja jaoks. Ei ole just efektiivseim, aga pole selge kas saab üldse paremini.
- mis keeles on väli algtabelis? Tobe oleks nõuda eestikeelse nime väljamõtlemist igale tootele, kui seda kasutatakse ainult ingliskeelses kontekstis.
Sama, mis 2., ainult et tõlked seotakse ID alusel, mitte tekstistringidena.
- tõlkeid ei saa taaskasutada. Pole vist suur probleem?
- kõik tekstid salvestatakse tõlgete tabelisse. Kas algtabelist võib vastavad väljad eemaldada? Ebaintuitiivne, aga saab kapseldada andmebaasis viewdesse.
- Kas see kõik ei lähe aeglaseks, kui on üks suur tõlgete tabel?

Mida soovitate?

Accepted Answer

Ma arvan, et variant 3 on kõige mõistlikum. Kasutada baastabelites tõlgete ID'sid ja pärida tõlkeid läbi funktsiooni (mitte join'i). See peaks olema suht kiire, kuna indeks (tolke_id, keel) on kompaktne ja efektiivne. Täiendava kiiruse jaoks on võimalik funktsiooni poolt tagastatud tulemused mälutabelis salvestada (cache'ida) kui programmeerimiskeskkond seda võimaldab. Või kui kliendi pool on võimalik kasutada mõnda lokaalset andmestruktuuri, siis on näiteks sisse logimisel võimalik luua lokaalne tabel ainult selle keele tõlgetega, mida kasutaja kasutab ja pärida tõlked sealt. Funktsiooni kasutamine tagab selle, et selliseid täiendavaid mälustruktuure saab muuta/lisada/kasutada ka hiljem kui süsteem kasvab ja vajadused muutuvad.

Variant 2 on tegelikult peaaegu sama hea, lihtsalt kasutatav ID väli on tekstiväli, mis kasvatab indeksi oluliselt suuremaks (situatsioonis kus on vaja tõlkida terve fraas).

Variant 1 - tuleks hoiduda igal juhul. See on väga piirav lahendus ja kui süsteem kasvab, siis võib uue keele lisamine olla väga keerukas (suure arvu päringute tõttu, mis pärivad tõlget konkreetsest veerust).

(Ja veel, kui hakata süsteemi arendama nullist ja tegemist on tüüpilise browseri põhise lahendusega, siis on kasulik kaaluda mõne olemasoleva framework'i kasutamist, kus tõlkimise mootor on juba realiseeritud)

Answer 2

Ma ütleks, et kõigil neil variantidel on omad head ja vead. Õige lahendus oleks täiendada andmebaasimootorit ennast nii, et välju saaks tõlkida. Kuid miskipärast on mul tunne, et seda sa tegema ei hakka :)

Variant 1 pole sugugi nii paha kui see vaid õigesti implementeerida. Mõistagi on vale kirjutada sellist koodi:

if (lang=="et") {
  db.query("SELECT * FROM products WHERE name_et = ?", name);
} else {
  db.query("SELECT * FROM products WHERE name_en = ?", name);
}

Sellisel juhul on muidugi uue keele lisamine ääretult piinarikas. Parem on täiendada andmebaasiklassi nii, et parajasti aktiivse keele nimetus lisatakse automaatselt spetsiaalselt märgistatud väljade lõppu. Näiteks:

db.query("SELECT * FROM products WHERE name_ = ?", name);

Suurim eelis selle variandi puhul on muidugi kiirus. Ei mingeid keerukaid JOIN'e ega muud säärast. Väga lihtne on ehitada iga keele tulbale eraldi indeksid peale, et sorteerimine toimuks just vastava keele reeglite alusel. Kui sul aga on kõik keeled ühes suures tõlgete tabelis, siis selle indekseerimine ei saa just kõikse lihtsam olema. (Näiteks MySQL lubab ühele tulbale määrata vaid ühe kollatsiooni.)

Olen ise taolist süsteemi kasutanud ja polnud tal häda kedagi. Kui oli tarvis uut keelt lisada, siis selle tegi ära väike skriptikene. Ainuke asi, et kui tegid andmebaasis käsurealt SELECT * FROM table siis kargasid kõik need tõlked korraga näkku, aga VIEW'de kasutamine lahendas sellegi mure.

Samas on mul olnud kokkupuuteid andmebaasidega, kus tõlked on seotud ID-dega ning lihtsalt tabelile peale vaadates ei saa mitte mõhkugi aru mis asja see tabel sisaldab, sest tekstide asemel on igal pool mingid numbrid. Muidugi VIEW'de kasutamine oleks seda probleemi leevendanud, kui keegi oleks kunagi viitsinud neid VIEW'sid sinna teha.

Lisaks ei tasu ära unustada, et VIEW'desse UPDATE'mine ja INSERT'imine võib osutuda problemaatiliseks.

Answer 3

Lisan veel ühe variandi:

Lisada iga tabeli kõrvale tõlgete tabel, mis on üks-üheses seoses põhitabeliga. Tõlgete tabelis on kõik tõlgitavad väljad + keel.
- Oletatavasti efektiivsem kui kõikide tõlgete hoidmine ühes suures tabelis.
- Päringusse lisandub üks lihtne join, võrreldes ühe globaalse tabeli variandiga, kus lisandub join iga tõlgitava välja kohta.
- Uue keele lisamine ei tähenda andmebaasi struktuuri muudatust.
- Tülikas uut välja tõlgitavaks märkida.
- Kas põhitabelisse jäävad tõlgitavad väljad alles või kaovad ära? Kui jäävad alles, siis mis oleks nende sisu?

Answer 4

0

Mina ei paneks tõlkeid üleüldse baasi, vaid kasutaks näiteks gettexti. Gettexti peale/juurde on ehitatud terve hulk tööriistu, millega tõlkijatel mugav majandada on ja mille uuesti ehitamine baasi peale tundub jalgratta leiutamisena.

Pealegi, kui juba tõlkima hakata, siis on sul ilmselt ka selliseid tekste vaja tõlkida, mida baasis ei ole - kasutajaliidese elemendid näiteks. Ja milleks siis hoida üleval kahte paralleelset süsteemi?

Toote nimede/kirjelduste jms gettexti lähteformaati saamiseks tuleb muidugi natuke vaeva näha, aga minu meelest tulemus on seda väärt.

link

vastatud Oct 28 '09 at 10:30

Anti Veeranna
206●3

Minu kontekst on see, et kasutaja tahab ise toodete nimetusi jms tõlkida. St ma peaks sisuliselt .po faile jooksult genereerima ning realiseerima nende editori oma kasutajaliideses. Natuke keeruliseks läheb. Aga muidu olen gettexti kasutanud ja kasutajaliidese tekstide tõlkimiseks sobib ta väga hästi.

(Oct 28 '09 at 10:57) Tambet Matiisen ♦♦

Kuidas lahendada infosüsteemis andmete tõlkimine?

Jälgi seda küsimust

Pinu tööpakkumised

Sarnased küsimused