Valodu maiņa mysql

[jurchiks]

hmm nu nezinu gan vai uz katru tekstu kuram vajag tulkojumu ir prātīgi vērsties pie datubāzes, cik tad daudz pieprasījumu datubāzei būs jāapstrādā. Kaut kā noteikti var arī savādāk teiksim izvēlētai valodai tulkojumus turēt atmiņā.

Persistent connection, query cache, prepared statements.

Gribi in-memory cache - izmanto Redis vai ko tamlīdzīgu.

Jebkurā gadījumā, izmantot teksta failus dinamisku tulkojumu glabāšanai, ja tie tiek tulkoti caur webu, IMHO ir vienkārši debīli.

gettext vispār man liekas reāli neparocīgs + morāli novecojis.

[Kavacky]

Jā, priekš tulkojumu masīva uzturēšanas gettext ir morāli novecojis, taču PREPARED NAHUJ STATEMENTS - tas ir ok.

[daGrevis]

Gettext alternatīvas? Problēma ar gettext ir, ka nevar nomainīt aktīvo bakendu, kurš vienmēr būs kešots .mo (kompilēts .po), bet gribu Redis ar fallbacku uz RDBM!

[codez]

Labi, ka scalā un play man nav ar to problēmas. Uz servera startupu ielādēju visus tulkojumus hashmapā, kurš tālāk jau pieejams katrā kverijā.

Izveidoju funkcijas t un tn, pārtranslēju standarta tn formulas nepieciešamajām valodām un varu dzīvot laimīgs, jo

šādā veidā man tulkojums tiek ņemts no atmiņas (pat bez requesta mem db kā redis vai memcache) un tulkojumi netiek lādēti katru reizi.

Ja tulkojumi mainās servera darbības laikā un tos ir nepieciešams atjaunot, var vienkārsi izsaukt ielādēšanu vēlreiz - kad un kā, tas jau pēc vajadzības.

[jurchiks]

Javā/Scalā tad loģiski, ka tādu problēmu nav.

 

@Kavacky - kas tev nepatīk prepared statementos? Baigi patīk rakstīt "SELECT " . implode(', ', $columns) . " FROM $table WHERE $wheres"?

Šajā gadījumā es prepared statements minēju tāpēc, ka citādi būtu problēmas ar query cache, ja katrs kverijs ir ar jau iekļautiem mainīgajiem tā vietā, lai tos baindotu caur prepared statement interfeisu.

Edited October 18, 2013 by jurchiks

[Kavacky]

Kādas viņa projektā varētu būt problēmas ar kešu?

[Kasspars]

Persistent connection, query cache, prepared statements.

Gribi in-memory cache - izmanto Redis vai ko tamlīdzīgu.

Jebkurā gadījumā, izmantot teksta failus dinamisku tulkojumu glabāšanai, ja tie tiek tulkoti caur webu, IMHO ir vienkārši debīli.

gettext vispār man liekas reāli neparocīgs + morāli novecojis.

 

Aha, gettext, kurš ir mega ātrs un praktiski resursu nerijošs formāts, kurš atbalsta Plural formas, kuram ir sprintf sintakse ir novecojis un neparocīgs. Savukārt katra tulkojamā labeļa izvilkšana no db ir ideāls risinājums. Turpini tādā garā, ir interesanti palasīt

[jurchiks]

Ģēnij, runa iet par CMS ar teksta tulkošanu, nevis par statiskiem tekstiem.

[daGrevis]

Es runāju par abiem — gan CMS tekstu tulkošanu (blograkstiem valodas), gan pārējā tulkošana (pogu nosaukumi, viss, kas ir dizainā, utt.).

[codez]

ja runa ir par contenta tulkošanu, tad kāda problēma ir to glabāt db?

Manuprāt, jebkurā prātīgā sistēmā contents glabāsies db, vienalga, vienā vai daudzas valodās.