Hoe maak je een meertalige App: een Demo met PHP en Gettext
of u nu een website of een volwaardige webapplicatie bouwt, waardoor deze toegankelijk is voor een breder publiek, vereist vaak dat deze beschikbaar is in verschillende talen en locales.
fundamentele verschillen tussen de meeste menselijke talen maken dit allesbehalve gemakkelijk. De verschillen in grammatica regels, taal nuances, datumformaten, en meer te combineren om lokalisatie een unieke en formidabele uitdaging.
beschouw dit eenvoudige voorbeeld.
regels voor meervoud in het Engels zijn vrij eenvoudig: je kunt een enkelvoud van een woord of een meervoud van een woord hebben.
in andere talen, echter – zoals Slavische talen – zijn er twee meervoudsvormen naast de enkelvoudsvorm. U kunt zelfs talen vinden met in totaal vier, vijf of zes meervoudsvormen, zoals in het Sloveens, Iers of Arabisch.
de manier waarop uw code is georganiseerd, en hoe uw componenten en interface zijn ontworpen, speelt een belangrijke rol bij het bepalen hoe gemakkelijk u uw toepassing kunt lokaliseren.
internationalisatie (i18n) van uw codebase, helpt ervoor te zorgen dat het kan worden aangepast aan verschillende talen of regio ‘ s met relatief gemak. Internationalisering gebeurt meestal een keer, bij voorkeur in het begin van het project om te voorkomen dat enorme veranderingen in de broncode op de weg.
zodra uw codebase is geïnternationaliseerd, lokalisatie (l10n) wordt een kwestie van het vertalen van de inhoud van uw applicatie naar een specifieke taal/lokale.
lokalisatie moet worden uitgevoerd telkens wanneer een nieuwe taal of regio moet worden ondersteund. Ook, wanneer een deel van de interface (met tekst) wordt bijgewerkt, nieuwe inhoud beschikbaar komt – die vervolgens moet worden gelokaliseerd (dat wil zeggen, vertaald) naar alle ondersteunde locales.
in dit artikel zullen we leren hoe software geschreven in PHP te internationaliseren en te lokaliseren. We gaan door de verschillende implementatieopties en de verschillende tools die tot onze beschikking staan om het proces te vergemakkelijken.
Tools for Internationalization
de makkelijkste manier om PHP software te internationaliseren is door array bestanden te gebruiken. Arrays zullen worden gevuld met vertaalde strings, die vervolgens kunnen worden opgezocht vanuit templates:
<h1><?=$TRANS?></h1>
Dit is echter nauwelijks een aanbevolen manier voor serieuze projecten, want het zal zeker leiden tot onderhoudsproblemen op de weg. Sommige problemen kunnen zelfs in het begin verschijnen, zoals het gebrek aan ondersteuning voor variabele interpolatie of meervoud van zelfstandige naamwoorden en ga zo maar door.
een van de meest klassieke tools (vaak gebruikt als referentie voor i18n en l10n) is een UNIX tool genaamd Gettext.
hoewel het dateert uit 1995, is het nog steeds een uitgebreid hulpmiddel voor het vertalen van software die ook gemakkelijk te gebruiken is. Hoewel het is vrij gemakkelijk om te beginnen met, het heeft nog steeds krachtige ondersteunende tools.
Gettext is wat we zullen gebruiken in dit bericht. We presenteren een geweldige GUI-applicatie die kan worden gebruikt om uw l10n-bronbestanden eenvoudig bij te werken, waardoor de noodzaak om te gaan met de opdrachtregel wordt vermeden.
bibliotheken om het gemakkelijk te maken
er zijn belangrijke PHP web frameworks en bibliotheken die Gettext en andere implementaties van i18n ondersteunen. sommige zijn gemakkelijker te installeren dan anderen, of sport extra functies of ondersteunen verschillende i18n-bestandsformaten. Hoewel in dit document, we richten ons op de tools die met de PHP core, hier is een lijst van enkele anderen het vermelden waard:
-
oscarotero / Gettext: Gettext-ondersteuning met een objectgeoriënteerde interface; bevat verbeterde helperfuncties, krachtige extractors voor verschillende bestandsformaten (sommige niet ondersteund door het
gettext
Commando). Kan ook exporteren naar formaten dan alleen. mo/. po-bestanden, die handig kan zijn als u nodig hebt om uw vertaling bestanden te integreren in andere delen van het systeem, zoals een JavaScript-interface. -
symfony / translation: ondersteunt veel verschillende formaten, maar raadt aan uitgebreide XLIFF ‘ s te gebruiken. bevat geen helperfuncties of een ingebouwde extractor, maar ondersteunt placeholders die
strtr()
intern gebruiken. -
zend / i18n: Ondersteunt array-en INI-bestanden, of Gettext-formaten. Implementeert een caching laag om te voorkomen dat het bestandssysteem elke keer te lezen. Bevat ook view helpers, en locale-aware invoerfilters en validators. Echter, het heeft geen bericht extractor.
andere frameworks bevatten ook i18n-modules, maar die zijn niet beschikbaar buiten hun codebases:
-
Laravel: ondersteunt basic array bestanden; heeft geen automatische extractor maar bevat een
@lang
helper voor template bestanden. -
Yii: Ondersteunt array, Gettext, en database-gebaseerde vertaling, en bevat een berichten extractor. Ondersteund door de
Intl
extensie, beschikbaar sinds PHP 5.3, en gebaseerd op het ICU project. Dit stelt Yii in staat om krachtige vervangingen uit te voeren, zoals het spellen van nummers, het formatteren van datums, tijden, intervallen, valuta en ordinalen.
als je besluit om te gaan voor een van de bibliotheken die geen extractors bieden, wil je misschien de Gettext formaten gebruiken, zodat je de originele Gettext toolchain kunt gebruiken (inclusief Poedit) zoals beschreven in de rest van het hoofdstuk.
gettext installeren
het kan nodig zijn om Gettext en de bijbehorende PHP bibliotheek te installeren met behulp van uw pakketbeheerder, zoals apt-get of yum. Nadat het is geà nstalleerd, activeer je het door extension=gettext.so
(Linux/Unix) of extension=php_gettext.dll
(Windows) toe te voegen aan je php.ini
bestand.
hier zullen we ook Poedit gebruiken om vertaalbestanden aan te maken. Je zult het waarschijnlijk vinden in de package manager van je systeem; het is beschikbaar voor Unix, Mac en Windows en kan ook gratis worden gedownload op de website.
typen Gettext-bestanden
er zijn drie bestandstypen waarmee u gewoonlijk te maken krijgt tijdens het werken met Gettext.
de belangrijkste zijn PO (Portable Object) en MO (Machine Object) bestanden, de eerste is een lijst van leesbare “vertaalde objecten” en de tweede is de bijbehorende binaire (te interpreteren door Gettext bij het uitvoeren van lokalisatie). Er is ook een POT (Po Template) bestand, dat gewoon bevat alle bestaande sleutels van uw bronbestanden, en kan worden gebruikt als een gids voor het genereren en bijwerken van alle PO-bestanden.
de sjabloonbestanden zijn niet verplicht; afhankelijk van de tool die u gebruikt om l10n te doen, zult u prima met alleen PO/MO bestanden. Je hebt één paar PO / MO bestanden per taal en regio, maar slechts één POT per domein.
domeinen scheiden
er zijn enkele gevallen, in grote projecten, waar u vertalingen moet scheiden wanneer dezelfde woorden in verschillende contexten een andere betekenis hebben.
in die gevallen moet je ze splitsen in verschillende “domeinen”, die in principe groepen van POT/PO/MO bestanden worden genoemd, waarbij de bestandsnaam het genoemde vertaaldomein is.
kleine en middelgrote projecten gebruiken meestal, voor de eenvoud, slechts één domein; de naam is willekeurig, maar we zullen “main” gebruiken voor onze codevoorbeelden.
in Symfony-projecten worden bijvoorbeeld domeinen gebruikt om de vertaling voor validatieberichten te scheiden.
Locale Code
een locale is gewoon een code die een versie van een taal identificeert. Het is gedefinieerd volgens de ISO 639-1 en ISO 3166-1 alpha-2 specificaties: Twee kleine letters voor de taal, optioneel gevolgd door een underscore en twee hoofdletters die het land of de regionale code identificeren.
voor zeldzame talen worden drie letters gebruikt.
voor sommige sprekers lijkt het landgedeelte overbodig. In feite hebben sommige talen dialecten in verschillende landen, zoals Oostenrijks Duits (De_at) of Braziliaans Portugees (pt_BR). Het tweede deel wordt gebruikt om onderscheid te maken tussen deze dialecten – als het niet aanwezig is, wordt het beschouwd als een “generieke” of “hybride” versie van de taal.
mappenstructuur
om Gettext te gebruiken, moeten we ons houden aan een specifieke mappenstructuur.
eerst moet u een willekeurige root selecteren voor uw l10n-bestanden in uw bronrepository. Daarin, heb je een map voor elke benodigde lokale, en een vaste “LC_MESSAGES” map die al uw PO/MO paren zal bevatten.
meervoudsvormen
zoals we in de inleiding al zeiden, kunnen verschillende talen verschillende pluralisatieregels hebben. Echter, Gettext bespaart ons deze moeite.
bij het maken van een nieuwe .po bestand, moet u de pluralisatie regels voor die taal te verklaren, en vertaalde stukken die meervoud-gevoelig zal een andere vorm voor elk van deze regels hebben.
wanneer Gettext in code wordt aangeroepen, moet u een nummer opgeven dat gerelateerd is aan de zin (bijvoorbeeld voor de zin “U hebt n berichten.”, moet u de waarde van n) opgeven, en het zal het juiste formulier uitwerken om te gebruiken – zelfs met behulp van tekenreeksvervanging indien nodig.
Meervoudsregels zijn samengesteld uit het aantal regels dat nodig is met een Booleaanse test voor elke regel (test voor maximaal één regel mag worden weggelaten). Bijvoorbeeld::
-
Japans:
nplurals=1; plural=0;
– één regel: er zijn geen meervoudsvormen -
Nederlands:
nplurals=2; plural=(n != 1);
– twee regels: Gebruik de meervoudsvorm alleen als n niet 1 is, anders gebruik de enkelvoudsvorm. -
Braziliaans Portugees:
nplurals=2; plural=(n > 1);
– twee regels, Gebruik de meervoudsvorm alleen wanneer n groter is dan 1, anders gebruik de enkelvoudsvorm.
voor een diepere uitleg, Er is een informatieve LingoHub tutorial online beschikbaar.
Gettext zal bepalen welke regel gebruikt moet worden op basis van het gegeven nummer en zal de juiste gelokaliseerde versie van de tekenreeks gebruiken. Voor strings waar pluralisatie moet worden behandeld, moet u opnemen in de .po bestand een andere zin voor elke meervoud regel gedefinieerd.
voorbeeld implementatie
na al die theorie, laten we een beetje praktisch. Hier is een uittreksel van a .po bestand (Maak je nog niet te veel zorgen over de syntaxis, maar in plaats daarvan gewoon een gevoel van de totale inhoud):
msgid ""msgstr """Language: pt_BR\n""Content-Type: text/plain; charset=UTF-8\n""Plural-Forms: nplurals=2; plural=(n > 1);\n"msgid "We're now translating some strings"msgstr "Nós estamos traduzindo algumas strings agora"msgid "Hello %1$s! Your last visit was on %2$s"msgstr "Olá %1$s! Sua última visita foi em %2$s"msgid "Only one unread message"msgid_plural "%d unread messages"msgstr "Só uma mensagem não lida"msgstr "%d mensagens não lidas"
de eerste sectie werkt als een header, met de msgid
en msgstr
leeg.
het beschrijft de bestandscodering, meervoudsvormen, en een paar andere dingen. De tweede sectie vertaalt een eenvoudige tekenreeks van Engels naar Braziliaans Portugees, en de derde doet hetzelfde, maar maakt gebruik van tekenreeks vervanging van sprintf
, waardoor de vertaling de gebruikersnaam en bezoek datum bevatten.
de laatste sectie is een voorbeeld van meervoudsvormen, met de enkelvoud en meervoud versie als msgid
in het Engels en de bijbehorende vertalingen als msgstr
0 en 1 (volgens het nummer gegeven door de meervoudregel).
Daar wordt ook stringvervanging gebruikt, zodat het getal direct in de zin te zien is, door %d
te gebruiken. De meervoudsvormen hebben altijd twee msgid
(enkelvoud en meervoud), dus is het raadzaam om geen complexe taal als bron van vertaling te gebruiken.
Localization Keys
zoals u misschien hebt gemerkt, gebruiken we de Engelse zin als bron-ID. Dat msgid
hetzelfde is dat overal in uw systeem wordt gebruikt .po-bestanden, wat betekent dat andere talen hetzelfde formaat en dezelfde msgid
velden hebben, maar msgstr
regels vertaald.
over vertaalsleutels gesproken, er zijn hier twee standaard “filosofische” benaderingen:
1. msgid als echte zin
de belangrijkste voordelen van deze benadering zijn::
-
als er delen van de software onvertaald zijn in een bepaalde taal, zal de weergegeven sleutel nog steeds enige betekenis behouden. Bijvoorbeeld, als je weet hoe je van Engels naar Spaans moet vertalen, maar hulp nodig hebt bij het vertalen naar Frans, zou je de nieuwe pagina met ontbrekende Franse zinnen kunnen publiceren, en delen van de website zouden in plaats daarvan in het Engels worden weergegeven.
-
het is veel gemakkelijker voor de vertaler om te begrijpen wat er aan de hand is en een goede vertaling te maken op basis van de
msgid
. -
het geeft je” gratis ” l10n voor één taal – de bron.
aan de andere kant is het belangrijkste nadeel dat, als u de eigenlijke tekst moet wijzigen, u dezelfde msgid
in meerdere taalbestanden moet vervangen.
2. msgid als een unieke, gestructureerde sleutel
dit zou de zinsrol in de toepassing op een gestructureerde manier beschrijven, met inbegrip van de sjabloon of het deel waar de tekenreeks zich bevindt in plaats van de inhoud ervan.
dit is een geweldige manier om de code te organiseren, waarbij de tekstinhoud wordt gescheiden van de sjabloonlogica. Dat kan echter problemen opleveren voor de vertaler die de context zou missen.
een brontaalbestand zou nodig zijn als basis voor andere vertalingen. Bijvoorbeeld, de ontwikkelaar zou idealiter een “en.po “bestand, dat vertalers zouden lezen om te begrijpen wat te schrijven in” fr.po”.
ontbrekende vertalingen zouden betekenisloze toetsen op het scherm weergeven (“top_menu.welkom “in plaats van” Hallo daar, gebruiker!”op de genoemde onvertaalde Franse pagina).
dat is goed omdat het Vertaling zou dwingen om volledig te zijn voordat het wordt gepubliceerd – maar slecht omdat vertaalproblemen echt verschrikkelijk zouden zijn in de interface. Sommige bibliotheken bevatten echter een optie om een bepaalde taal te specificeren als “fallback”, met een vergelijkbaar gedrag als de andere benadering.
het gettext-handboek geeft de voorkeur aan de eerste aanpak omdat het over het algemeen gemakkelijker is voor vertalers en gebruikers in geval van problemen. Dat is de aanpak die we hier ook zullen gebruiken.
Opgemerkt dient te worden dat de documentatie van Symfony de voorkeur geeft aan op trefwoorden gebaseerde vertaling, om onafhankelijke wijzigingen van alle vertalingen mogelijk te maken zonder ook sjablonen te beïnvloeden.
dagelijks gebruik
In een veelgebruikte toepassing gebruikt u enkele Gettext-functies tijdens het schrijven van statische tekst in uw pagina ‘ s.
deze zinnen zouden dan in .po-bestanden, get vertaald, gecompileerd in. mo-bestanden, en vervolgens gebruikt door Gettext bij het renderen van de werkelijke interface. Gezien dat, laten we koppelen wat we tot nu toe hebben besproken in een stap-voor-stap voorbeeld:
1. Een voorbeeld template bestand, inclusief een aantal verschillende gettext aanroepen
<?php include 'i18n_setup.php' ?><div> <h1><?=sprintf(gettext('Welcome, %s!'), $name)?></h1> <!-- code indented this way only for legibility → <?php if ($unread): ?> <h2> <?=sprintf( ngettext('Only one unread message', '%d unread messages', $unread), $unread )?> </h2> <?php endif ?></div><h1><?=gettext('Introduction')?></h1><p><?=gettext('We\'re now translating some strings')?></p>
-
gettext()
vertaalt eenvoudig eenmsgid
in de corresponderendemsgstr
voor een bepaalde taal. Er is ook de stenofunctie_()
die op dezelfde manier werkt -
ngettext()
doet hetzelfde, maar met meervoud regels -
er is ook
dgettext()
endngettext()
, waarmee u het domein kunt overschrijven voor een enkele aanroep (meer over domeinconfiguratie in het volgende voorbeeld)
2. Een voorbeeld setup bestand (i18n_setup.php zoals hierboven gebruikt), het selecteren van de juiste locale en het configureren van Gettext
met behulp van Gettext heeft een beetje van een boilerplate code, maar het gaat meestal over het configureren van de locales directory en het kiezen van de juiste parameters (een locale en een domein).
<?php/** * Verifies if the given $locale is supported in the project * @param string $locale * @return bool */function valid($locale) { return in_array($locale, ) && valid($_GET)) { // the locale can be changed through the query-string $lang = $_GET; //you should sanitize this! setcookie('lang', $lang); //it's stored in a cookie so it can be reused} elseif (isset($_COOKIE) && valid($_COOKIE)) { // if the cookie is present instead, let's just keep it $lang = $_COOKIE; //you should sanitize this!} elseif (isset($_SERVER)) { // default: look for the languages the browser says the user accepts $langs = explode(',', $_SERVER); array_walk($langs, function (&$lang) { $lang = strtr(strtok($lang, ';'), ); }); foreach ($langs as $browser_lang) { if (valid($browser_lang)) { $lang = $browser_lang; break; } }}// here we define the global system locale given the found languageputenv("LANG=$lang");// this might be useful for date functions (LC_TIME) or money formatting (LC_MONETARY), for instancesetlocale(LC_ALL, $lang);// this will make Gettext look for ../locales/<lang>/LC_MESSAGES/main.mobindtextdomain('main', '../locales');// indicates in what encoding the file should be readbind_textdomain_codeset('main', 'UTF-8');// if your application has additional domains, as cited before, you should bind them here as wellbindtextdomain('forum', '../locales');bind_textdomain_codeset('forum', 'UTF-8');// here we indicate the default domain the gettext() calls will respond totextdomain('main');// this would look for the string in forum.mo instead of main.mo// echo dgettext('forum', 'Welcome back!');?>
3. Vertaling voorbereiden voor de eerste run
een van de grote voordelen van Gettext ten opzichte van aangepaste framework i18n-pakketten is het uitgebreide en krachtige bestandsformaat.
misschien denkt u “oh man, dat is heel moeilijk te begrijpen en te bewerken met de hand, een eenvoudige array zou gemakkelijker zijn!”Vergis je niet, toepassingen zoals Poedit zijn hier om te helpen – veel. U kunt het programma van hun website, het is gratis en beschikbaar voor alle platforms. Het is een vrij eenvoudig hulpmiddel om aan te wennen, en een zeer krachtige één op hetzelfde moment – met behulp van alle functies Gettext beschikbaar heeft. We werken hier met de nieuwste versie, Poedit 1.8.
in de eerste run moet u “File > New…” uit het menu selecteren. U wordt gevraagd om de taal; selecteer / filter de taal waarnaar u wilt vertalen, of gebruik het formaat dat we eerder hebben genoemd, zoals en_US
of pt_BR
.
nu, sla het bestand – met behulp van die directory structuur die we ook genoemd. Dan moet je klikken “Extract from sources”, en hier zul je verschillende instellingen voor de extractie en vertaling taken configureren. U zult in staat zijn om deze later te vinden via “Catalog > Properties”:
-
bron-paden: Alle mappen van het project opnemen waar
gettext()
(en broers en zussen) worden aangeroepen-dit is meestal uw sjablonen / weergavemappen. Dit is de enige verplichte instelling. -
vertaal-eigenschappen:
- naam en versie van het Project, Team en e-mailadres van het Team: nuttige informatie die gaat in de .po file header.
- meervoudsvormen: dit zijn de eerder genoemde regels. U kunt het meestal laten met de standaard optie, omdat Poedit al een handige database van meervoud regels voor vele talen bevat.
- Charsets: UTF-8, bij voorkeur.
- broncode tekenset: de tekenset die door uw codebase wordt gebruikt – waarschijnlijk ook UTF-8, toch?
-
Source keywords: de onderliggende software weet hoe
gettext()
en soortgelijke functieaanroepen eruit zien in verschillende programmeertalen, maar u kunt net zo goed uw eigen vertaalfuncties creëren. Het zal hier u zult die andere methoden toe te voegen. Dit zal later worden besproken in de” Tips ” sectie.
na het instellen van deze eigenschappen, Poedit zal een scan uitvoeren door uw bronbestanden om alle lokalisatie calls te vinden. Na elke scan, Poedit zal een samenvatting van wat werd gevonden en wat werd verwijderd uit de bronbestanden weer te geven. Nieuwe items zullen leeg zijn in de vertalingstabel, zodat u de gelokaliseerde versies van deze strings kunt invoeren. Sla het op en een. mo bestand wordt (opnieuw)gecompileerd in dezelfde map en, presto!, uw project is geïnternationaliseerd!
Poedit kan ook algemene vertalingen van het web en van eerdere bestanden suggereren. Het is handig, dus je hoeft alleen maar te controleren of ze zinvol zijn, en ze te accepteren. Als u niet zeker bent over een vertaling, kunt u deze markeren als Fuzzy, en het zal worden weergegeven in geel. Blauwe ingangen zijn degenen die geen vertaling hebben.
4. Translating strings
zoals u wellicht hebt opgemerkt, zijn er twee hoofdtypen van gelokaliseerde strings: eenvoudige en die met meervoudsvormen.
eenvoudige hebben slechts twee kaders: bron en gelokaliseerde tekenreeks. De brontekst kan niet worden gewijzigd, omdat Gettext / Poedit niet de mogelijkheid bevat om uw bronbestanden te wijzigen; in plaats daarvan moet u de bron zelf wijzigen en de bestanden opnieuw scannen. (Tip: Als u met de rechtermuisknop op een vertaalregel klikt, wordt er een hint weergegeven met de bronbestanden en regels waar die string wordt gebruikt.)
meervoudsvormreeksen bevatten twee kaders om de twee bronreeksen weer te geven, en tabs zodat u de verschillende definitieve vormen kunt configureren.
voorbeeld van een string met een meervoudsvorm op Poedit, die voor elk een tabblad vertaling toont.
wanneer u uw broncodebestanden wijzigt en de vertalingen wilt bijwerken, klikt u op Refresh en Poedit zal de code opnieuw scannen, niet-bestaande ingangen verwijderen, de gewijzigde ingangen samenvoegen en nieuwe toevoegen.
Poedit kan ook proberen een aantal vertalingen te raden, gebaseerd op andere vertalingen die u hebt gemaakt. Deze gissingen en de gewijzigde items zullen een “Fuzzy” markering ontvangen, die aangeeft dat ze moeten worden beoordeeld, weergegeven in het geel in de lijst.
het is ook handig als je een vertaalteam hebt en iemand probeert iets te schrijven waar ze niet zeker van zijn: markeer het gewoon Fuzzy en iemand anders zal het later bekijken.
ten slotte is het raadzaam om” View > Untranslated entries first ” gemarkeerd te laten, omdat het u zal helpen voorkomen dat u items vergeet. Vanuit dat menu kunt u ook delen van de gebruikersinterface openen waarmee u indien nodig contextuele informatie voor vertalers kunt achterlaten.
Tips & trucs
webservers kunnen uw. mo-bestanden cachen.
als je PHP draait als een module op Apache (mod_php), kun je problemen ondervinden met het .mo bestand dat gecached wordt. Het gebeurt de eerste keer dat het wordt gelezen, en dan, om het bij te werken, moet u mogelijk de server opnieuw op te starten.
op Nginx en PHP5 duurt het meestal slechts een paar paginavernieuwingen om de vertaalcache te vernieuwen, en op PHP7 is het zelden nodig.
bibliotheken bieden hulpfuncties om de lokalisatiecode kort te houden.
zoals veel mensen verkiezen, is het gemakkelijker om _()
te gebruiken in plaats van gettext()
. Veel aangepaste i18n-bibliotheken van frameworks gebruiken ook iets gelijkaardigs als t()
om vertaalde code korter te maken. Echter, dat is de enige functie die sport een kortere weg.
u wilt misschien een aantal andere aan uw project toevoegen, zoals __()
of _n()
voor ngettext()
, of misschien een fancy _r()
die gettext()
en sprintf()
aanroepen. Andere bibliotheken, zoals oscarotero ‘ s Gettext bieden ook helperfuncties zoals deze.
in die gevallen moet u het Gettext hulpprogramma instrueren over hoe u de strings uit die nieuwe functies kunt extraheren. Wees niet bang, het is heel makkelijk. Het is gewoon een veld in de .po-bestand of een instellingenscherm in Poedit (in de editor bevindt deze optie zich in “Catalog > Properties > Sources keywords”).
onthouden: Gettext kent al de standaard functies voor veel talen, dus wees niet bezorgd als die lijst leeg lijkt. U moet in die lijst de specificaties van de nieuwe functies opnemen, volgens dit specifieke formaat:
-
als u iets als
t()
maakt, dat simpelweg de vertaling van een tekenreeks retourneert, kunt u deze opgeven alst
. Gettext zal weten dat het enige functieargument de te vertalen tekenreeks is; -
als de functie meer dan één argument heeft, kunt u opgeven in welke de eerste string is en, indien nodig, ook de meervoudsvorm. Bijvoorbeeld, als onze functiehandtekening
__('one user', '%d users', $number)
is, zou de specificatie__:1,2
zijn, wat betekent dat de eerste vorm het eerste argument is, en de tweede vorm het tweede argument. Als uw nummer in plaats daarvan als het eerste argument komt, zou de spec__:2,3
zijn, wat aangeeft dat de eerste vorm het tweede argument is, enzovoort.
na het opnemen van die nieuwe regels in de .po bestand, een nieuwe scan zal brengen in uw nieuwe strings net zo gemakkelijk als voorheen.
Maak Uw PHP-App meertalig met Gettext
Gettext is een zeer krachtige tool voor het internationaliseren van uw PHP-project. Naast de flexibiliteit waarmee ondersteuning voor een groot aantal menselijke talen, de ondersteuning voor meer dan 20 programmeertalen kunt u gemakkelijk uw kennis van het gebruik ervan met PHP naar andere talen zoals Python, Java, of C#.
verder kan Poedit helpen het pad tussen code en vertaalde strings glad te strijken, waardoor het proces eenvoudiger en gemakkelijker te volgen is. Het kan ook gedeelde vertaalinspanningen stroomlijnen met zijn Crowdin-integratie.
overweeg waar mogelijk andere talen die uw gebruikers kunnen spreken. Dit is vooral belangrijk voor niet-Engelse projecten: U kunt uw gebruikerstoegang verbeteren als u het zowel in het Engels als in uw moedertaal loslaat.
natuurlijk hebben niet alle projecten behoefte aan internationalisering, maar het is veel gemakkelijker om i18n in de kinderschoenen te starten, zelfs als het in eerste instantie niet nodig is, dan om het later te doen als het later een vereiste wordt. En met tools als Gettext en Poedit is het makkelijker dan ooit.