[DISC] Hoe applicatie internationaliseren?

Ik vermoed dat je best je afkortingen kan gebruiken als standaardtaal in gettext, zodat je het beste van gettext en de kortere labels kunt combineren.

Code moet je in mijn ogen documenteren met comments, en niet met de teksten die op het scherm van de gebruiker landen. Die laatste zijn volgens mij ook vaak een simplificatie van wat er gebeurt. Hierdoor ontstaat het risico dat je informatie over de werking van je code weg gaat laten. Ik ben zelf dus veeleerder geneigd om een language array / object te maken .

Mijn vorige post was niet erg volledig, aangezien het vooral een negatie van een van de vermeende voordelen van de helestring-methode is. Desalniettemin neig ik persoonlijk naar een language array / object. Ik vind het niet de verantwoordelijkheid van een functie / class om te bepalen hoe een error message woordelijk in elkaar zit, maar veeleerder van de presenterende kant. Maar uiteindelijk denk ik dat je volledig gelijk hebt dat het vooral een voorkeur-iets is.

Ik denk niet dat je code onoverzichtelijker wordt van langere strings. Je code wordt er ook niet onoverzichtelijker van als je methode-namen langer dan 8 characters gebruikt

Wat imho wel van belang is is dat je de codes structureert. Bijvoorbeeld door de code te prefixen met het object waar de string betrekking op heeft, en een aantal algemene prefixes (cache, database, input, etc.). Daarnaast de waarden van de codes in een extern bestand zodat de teksten herbruikbaar zijn over je code-bestanden heen. Verder is het parametriseren van je teksten ook wel handig, dan hoef je niet elke keer dezelfde tekst te typen.

Als je kijkt naar de code van phpGroupware dan zie je dat ze daar nog een ander systeem gebruiken: alle strings en vertalingen zijn opgenomen in de backend database. Op zich is daar wel wat voor te zeggen: PHP hoeft niet alle strings tig keer in het geheugen te hebben en je kan redelijk eenvoudig extra strings en talen toevoegen.

Het nadeel van je vertalingen in een database, is de hogere load op je database server indien de pagina druk bezocht wordt. Je zou een XML file kunnen gebruiken, met daarin de vertalingen. Zoals al eerder gezegd, het is een kwestie van voorkeur

Manuzhai schreef op zondag 04 maart 2007 @ 09:44:
Ik vermoed dat je best je afkortingen kan gebruiken als standaardtaal in gettext, zodat je het beste van gettext en de kortere labels kunt combineren.

Erm, en wat nou als er geen definitie is voor die afkorting, i.e. geen vertaling is voor die afkorting. Dan valt gettext toch terug op die afkorting, en geeft die weer afaik. Kun je dan niet beter gewoon bij english human readable strings blijven, zodat in het ergste geval teruggevallen wordt op die engelse string.

Ik heb in een vrij groot programma (zeg 50.000 regels code, al zegt dat niet zoveel natuurlijk) een systeem opgezet voor internationalisering. Alleen voor het vertalen van teksten in de UI overigens, er komt nog meer kijken bij 'echte' i18n natuurlijk (denk aan datums, tijdzones... het kan zo lastig als je zelf wil... en wat dacht je van telwoorden: 1 bericht, twee berichten is al lastig, en er schijnen talen te zijn waar ze tot een stuk of 5 verschillende 'meervouden' hebben...).

Anyway wat ik heb: per string roep ik een functie TL(keyword) aan, dus TL("browser_page_not_found") met inderdaad een prefix om aan te geven op welk onderdeel het van betrekking is. Voor het bijhouden van de onderlinge verschillen tussen de taalfiles maak ik een van de lijsten mijn 'hoofd'-taal waarin ik meteen de strings toevoeg als ik ze gebruik in de code (op dit moment de Nederlandse). Met een script laat ik dan uitzoeken welke er nog ontbreken in de andere taalbestanden en voeg ik die toe

