Multi-language system

[anonīms]

Sveiki. Pašlaik lapa atrodas tādā stāvoklī, ka stringi tiek padoti caur array'u. Tas ir

$lang['menu2'] = 'Izvēlne';

un attiecīgi inklūdots īstais fails include

/languages/en/main.php

.

 

Vēlos kaut kā panākt tā, lai tas viss notiktu ar mysql palīdzību un būtu tulkojams caur adminpaneli. Ļoti simpatizē drupal i18n modulis, bet viņš ir diezgan pasmags un tas laiks nav tik daudz, lai burtos cauri tagad visām rindiņām.

 

Tie, kas nav strādājuši ar drupal, tad īsumā ir tā. Veidojot kodu tas tiek padots caur "t" funckiju, attiecīgi

<? print t('Hello'); ?>

Uzreiz ejot uz adminpaneli "translate" sadaļu šo stringu ir iespējams iztulkot visās valodās. Meklēju līdzīgu veidu kā to varētu panākt.

 

Tīri teorētiski man tas pat nav skaidrs.

Teiksim esmu izdomājis, ka veidošu jaunu tabulu "translations" un attiecīgi kollonas nosaukums būs valoda (en/lv/ru), kur vienā gabalā viss json formātā arī tiks glabāts un tad vienkārši izvadīts.

 

Esmu apstājies pie tā, ka īsti nesaprotu kā panākt, ka šis strings tiek ievietots iekšs db. Idejas līmenī bija veidot kko tādu kā "super botu", kuru palaižot, tas iziet cauri visām t funkcijām, pārbauda vai dati ir db un, ja nav, tad tos pievieno, bet kā panākt, ka viņš teiksim iziet cauri tiem pašiem 100.php failiem, dažādos folderos un vai tas nebūtu "slimi"?

[briedis]

Izmanto GetText. Izsaukšana - echo _("teksts, kas var būt teikums")l

[daGrevis]

Pameklē... bija šāda diskusija, kur pats biju uzrakstījis skaidru paskaidrojumu "how-to" + bars foruma biedru Manu ideju nolikuši (Savā ziņā) un, beigās, kopā - izdomājuši ko vēl labāku!

[Syntetik]

Sveiki, programmisti! :)

 

Es daru tā. Man viss iet uz templeitiem. Kaut kas līdzīgs populārajam template variantam, ko daudzas sistēmas izmanto, bet tā kā man ir alerģija pret visu svešo kodu, tad pašam ir savs, bet ar uzlabojumiem.

 

Templeitā rakstu, piemēram, formas ievadlauku nosaukumus -

{t}Vārds{/t}: input lauks

{t}Uzvārds{/t}: input lauks

 

un inkludu direktorijā ir iespējamo valodu "vārdnīcas", piemēram, lang_eng.inc (jebšu 'lang_'. $_SESSION['lang'] .'.inc', vai ne?! :) ), kas ir apmēram šāds:

$src = array();

$dst = array();

 

$src[] = 'Vārds';

$dst[] = 'Name';

 

$src[] = 'Uzvārds';

$dst[] = 'Lastname';

 

$src[] = 'Vēl viens alus šovakar būs tieši laikā';

$dst[] = 'Another beer tonight will be just in time'; // Google labi iztulkoja, nu ja, kas sirdij tuvāks!!!

u.t.t.

 

Protams, var vēl savādāk, tjipa $src['Vārds'] = 'Name', bet ātruma ziņā iegūst pirmais variants, ja ir ļoti daudz frāžu, jo kodā tieši tajā brīdī, kad sagremo templeitu, ar preg_match atlasu visus pēc šablona {t}kaut kas{/t}, saturu meklēju iekš $src, iegūstu indeksu un ar to izvelku no $dst tulkoto vērtību. Šķiet, ka ar ciparisko indeksu php atrod ātrāk, nekā ar simbolisko, nu, tā vajadzētu būt.

 

Darbojas mērkaķa ātrumā. Un galvenais, ka nenoslogo datubāzi.

 

Protams, ja taisa universālu sistēmu, kur viss ir datubāzē, tad pirmkārt, ir čakaris visu iespējamo iebliezt tabulā, bet nu ja dara, tad dara, otrkārt, templeitā tad jāizmanto kas? - indeksi, kodi, pēc kuriem datubāzē meklēt? Vai arī {t}...{/t} sistēma, bet tad templeita apstrādes brīdī tev uz katru preg_match atrasto frāzi/vārdu ir jātaisa pieprasījums datubāzei un tad jau nav tālu līdz pilnīgam ablomam. Var arī savādāk. Administrēšanu taisa kā priekš datubāzes, bet kad tulkošanas darbi pabeigti, tad ģenerē katrai valodai .inc failu minētā formātā. Principā tāds arī ir vienīgais variants, lai būtu gan ātrdarbība produktā, gan ērtība administrēšanā. Pirmajā reizē var nolasīt templeitu - atlasa visus tulkojamos gabalus un iebliež datubāzē un tad ar CMSu labo un ģenerē .inc failu.

 

Upsss, sanāca visai gari priekš pirmā posta :)

Edited June 29, 2011 by Syntetik

[codez]

Syntetik, ja jau tik tālu esi ticis, ka tev ir templeiti, kurus pārsē, tad jau tikai viens solītis līdz normālam variantam.

Liec visus tulkojumus db un templeitu (user.tpl) iztulko un saglabā tulkoto versiju kā user.tpl.en, user.tpl.lv. Pirms tulkošanas pārbaudi, vai user.tpl mainīšanas laiks ir vienāds ar user.tpl.en, ja vienādi, tad uzreiz padot user.tpl.en, ja nav vienādi, tad iztulko un uzģenerē jaunu user.tpl.en. Respektīvi tev nāksies griezties pie db un tulkot tikai gadījumā, ja izmaini user,tpl failu, visos pārējos gadījumos tu izmantosi jau iztulkotu user.tpl.en failu.

 

Plusi:

1)Ātri, jo tiek izmantoti jau nokešoti tulkoti templeiti.

2)Ērti, jo visi tulkojumi glabājas db.

 

Mīnuss:

1)Vajadzīgs tūlis, kurš izskrien un pārtulko visus tpl failus, gadījumā, ja tpl failu neaiztiec, bet maini tikai tulkojumu db. Bet no otras puses, var vienkār'xsi izdzēst visu kešotos tulkotos templeita failus un tie pie nākamā pieprasījuma tiks uzģenerēti no jauna.

[Syntetik]

...iztulko un uzģenerē jaunu user.tpl.en. Respektīvi tev nāksies griezties pie db un tulkot tikai gadījumā, ja izmaini user,tpl failu, visos pārējos gadījumos tu izmantosi jau iztulkotu user.tpl.en failu.

Jā, bija arī tāda doma tieši tādā izpildījumā, bet parasti tādas pieslīpēānas atstāj uz projekta nogali un tad jau, ja viss iet, var šo izlaist. Vismaz tā vairākas reizes man ir bijis un paliek šāds pusvariants :) Ja tam būtu pieprasījums, tad vēl tā. Piemēram, sistēma, kur uzeris pats veido lapas, izmantojot CMS, tad jā, vajadzētu šo tulkošanu novest līdz galam. Bet mājas lapās un portālos, kādi man ir gadījušies, viss ir bijis programmiski paredzams - vismaz tulkojamās lietas statiskas.

Edited June 30, 2011 by Syntetik