jūsu domas par šo multilanguage sistēmu ..

[Maris-S]

Glabājot saturu atbilstoši valodām datubāzē ir jāuzmanās izmantojot katrai valodai atsevišķu kolonu, izmantojot innodb tabulas ir ierobežojums uz ieraksta izmēru, parasti satura glabāšanai tiek izmantoti text vai varchar datu tipi un izmantojot viņus salīdzinoši ātri var pārsniegt ierobežojumu, gadījumā ja izmanto daudz valodas. Skaitļus no galvas vairs neatceros, ierobežojumus var apskatīties mysql dokumentācijā. Man personīgi šķiet sanāca salasīt 8 vai 11 koloniņas ar text datu tipu, lapai ar 4 valodām un bij nepieciešamība rakstiem saglabāt īso un pilno aprakstu, bet iespējams ka vēl kas bij un kopā salasījās pāri tādām 8 koloniņām. Izmanotjot datu tipus kā int protams koloniņu vajadzēs daudz vairāk, lai pārsniegtu tos limitus.

 

Risinājums glabāt saturu atbilstošajām valodām divkāršsaistītās tabulās (piemēram, id | raksta_id | lang_id | īss_apraksts | raksts), pie tam tādai sistēmai viegli pievienot jaunas valodas, ja tas nepieciešams.

[2easy]

pie tam tādai sistēmai viegli pievienot jaunas valodas, ja tas nepieciešams.

ALTER TABLE content ADD teksts_xxx text

arī ir viegli

[briedis]

Man vislabāk patika kaklz variants ar eksport fīču :)

[Maris-S]

2easy, koloniņu datubāzē protams ka viegli pievienot, bet veidojot sistēmu ar atsevišķu valodu tabulu, kas tiks saistīta ar satura tabulām, domāju ka jebkurš ievadīšanas formas, piemēram, administrācijas sadaļās arī veidos automātiski, balstoties uz valodām kādas ir sistēmā, tātad nevajadzēs programmēt klāt skriptos. Protams tas ir vienkāršajos variantos. Protams var automatizēt formu veidošanu arī pēc koloniņu nosaukumiem, bet nedomāju ka būs droši to darīt.

[2easy]

define('SITE_LNG', 'lv,ru,en,de');

balstoties uz šiem datiem, admin panelī tiek uzģenerēti formas kontroļi ar textarea/wysiwyg priekš katras valodas kontenta. viss automātiski. līdz ar to valodas pievienošana sastāv no:

1) jau augstāk pieminētais ALTER TABLE

2) jāpievieno jaunais valodas id pie jau esošajām valodām 'lv,ru,en,de,xxx'

3) valodas failu folderī ir jāieliek pāris faili ar statiskajiem valodas tekstiem (konstantēm). katrā requestā tiek inklūdoti tikai tie konstanšu faili, kuri tobrīd ir nepieciešami (atkarībā no valodas un no applikācijas - site/cms)

 

thats it!~ so simple. isn't it? ;)

Edited March 11, 2010 by 2easy

[Maris-S]

Un ja mājas lapai ko taisi uz pasūtījumu būs nepieciešama valodas pievienošana no administrācijas sistēmas? Kā lietotājs, kas neko nesaprot no php un viņam arī nevajag saprast php, pārveidos skriptā konstanti?

 

Protams ir vienkārši, arī konstantes modificēšanu var atrisināt kaut vai ini failā ieliekot stringu 'lv|en|ru', ko vēlāk vienkārši saliek masīvā (viens no variantiem). Tomēr šādas metodes neuzskatu par pareizākajiem un ērtākajiem risinājumiem (tikai manas domas, par vienīgo taisnību necenšos strīdēties), bet galvenais jau nav sistēmas organizēšana principā, galvenā doma manam teiktajam (sākumā) bij tieši ieraksta garuma limits innodb tabulām datubāzē (~8000 baiti). Ar laiku mājas lapa var palikt par daudzvalodu sistēmu pie tam ne ar 3, bet 5-10 valodām, kā arī norādīju piemērā man pašam personīgi pietika 4 valodu, lai limitu sasniegtu. Tas protams ir izņēmuma gadījumi un es personīgi par to uzzināju tikai saskaroties ar problēmu, tāpēc ceru kādam šis varētu noderēt.

 