Wat ik maar wil zeggen is dat er meer bij komt kijken dan je denkt... Het steeds ophalen van die taalstrings is overigens wel traag natuurlijk, maar met een nette hashtable is het wel op te lossen. Het steeds aanspreken van de database introduceert extra tijd door de latency tussen database-server (ook al is het localhost) en je web-server, het parsen van de query, het uitvoeren etc... dat kun je zelf dus een stuk efficienter maken door gewoon (in het geval van PHP) een bestand weg te schrijven met daarin een array "key" => "string" per taal. Per taal een bestand maken en dat includen afhankelijk van de taalkeuze lijkt mij het meest performant eigenlijk...

Verwijderd schreef op maandag 05 maart 2007 @ 18:31:
[...]

Ik denk overigens dat naarmate je applicatie uitgebreider wordt, het minder makkelijk wordt om unieke keywords te verzinnen.

Als je twee taalstrings hebben die hetzelfde keyword zouden moeten hebben moet je volgens mij gaan nadenken of die twee strings niet hetzelfde 'bedoelen'. Als dat zo is moet je ze samenvoegen. Ik heb hier een programma dat gebruik maakt van veel plug-ins; iedere plug-in heeft z'n eigen vertaalbestanden. Door het hele programma door wordt het begrip 'tijdbalk' gebruikt, ik hoef in die gevallen niet steeds plugin1_timeline, plugin2_timeline etc te maken, maar ik maak gewoon een 'gedeeld' bestand met één key 'timeline' erin

In het voorbeeld dat je geeft zou je kunnen kiezen voor een algemene key 'send' of 'save' ("Bericht opslaan" is duidelijk genoeg voor zowel een forumpost als een artikel) maar aangezien er kennelijk een verschil tussen is zijn twee verschillende keys gerechtvaardigd: save_forum_post en save_article, ofzo

Ik hou er zelf overigens van om als key een verkorte versie van de Engelse tekst te pakken, dus edit_forum_post in plaats van forum_post_edit_button_text of iets dergelijks. Als je dan gaat vertalen blijft de 'bedoeling' van het origineel tenminste nog enigszins behouden

Wat bedoel je met "parametriseren van je teksten"?

Ik vermoed dat hij templating bedoeld. Iets in de richting van:



Dat is ook bij i18n aan de orde (en bij ingewikkeldere teksten ontkom je daar misschien niet eens aan), maar voor het doel van de TS lijken me statische strings genoeg

[ Voor 18% gewijzigd door MisterData op 05-03-2007 22:23 ]

MisterData schreef op maandag 05 maart 2007 @ 22:19:

Ik vermoed dat hij templating bedoeld. Iets in de richting van:

code:

1 2 3

Beste $geslacht $achternaam, Graag bevestigen we uw bestelling met nummer $nummer. Uw pakketje is op de post gedaan en zal naar verwachting op $datum aankomen.

Dat is ook bij i18n aan de orde (en bij ingewikkeldere teksten ontkom je daar misschien niet eens aan), maar voor het doel van de TS lijken me statische strings genoeg

Idd. Zie bijvoorbeeld http://struts.apache.org/...tring,%20java.lang.Object[])

Je gebruikt in je voorbeeld voor je parameters argumenten die niet meertalig zijn, maar het krachtige is juist dat je ook parameters kan gebruiken die zelf ook weer meertalig zijn.

