Een paar overwegingen:
Wie gaat de vertalingen doen? Mensen die ook verbonden zijn met de site? Een vertaalbureau? Bij het gebruik van Gettext werk je met 'pot' (.po) bestanden. Deze bestanden bevatten de bericht-ID en de berichtreeks (de vertaling). Voorbeeld:
msgid "A string to be translated would go here"
msgstr ""Dit ziet er prima en begrijpelijk uit voor iedereen die dit moet vertalen. Maar wat gebeurt er als je trefwoorden gebruikt, zoals Mike suggereert, in plaats van volledige zinnen? Als iemand een bericht met de naam "address_home" moet vertalen, heeft hij of zij geen idee of dit een koptekst "Thuisadres" moet zijn of dat het een volledige zin is. Zorg er in dit geval voor dat u opmerkingen aan het bestand toevoegt vlak voordat u de gettext-functie aanroept, zoals:
/// This is a comment that will be included in the pot file for the translators
gettext("ready_for_lost_episode");
xgettext --add-comments=/// gebruiken bij het maken van de .po-bestanden zullen deze opmerkingen worden toegevoegd. Ik denk echter niet dat Gettext op deze manier bedoeld is. Ook als u opmerkingen moet toevoegen met elke tekst die je wilt weergeven zul je a) waarschijnlijk ooit een fout maken, b) je hele script wordt toch gevuld met de teksten, alleen in commentaarvorm, c) de opmerkingen moeten direct boven de Gettext worden geplaatst functie, wat niet altijd handig is, afhankelijk van de positie van de functie in je code.
Zodra uw site (nog verder) groeit en uw taalbestanden meegroeien, kan het behoorlijk moeilijk worden om alle verschillende vertalingen op deze manier te onderhouden. Elke keer dat je een tekst toevoegt, moet je nieuwe bestanden maken, de bestanden naar vertalers sturen, de bestanden terug ontvangen, ervoor zorgen dat de structuur nog intact is (gretige vertalers zijn altijd blij om de syntaxis ook te vertalen, waardoor het hele bestand onbruikbaar :)), en eindig met het importeren van de nieuwe vertalingen. Het is zeker te doen, maar houd rekening met mogelijke problemen op dit gebied met grote sites en veel verschillende talen.
Een andere optie:combineer uw 2e en 3e alternatief:
Persoonlijk vind ik het handiger om de vertaling te beheren met een (eenvoudig) CMS, de variabelen en vertalingen in een database te houden en de relevante teksten zelf naar taalbestanden te exporteren:
- variabelen aan de database toevoegen (bijvoorbeeld:id, pagina, variabele);
- vertalingen aan deze variabelen toevoegen (bijv.:id, varId, taal, vertaling);
- selecteer relevante variabelen en vertalingen, schrijf ze naar een bestand;
- neem het relevante taalbestand op in uw site;
- maak je eigen functie om een variabele tekst weer te geven:
text('var'); of misschien iets als __('faq','register','lost_password_text');
Punt 3 kan zo simpel zijn als het selecteren van alle relevante variabelen en vertalingen uit de database, ze in een array plaatsen en de geserlialiseerde array naar een bestand schrijven.
Voordelen:
-
Onderhoud. Bij grote projecten kan het onderhouden van de teksten een stuk makkelijker zijn. U kunt variabelen groeperen op pagina, secties of andere delen van uw site, door simpelweg een kolom aan uw database toe te voegen die definieert tot welk deel van de site deze variabele behoort. Op die manier kun je snel een lijst opvragen van alle variabelen die worden gebruikt in b.v. de pagina met veelgestelde vragen.
-
vertalen. U kunt de variabele met alle vertalingen van alle verschillende talen op één pagina weergeven. Dit kan handig zijn voor mensen die teksten tegelijkertijd in meerdere talen kunnen vertalen. En het kan handig zijn om andere vertalingen te bekijken om een gevoel voor de context te krijgen, zodat de vertaling zo goed mogelijk is. U kunt ook de database doorzoeken om erachter te komen wat er is vertaald en wat niet. Voeg misschien tijdstempels toe om mogelijke verouderde vertalingen bij te houden.
-
Toegang. Dit hangt af van wie er gaat vertalen. U kunt het CMS inpakken met een simpele login om zo nodig toegang te verlenen aan mensen van een vertaalbureau en hen alleen toe te staan bepaalde talen of zelfs bepaalde delen van de site te wijzigen. Als dit geen optie is, kunt u de gegevens nog steeds uitvoeren naar een bestand dat handmatig kan worden vertaald en later kan worden geïmporteerd (hoewel dit met dezelfde problemen kan komen als eerder vermeld). U kunt een van de reeds bestaande vertalingen (Engels of een andere hoofdtaal) als context voor de vertaler toevoegen.
Al met al denk ik dat je op deze manier veel meer controle over de vertalingen zult hebben, vooral op de lange termijn. Ik kan je niets vertellen over de snelheid of efficiëntie van deze aanpak in vergelijking met de native gettext-functie. Maar, afhankelijk van de grootte van de taalbestanden, denk ik niet dat het een groot verschil zal zijn. Als u de variabelen per pagina of sectie groepeert, kunt u altijd alleen de vereiste onderdelen opnemen.