Vícejazyčné texty v DB

[Ondřej Novák]

Snažím se někde vygooglit rozumnou strategii pro vícejazyčné texty v databázích. Samozřejmě že nejprve jsem to řešil extra tabulkou, ve které byly pro každý řádek v primární tabulce textové popisky pro konkrétní jazyk s tím, že primární tabulka má take textové popisky, které suplují "default" jazyk, tedy situaci, kdy někdo žádá o jazyk, který není v jazykové tabulce.

Tohle řešení dost komplikuje některé dotazy a moc se mi nelíbí, je málo univerzální.

Pak mě napadlo dávat vícejazyčné texty dohromady do jednoho sloupečku a nějak to rozlišit uvnitř, s tím, že by po vrácení z DB došlo k nějaké filtraci textu podle toho, co žádá uživatel za jazyk. Zpracování textu by bylo obecnější, ale dělal by to až backend, ne databáze (maximálně, že by se napsala funkce pro databázi, která by to dělala).

Poradí někdo řešení, jak se to třeba dělá jinde? Nebo stačí jen poradit vhodný dotaz pro googla.

[Reklama]

[Kit]

Pro statické texty se používá Gettext.

Pro dynamické texty je možné použít třísloupcovou tabulku: jazyk, klíč a text. Primárním klíčem je pak dvojice (jazyk, klíč), atributem text.

Text se může vypisovat přímo nebo prostřednictvím funkce printf(). V tom případě může obsahovat i příslušné formátovací znaky pro vkládání hodnot.

Může být praktické i použití některých dalších NoSQL databází, jejich výběr však záleží na případu užití a také na použitém programovacím jazyku. Osvědčila se mi například DB4, resp. GDBM.

[andy]

Mozes si pozriet prestashop alebo magento. V preste je ku kazdej tabulke tabulka _lang kde su relevantne roznojazycne texty. Dalo by sa aj mat to v 1 tabulke, kde by bol stlpec "table_name" a kluc. Co sa tyka tvojho default stlpca, tak mozno je zbytocny, lebo mozes mat default ako jazyk, alebo mat jeden z jazykov ako default.

Okrem toho nezabudaj aj na moznost pouzit (napr na nazvy policok ako meno/priezvysko) gettext.

[Ondřej Novák]

o gettext nejde. Server nemá žádné vlastní texty, funguje jako dodavatel dat. Varianta místo textu ID do tabulky textů se mi moc nelíbí zvlášť to komplikuje query při vyzvedávání textů

typicky:

Kód: [Vybrat]

Nabidka
ID, fld1,fld2,fld3, nazev, popisek, podminky_pouziti, ....
kde fldX jsou netextové políčka

s tim _lang to mám podobně,

Kód: [Vybrat]

Nabidka_lang
ID, jazyk, nazev, popise, podminky_pouziti

akorát těch textů v různých tabulkách tam mám hafo a abych ke každé tabulce vytvářel _lang variantu a upravoval všechny místa, kde se to vyzvedává... no se mi moc nechce

[to_je_jedno]

V preste je ku kazdej tabulke tabulka _lang

To jako fakt? Ze, je presta tragicky kus SW jsem vedel davno, ale ze az takhle to me prekvapuje.

Jednoduche reseni(v podstate jiz bylo napsane):
locales_source - ls_id, text, context
locales_taget - lt_id, ls_id, lang, text (lt_id = auto_increment primary key, unique = ls_id - lang)
ziskani prekladu pro dany jazyk = 1 jednoduchy select s 1 jednoduchym joinem