[ Voor 13% gewijzigd door CubicQ op 06-03-2007 19:53 . Reden: Ik geef het op, ik kan gewoon niet overweg met het plaatsen van URL's op GoT :) ]

CubicQ schreef op dinsdag 06 maart 2007 @ 19:48:
[...]


Ik vermoed dat hij templating bedoeld. Iets in de richting van:

code:

1 2 3

Beste $geslacht $achternaam, Graag bevestigen we uw bestelling met nummer $nummer. Uw pakketje is op de post gedaan en zal naar verwachting op $datum aankomen.

Daar heb je toch de equivalenten voor van sprintf

MueR schreef op maandag 05 maart 2007 @ 00:00:
Het nadeel van je vertalingen in een database, is de hogere load op je database server indien de pagina druk bezocht wordt. Je zou een XML file kunnen gebruiken, met daarin de vertalingen. Zoals al eerder gezegd, het is een kwestie van voorkeur

nee dat geeft een leuke load op je server, telkens die XML gaan parse kost denk ik heel wat meer cpu-cycles dan een paar extra query's over een database verbinding die er toch al is. nog maar niet te spreken over I/O die je op je filesysteem neerlegt.

XML != database en moet dan ook niet als dusdanig worden gebruikt.

@TS
Ik denk dat het belangrijkste is dat je je presentatie-laag gescheiden houdt van de applicatie laag. dus als het goed is heb je al een functie die verantwoordelijk is voor het presenteren van tekst op het scherm zoniet maak er een.

bijvoorbeeld een functie die 2 parameters heeft, 1 is de tekst en de 2 de 2-letterige taal-code. dan plaats je voor elke $tekst een 5 letterige code gevolgt door een punt-comma bijvoorbeeld.


vervolgens kun je in een backend zoals een mysql database de vertaling ophalen en weergeven of doorsturen naar de werkelijke weergave functie. ook kun je het zo maken dat bijvoorbeeld alleen de $tekst_id al genoeg is zodat ook e.v.t spell foutjes worden gecorriceer bijgegaan door een E_USER_NOTICE zodat je je code kunt verbeteren.

ook zou je met % tekens en patterns de waarden kunnen invoegen in ander tallen zodat bijvoorbeeld "Kan bestand php.pdf niet openen" waarbij je dan in je backend opslaat "Kan bestand %f niet openen" met als vertaling "Failed to open file %f.". je script kan dan bijvoorbeeld automatische het 3e woord in de nederlandse melding vervangen met het 5e woord in de engelse vertaling zodat ook waardes in andere talen automatische worden ingevoegd.

meede daarom gebruik je een 5 alphanumerieke code aan het begin van elke aanroep zodat het script weet dat "Kan bestand php.pdf niet openen" en "Kan bestand gtk.pdf niet openen" het zelfde bericht zijn met een andere waarde. mogelijk zou je ook een pattern kunnen gebruiken om het verschill te vinden maar dan weet je script niet meer dat "Failed to open file php.pdf" en "Kan bestand gtk.pdf niet openen" eigenlijk het zelfde bericht zijn en dus de zelfde vertaling gebruiken.

een database kan handig zijn in dit geval maar een oplossing met simpele comma-delimitted tekst-file's werkt zeker ook goed. gewoon voor elke taal 1 bestand met voor elke stukje tekst dat vertaald moet worden 1 regel. vergeet dus niet line-breaks te escapen. en dan op elke regel het formaat: tekst_id;optie1;optie2;vertaling;

dit soort bestanden zijn snel in te leezen en hoef je eigenlijk alleen maar te exploden en klaar. alleen als het erg veel vertalingen gaat, zeg >100Kb dan kan een database sneller zijn ook omdat die middels slimme caching de antwoorden in het geheugen houden en je script dus niet alle vertaalingen in het geheugen hoeft te houden en bij elke page-view opnieuw moet inlezen.

ik denk dat dit de meest gebruikte methode is of een variant in deze richting. en zoals altijd hangt het heel erg af van wat je precies wilt vertallen. als het om een keer 100 statische zinnen gaat dan is soms de tekst file optie zinvoller of gewoon een search&replace op de broncode maar als het om meer dan 100 zinnen gaat of zinnen waar ook variable waarde's in voorkomen dan wordt het lastig en werkt de bovenstaande methode veel flexiebeler ook omdat je elke mogelijke taal kan toevoegen, zeker als je gebruik maakt van de multi-byte extensie voor niet westerse tekens in je presentatie laag.

Ik gebruik zelf includes met language.$taal.inc.php. Hierin staan dan strings in deze layout:


Deze worden dan via een functie die onder andere deze code bevat aangeroepen:


Vast wel voor verbetering vatbaar, maar voor mij werkt het prima.

Nee, de lengte van die dingen gaat echt niet je applicatie traag maken. En als je het zo nodig exact wilt weten dan benchmark je toch gewoon? Ik denk dat het gewoon onderhoudbaar houden van je code/teksten een veel betere investering is, dan het "optimaliseren" van wat strings.

Waarom gebruik je eigenlijk '%s', vraag ik me zo af...?

Verwijderd schreef op woensdag 07 maart 2007 @ 18:33:

Bedoel je hiermee dat jouw voorkeur naar de methode met ARRAY_KEYS uitgaat (omdat alle strings dan onder elkaar in 1 bestand staan ipv verspreid door de code)?

Waar de strings vandaan komen interesseert mij eigenlijk vrij weinig. Je programmeert als het goed is tegen een interface aan die vertaalde berichten teruggeeft. Wat daar allemaal achter zit zal wel, voor wat betreft de applicatie. Dat is iets wat intern op honderden manieren kan. Je kunt includes gebruiken met arrays met mappings, je kunt iets als gdbm gebruiken, ini files, een database, whatever. Het inlezen van die gegevens duurt slechts een fractie van een seconde, snel genoeg om er geen last van te hebben. En of je in je code dan "preview_button" of "Preview this message" hebt staan boeit mij ook vrij weinig.

Dat was een slecht voorbeeld. Ik zou construcites gebruiken als:

PHP:

1 2 3

function foo($module) { echo t("The %module settings are updated", array('%module' => $module->name)); }

Misschien was mijn vraag een beetje scheef. Waarom gebruik je wel '%s' maar niet (v)(s)printf? Kun je meteen de parameters formateren mocht dat nodig zijn.
Waarom omslachtige replace functies gebruiken in plaats van de razendsnelle printf functies?

Verwijderd schreef op woensdag 07 maart 2007 @ 19:26:
[...]

Ik gebruik een strtr ipv sprintf omdat sprintf alleen bepaalde type specifiers aanvaardt, terwijl strtr alle soorten tokens vervangt. Ik de string kun je dan meer zin geven aan bepaalde tokens. Vergelijk:

PHP:

1 2 3

$string = 'Bedankt voor uw aanmelding op %forumnaam, %user!'; $string = 'Bedankt voor uw aanmelding op %s, %s!';

Dan geeft de eerste methode (%forumnaam, %user) meer context dan %s, %s!

Dus maak je een eigen functie die ELKE keer als je hem oproept opnieuw de talen moet inlezen?
Ik vind de format functies handig, en ze werken lekker snel. Maar als je een eigen functie maakt zorg dan in elk geval dat hij efficient is..



Het is misschien minder duidelijk zoals je zelf aangeeft, maar op het moment dat vertaald wordt heb je al een voorbeeld string zodat je weet waarmee het vervangen zou kunnen worden. Zeker als je ook de applicatie erbij houdt.

Om de discussie niet offtopic te brengen, ik gebruik zelf gettext in combinatie met sprintf. Ik weet niet of het ook echt zo is (vast wel), maar ik heb gewoon meer vertrouwen in pre-compiled modules die niet elke keer opnieuw geïnterpreteerd hoeven te worden, en het werkt uitstekend, de gettext taal bestanden zijn enorm duidelijk imho.

Maar ik vertaal alles dan ook zelf en gebruik alleen Nederlands en Engels voor mijn applicaties omdat als ik een andere taal aanbied ik ook vind dat ik er ondersteuning in moet kunnen bieden, en dat kan ik nou eenmaal niet.

Waar ik benieuwd naar ben: kan iemand mij vertellen welke methode React gebruikt? Ik heb net MyReact gedownload om te kijken, maar alle classes / php bestanden zijn geencrypt. Ik zie geen aparte language files. Betekent dit, dat er in de code volledige taalstrings staan?

Reveller schreef op zaterdag 17 maart 2007 @ 19:23:
Waar ik benieuwd naar ben: kan iemand mij vertellen welke methode React gebruikt? Ik heb net MyReact gedownload om te kijken, maar alle classes / php bestanden zijn geencrypt. Ik zie geen aparte language files. Betekent dit, dat er in de code volledige taalstrings staan?

Die kun je weldegelijk vinden:

Volgens mij gebruiken ze gewoon gettext.

[ Voor 3% gewijzigd door G33rt op 18-03-2007 19:49 ]