Pamēģināju sataisīt tabulu, kur varētu atkārtot šo kļūdu. Principā var vienkārši izveidot jebkuru tabulu ar vismaz 11 text, longtext, blob vai tāda veida koloniņām (tomēr tai mājas lapai ko taisīju uz katru valodu bij ne tikai īsais un garais apraksts, bet vēl kāds 3. lauks, sen jau taisīju, neatceros). Tekstam jābūt salīdzinoši garam, lai kopēji (vienā ierakstā) pārsniegtu 8000 baitus. Kļūda ko parādīs mysql, ja pārsniegs ieraksta pieļauto garumu: '1030 - Got error 139 for storage engine'. Protams daudziem radīsies loģisks jautājums kāpēc tad var daudz lielākus datus ielikt kaut vai blob laukā, ja ir mazāk par 11 koloniņām. Lieta tāda ka šo tipu lauku dati tikai daļēji tiek glabāti pašā ierakstā, tikai sākums. Sīki nezinu kā realizēta sistēma mysqlam. Kam interesē šeit var palasīt sīkāk: http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html

Edited March 11, 2010 by Maris-S

[2easy]

Un ja mājas lapai ko taisi uz pasūtījumu būs nepieciešama valodas pievienošana no administrācijas sistēmas? Kā lietotājs, kas neko nesaprot no php un viņam arī nevajag saprast php, pārveidos skriptā konstanti?

ja baigi vajag, tad var uzģenerēt formu, kura paņem datus no kāda pašreizējā konstanšu faila, piemēram defaultajai valodai, kur tos var rediģēt un pēc tam saglabā kā jaunu konstanšu failu attiecīgi jaunajai/pievienojamajai valodai. tas nju nav nekas tāds ūber :D:D:D

 

anyway, nav daudz tādu klientu, kas paši to gribētu darīt. vnk klienti vairumā gadījumu ir pārāk slinki :P dažus tekstiņus pamainīt vēl ir gatavi, bet nopietnākas izmaiņas labāk uzticēs tam pašam izstrādātājam ;)

 

Tomēr šādas metodes neuzskatu par pareizākajiem un ērtākajiem risinājumiem (tikai manas domas, par vienīgo taisnību necenšos strīdēties)

vajag, vajag strīdēties! konstruktīvos strīdos dzimst ļoti daudz noderīgas idejas ;)

 

bet galvenais jau nav sistēmas organizēšana principā, galvenā doma manam teiktajam (sākumā) bij tieši ieraksta garuma limits innodb tabulām datubāzē (~8000 baiti).

prrrr. 8K uz visu rindu... tas taču nekas nav! vienam pašam text ir 64KB limits. ja tas tiešām arī saturētu tik daudz datus, tad jau pēc definīcijas to nemaz nevar iedabūt tajā innodb tabulā!!! ta nu gan tolks no tāda innodb...

[Maris-S]

Nedomāju ka Tev pašam pēc gada kādai mājas lapai būs vienkāršāk domāt par tās konstantēm, nekā administrācijas sadaļā (ar paša lielākā administratora paroli) pievienot vienu valodu un augšupielādēt vienu karodziņa attēlu. Lietotāji ne vienmēr ir slinki lai administrētu savu lapu, bieži vien pat lapas būtība ir tāda ka tās saturu jāpapildina dienā vairākas reizes un jāadministrē visu laiku (ziņas, blogi, nekustamie īpašumi, internet veikali, grāmatvedības sistēmas utt.).

 

Strīdēties tiešām nevajag, vajag izteikt savas domas un pamatot tās kāpēc tā domā, citiem atkal, ja ir vēlēšanās, nav jāstrīdas pretī, bet gan jānorāda uz kļūdām un jāpamato tās.

 

Tu neuzmanīgi izlasīji ko es rakstīju. :) Innodb tādus laukus kā text, blob un tml. pašā ierakstā nesaglabā pilnīgi, bet gan tikai sākuma baitus (līdz cik tieši skaitli nezinu), pārējā daļa iet ārpusē (terminus kā tās daļas sauc nezinu), teorētiski lauks ar atbilstošu tipu var sasniegt 4GB. Stipri aptuvens pašā ierakstā saglabājamo datu izmērs varētu būt 8000/11 baiti, jo tieši pie 11 koloniņām var parādīties šīs problēmas, ja katrā no viņām saglabātie dati sasniedz vai pārsniedz šo sākuma baitu lielumu, id koloniņu var šoreiz ignorēt, aprēķini aptuveni un tā ir salīdzinoši maza. Nevarēšu pateikt ko nozīmē "ierakstam ārpusē', tur jālasa mysql struktūras dokumentācija par viņu 'database page" un visām pārējām lietām. Tur ir daudz ko pētīt ja iedziļinās. Varbūt kāds mysql speciālist varēs mūs apgaismot par pašu teoriju kā notiek saglabāšana ierakstos. Personīgi es tik stipri neesmu pētījis, vismaz pagaidām.