Pak akorat delame to, ze kazdy print je vzdy prohnany funkci t(); (viz https://api.drupal.org/t )
Tohle se tyka prekladu user interface a custom stringu.

Pak je jina vec preklady obsahu (= entit).

[Reklama]

[Kit]

o gettext nejde. Server nemá žádné vlastní texty, funguje jako dodavatel dat. Varianta místo textu ID do tabulky textů se mi moc nelíbí zvlášť to komplikuje query při vyzvedávání textů

Pokud nepotřebuješ vazbu na jiné tabulky, tak je ID v takových tabulkách zbytečné.Můžeš používat slova jako primární klíče.

Můžeš udělat i defaultní jazyk, který se použije, pokud požadovaný text v požadovaném jazyce v tabulce není.
Komplikaci query nikde nevidím, jsou to jen dvě tabulky. Jakou máš vlastně představu, že by to mělo fungovat?

[andy]

V preste je ku kazdej tabulke tabulka _lang

To jako fakt? Ze, je presta tragicky kus SW jsem vedel davno, ale ze az takhle to me prekvapuje.

Su tam aj preklady statickych textov ktore su v xml (nejake ich custom riesenie), ale neviem co tym vyriesili a o korektnosti dost pochybujem. S tym ze je to tragicky kus SW plne suhlasim, ale vraj je to jedno z naj php rieseni, tak to je dost smutne. Funkcne je to ok, ale na korektnost by som nevsadil a technicky to ma zopar pruserov. Javova bokovka na vikend sa ale dost tazko zhana...

[Kit]

Su tam aj preklady statickych textov ktore su v xml (nejake ich custom riesenie), ale neviem co tym vyriesili a o korektnosti dost pochybujem. S tym ze je to tragicky kus SW plne suhlasim, ale vraj je to jedno z naj php rieseni, tak to je dost smutne. Funkcne je to ok, ale na korektnost by som nevsadil a technicky to ma zopar pruserov. Javova bokovka na vikend sa ale dost tazko zhana...

XML jako formát pro ukládání primárních dat není špatný, pro prezentační data také ne. Jen je problém v tom, že bývají různé požadavky pro oba formáty. Při vytváření překladu je pro jednoho překladatele obvykle výhodnější mít pohromadě všechny překlady jednoho výrazu. Pro prezentaci je však dobré je mít uspořádány podle jazyků, nejlépe v samostatných souborech. Naštěstí je možné si snadno udělat konvertor mezi nimi, resp. konvertor XML->databáze.

[andy]

Nejde o to ze je to v xml a tiez to nie je jediny problem toho sw..

[Kit]

Osvědčilo se mi jazykové závislosti v aplikaci vůbec neřešit a přenechat to až výstupní šabloně, která umí se slovníkem v XML pracovat nativně. Šabloně pak pošlu jen data a jazyk, ve kterém mají být prezentována.

Obávám se však, že tohle nebude ten správný případ užití.

[to_je_jedno]

Můžeš používat slova jako primární klíče.

Napis si na to tridu do 65 radku.. a pak resi proc to neni nic moc (omezovat se v tomhle pripadne na varchar by fakt nebylo moc uzivatelsky dobry)

[Kit]

Můžeš používat slova jako primární klíče.

Napis si na to tridu do 65 radku.. a pak resi proc to neni nic moc (omezovat se v tomhle pripadne na varchar by fakt nebylo moc uzivatelsky dobry)

Nevím jak tobě, ale mně na takovou prkotinu stačí polovina, tedy 30 řádek.

[Ondřej Novák]

Díky za rady. Zatím jsem to nechal v organizaci ze v hlavní tabulce mám texty ve výchozím jazyce a ve vedlejší tabulce jsou texty dle jazyka. Každý textový sloupeček z hlavní tabulky tam má svou jazykovou alternativu. V hlavní tabulce nesmí být NULL, naopak v jazykové tabulce je NULL povoleno. NULL pak znamená, že pro konkrétní políčko se použije text z hlavní tabulky.

Při SELECT používám funkci SELECT COALESCE (jazykova.sloupecek, hlavni.sloupecek) FROM hlavni LEFT JOIN jazykova ON jazykova.id = hlavni.id AND jazykova.lang = ?