Edited March 11, 2010 by Maris-S

[2easy]

Nedomāju ka Tev pašam pēc gada kādai mājas lapai būs vienkāršāk domāt par tās konstantēm, nekā administrācijas sadaļā (ar paša lielākā administratora paroli) pievienot vienu valodu un augšupielādēt vienu karodziņa attēlu.

man tas būs easy gan tā, gan tā ;)

 

Lietotāji ne vienmēr ir slinki lai administrētu savu lapu, bieži vien pat lapas būtība ir tāda ka tās saturu jāpapildina dienā vairākas reizes un jāadministrē visu laiku (ziņas, blogi, nekustamie īpašumi, internet veikali, grāmatvedības sistēmas utt.).

valodas jau gan katru dienu nemainās :P

 

Strīdēties tiešām nevajag

vajag! :D

 

Tu neuzmanīgi izlasīji ko es rakstīju. :)

tas bija apzināti ;) gribēju, lai vēl kāds kko vairāk pastāsta: pretpiemērus... citu pieredzi...

[black]

Vēl aizmirsu piebilst par iespējamo čakri ar daudzskaitļa formām. Kā aprakstīts http://www.gnu.org/software/hello/manual/gettext/Plural-forms.html, tikai angļu valodā daudzskaitli veido, vienskaitlim pievienojot s. Tas nozīmē, ka tulkošanas sistēmai būtu jāuztur dažādas daudzskaitļa formas.

 

Piemērs kā poļi loka vārdu fails (no linka):

1 plik

2,3,4 pliki

5-21 pliko'w

22-24 pliki

25-31 pliko'w

 

Tas vērā ņemami sarežģī masīva (vai datubāzes, vai dajebkā cita) struktūru. Piemēram, funkcijai, kas tulko, kā parametrs jāpadod arī skaitlis, kā arī - katrai valodai jādefinē funkcija, kas atkarībā no skaitļa atgriezīs pareizo tulkojuma formu. Glabājot datus datubāzē, tas nozīmē pie katra tulkojuma glabāt arī locījuma formas id, utt.

Edited March 11, 2010 by black

[2easy]

nu tu gan pārcenties! glabāt vajag tikai tās frāzes, kuras ir jārāda lapā, nevis katru vārdu locīt visos iespējamos veidos

[rATRIJS]

Nu kaut kādu locīšanu jau vajag :)

 

Kaut vai:

- 1 komentārs

- 5 komentari

 

Un ja locīšanas noteikumi pa valodām atšķiras + mainās, tad jau tas visu var sarežģīt.

[2easy]

vienskaitlis/daudzskaitlis tas jau ir sīkums. kad tulks ir iztulkojis, visu ko vajag, tad atliek vien paņemt

$i % 10 == 1 && $i % 100 != 11 ? OBJ_VIENSK : OBJ_DAUDZSK;

prikolīgi, ka lv valodā ir 1 komentārs, 11 komentāri, un pēc tam atkal 21 komentārs, 31 komentārs, ... , un pēc kāda laiciņa atkal 111 komentāri :D:D:D

Edited March 11, 2010 by 2easy

[rATRIJS]

Paskaties ko black uzrakstīja par poļu valodu :)

 

Tātad funkcijai daudzskaitļotājs jātaisa vairākas implementācijas skatoties kāda ir valoda :)

[briedis]

vienskaitlis/daudzskaitlis tas jau ir sīkums. kad tulks ir iztulkojis, visu ko vajag, tad atliek vien paņemt

$i % 10 == 1 && $i % 100 != 11 ? OBJ_VIENSK : OBJ_DAUDZSK;

prikolīgi, ka lv valodā ir 1 komentārs, 11 komentāri, un pēc tam atkal 21 komentārs, 31 komentārs, ... , un pēc kāda laiciņa atkal 111 komentāri :D:D:D

 

Atrisināsim to vienkārši, piemēram pie video - Šim video pēdējais komentārs ir pirmais(otrais, vienpadsmitais, divdesmitais) :))

 

Bet vispār tas, ka locījumi katrā valodā savādāki reāli sucks...

Edited March 11, 2010 by briedis