Slik Bygger Du En Flerspråklig App :En Demo Med PHP Og Gettext

Enten du bygger et nettsted eller en fullverdig webapplikasjon, noe som gjør den tilgjengelig for et bredere publikum, krever det ofte å være tilgjengelig på forskjellige språk og steder.

Fundamentale forskjeller mellom de fleste menneskelige språk gjør dette alt annet enn enkelt. Forskjellene i grammatikkregler, språknyanser, datoformater og mer kombineres for å gjøre lokalisering til en unik og formidabel utfordring.

Vurder dette enkle eksemplet.

regler for pluralisering på engelsk er ganske enkle: du kan ha en singular form av et ord eller en flertallsform av et ord.

på Andre språk, skjønt – som Slaviske språk – er det to flertallsformer i tillegg til entall. Du kan til og med finne språk med totalt fire, fem eller seks flertallsformer, for Eksempel På Slovensk, Irsk eller arabisk.

måten koden din er organisert på, og hvordan komponentene og grensesnittet er utformet, spiller en viktig rolle for å bestemme hvor enkelt du kan lokalisere søknaden din.

Internasjonalisering (i18n) av kodebasen din, bidrar til å sikre at den kan tilpasses forskjellige språk eller regioner med relativ letthet. Internasjonalisering gjøres vanligvis en gang, helst i begynnelsen av prosjektet for å unngå store endringer i kildekoden nedover veien.

Hvordan Bygge En Flerspråklig App: En Demo MED PHP og Gettext

når kodebasen er internasjonalisert, blir lokalisering (l10n) et spørsmål om å oversette innholdet i søknaden din til et bestemt språk/locale.

Lokalisering må utføres hver gang et nytt språk eller en ny region må støttes. Også når en del av grensesnittet (som inneholder tekst) oppdateres, blir nytt innhold tilgjengelig – som da må lokaliseres (dvs.oversatt) til alle støttede steder.

i denne artikkelen vil vi lære å internasjonalisere og lokalisere programvare skrevet I PHP. Vi vil gå gjennom de ulike implementeringsalternativene og de ulike verktøyene som er tilgjengelige for å lette prosessen.

Verktøy For Internasjonalisering

den enkleste måten Å internasjonalisere PHP-programvare på er å bruke array-filer. Arrays vil bli befolket med oversatte strenger, som deretter kan bli sett opp fra maler:

<h1><?=$TRANS?></h1>

Dette er imidlertid neppe en anbefalt måte for seriøse prosjekter, da det definitivt vil utgjøre vedlikeholdsproblemer nedover veien. Noen problemer kan til og med vises i begynnelsen,for eksempel mangel på støtte for variabel interpolering eller pluralisering av substantiver og så videre.

Et av de mest klassiske verktøyene (ofte tatt som referanse for i18n og l10n) Er Et Unix-verktøy kalt Gettext.

selv om det går tilbake til 1995, er det fortsatt et omfattende verktøy for å oversette programvare som også er enkel å bruke. Selv om det er ganske enkelt å komme i gang med, har det fortsatt kraftige støtteverktøy.

Gettext er Det vi skal bruke i dette innlegget. Vi vil presentere en stor GUI program som kan brukes til å enkelt oppdatere l10n kildefiler, og dermed unngå behovet for å håndtere kommandolinjen.

Biblioteker For Å Gjøre Ting Enkelt

Store PHP web rammeverk og biblioteker som støtter Gettext

DET er store PHP web rammeverk og biblioteker som støtter Gettext og andre implementeringer av i18n. Noen er enklere å installere enn andre, eller sport tilleggsfunksjoner eller støtte ulike i18n filformater. Selv om vi i dette dokumentet fokuserer på verktøyene som FØLGER MED PHP-kjernen, er det en liste over noen andre som er verdt å nevne:

  • oscarotero / Gettext: gettext støtte med et objektorientert grensesnitt; inkluderer forbedrede hjelpefunksjoner, kraftige ekstraktorer for flere filformater(noen av dem støttes ikke innfødt av kommandoen gettext). Kan også eksportere til formater utover bare .mo/. po-filer, noe som kan være nyttig hvis du trenger å integrere oversettelsesfilene dine i andre deler av systemet, som Et JavaScript-grensesnitt.

  • symfony / translation: Støtter mange forskjellige formater, men anbefaler å bruke verbose XLIFF ‘ s. Inkluderer ikke hjelpefunksjoner eller en innebygd ekstraktor, men støtter plassholdere som bruker strtr() internt.

  • zend/i18n: Støtter array og INI-filer, Eller gettext formater. Implementerer en caching lag for å unngå å måtte lese filsystemet hver gang. Inkluderer også vis hjelpere, og locale-aware input filtre og validatorer. Det har imidlertid ingen meldingsuttrekker.

Andre rammer inkluderer også i18n-moduler, men de er ikke tilgjengelige utenfor kodebasene:

  • Laravel: Støtter grunnleggende arrayfiler; har ingen automatisk ekstraktor, men inkluderer en @lang hjelper for malfiler.

  • Yii: Støtter array, Gettext, og database-basert oversettelse, og inkluderer en meldinger extractor. Støttet av utvidelsen Intl, tilgjengelig SIDEN PHP 5.3, og basert på ICU-prosjektet. Dette gjør At Yii å kjøre kraftige erstatninger, som stave ut tall, formatering datoer, tider, intervaller, valuta, og ordinaler.

Hvis du bestemmer deg for å gå til et av bibliotekene som ikke gir noen ekstraktorer, vil du kanskje bruke Gettext-formatene, slik at du kan bruke den opprinnelige gettext-verktøykjeden (inkludert Poedit) som beskrevet i resten av kapitlet.

Installere Gettext

du må kanskje installere Gettext og det relaterte PHP-biblioteket ved å bruke pakkebehandleren, som apt-get eller yum. Når den er installert, aktiverer du den ved å legge til extension=gettext.so (Linux/Unix) eller extension=php_gettext.dll (Windows) i filen php.ini.

Her vil Vi også bruke Poedit til å lage oversettelsesfiler. Du vil sannsynligvis finne den i systemets pakkebehandling; den er tilgjengelig For Unix, Mac Og Windows, og kan lastes ned gratis på sin nettside også.

Typer Gettext-Filer

det er tre filtyper du vanligvis håndterer mens du arbeider med Gettext.

de viktigste er po (Portable Object) og MO (Machine Object) filer, den første er en liste over lesbare «oversatte objekter» og den andre er den tilsvarende binære (som skal tolkes Av Gettext når du gjør lokalisering). DET er også EN POT (PO Mal) fil, som bare inneholder alle eksisterende nøkler fra kildefilene dine, og kan brukes som en guide for å generere og oppdatere ALLE PO-filer.

malfilene er ikke obligatoriske; avhengig av verktøyet du bruker til å gjøre l10n, vil du bare ha det bra med BARE po/MO-filer. Du har ett par po / MO-filer per språk og region, men bare en POTT per domene.

Separere Domener

det er noen tilfeller, i store prosjekter, hvor du kanskje må skille oversettelser når de samme ordene formidler forskjellig mening i forskjellige sammenhenger.

i slike tilfeller må du dele dem i forskjellige «domener», som i utgangspunktet heter grupper AV POT / PO / MO-filer, der filnavnet er det nevnte oversettelsesdomenet.

Små og mellomstore prosjekter vanligvis, for enkelhet, bruker bare ett domene; navnet er vilkårlig, men vi skal bruke «main» for våre kodeeksempler.

i Symfony-prosjekter brukes for eksempel domener til å skille oversettelsen for valideringsmeldinger.

Nasjonal Kode

en nasjonal kode er ganske enkelt en kode som identifiserer en versjon av et språk. Det er definert ETTER iso 639-1 og ISO 3166-1 alfa-2-spesifikasjonene: to små bokstaver for språket, eventuelt etterfulgt av en understrek og to store bokstaver som identifiserer land eller regional kode.

for sjeldne språk brukes tre bokstaver.

for noen høyttalere kan landdelen virke overflødig. Faktisk har noen språk dialekter i forskjellige land, for Eksempel Østerriksk tysk (de_AT) eller Brasiliansk portugisisk (pt_BR). Den andre delen brukes til å skille mellom disse dialektene – når den ikke er til stede, blir den tatt som en «generisk» eller «hybrid» versjon av språket.

Katalogstruktur

for å bruke Gettext må vi følge en bestemt struktur av mapper.

først må du velge en vilkårlig rot for l10n-filene dine i kildelageret ditt. Inne i det, vil du ha en mappe for hver nødvendig locale, og en fast» LC_MESSAGES » mappe som vil inneholde alle DINE PO / MO par.

Lc_messages Mappe

Flertallsformer

som vi sa i innledningen, kan forskjellige språk sport forskjellige pluraliseringsregler. Men, gettext sparer oss dette problemer.

når du oppretter en ny .po-fil, du må erklære pluraliseringsreglene for det språket, og oversatte stykker som er flertallsfølsomme, vil ha en annen form for hver av disse reglene.

når du ringer Gettext i kode, må du angi et nummer relatert til setningen (f. eks for uttrykket «Du har n meldinger.», må du angi verdien av n), og det vil fungere riktig form å bruke – selv ved hjelp av streng substitusjon om nødvendig.

Flertallsregler er sammensatt av antall regler som er nødvendige med en boolsk test for hver regel (test for høyst en regel kan utelates). For eksempel:

  • Japansk: nplurals=1; plural=0; – en regel: det er ingen flertallsformer

  • norsk: nplurals=2; plural=(n != 1); – to regler: bruk bare flertallsform når n ikke er 1, ellers bruk entallsform.

  • Brasiliansk portugisisk: nplurals=2; plural=(n > 1); – to regler, bruk bare flertallsform når n er større enn 1, ellers bruk entallsform.

for en dypere forklaring er det en informativ LingoHub-opplæring tilgjengelig online.

Gettext bestemmer hvilken regel som skal brukes basert på nummeret som er oppgitt, og vil bruke den riktige lokaliserte versjonen av strengen. For strenger der pluralisering må håndteres, må du inkludere i .po fil en annen setning for hver flertallsregel definert.

Eksempelimplementering

Etter all den teorien, la Oss få litt praktisk. Her er et utdrag av a .po-fil (ikke bekymre deg for mye om syntaksen, men i stedet bare få en følelse av det generelle innholdet):

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"

den første delen fungerer som en overskrift, med msgid og msgstr tom.

den beskriver filkoding, flertallsformer og et par andre ting. Den andre delen oversetter en enkel streng fra engelsk Til Brasiliansk portugisisk, og den tredje gjør det samme, men utnytter strengutskifting fra sprintf, slik at oversettelsen kan inneholde brukernavn og besøksdato.

den siste delen er et utvalg av pluraliseringsskjemaer, som viser singular-og flertallsversjonen som msgid på engelsk og tilhørende oversettelser som msgstr 0 og 1 (etter tallet gitt av flertallsregelen).

der brukes også strengutskifting, slik at tallet kan ses direkte i setningen ved å bruke %d. Flertallsformer har alltid to msgid (entall og flertall), så det anbefales å ikke bruke et komplekst språk som kilde til oversettelse.

Lokaliseringsnøkler

som du kanskje har lagt merke til, bruker vi den faktiske engelske setningen som kilde-ID. At msgid er det samme som brukes i hele din .po-filer, noe som betyr at andre språk vil ha samme format og de samme msgid feltene, men oversatt msgstr linjer.

Når det Gjelder oversettelsesnøkler, er det to standard «filosofiske» tilnærminger her:

1. msgstr som en reell setning

de viktigste fordelene med denne tilnærmingen er:

  • hvis det er deler av programvaren uoversatt på et gitt språk, vil nøkkelen som vises fortsatt ha noen betydning. Hvis du for eksempel vet hvordan du oversetter fra engelsk til spansk, men trenger hjelp til å oversette til fransk, kan du publisere den nye siden med manglende franske setninger, og deler av nettstedet vil bli vist på engelsk i stedet.

  • det er mye lettere for oversetteren å forstå hva som skjer og gjøre en riktig oversettelse basert på msgid.

  • Det gir deg «gratis» l10n for ett språk-kilden en.

på den annen side er den primære ulempen at hvis du trenger å endre den faktiske teksten, må du erstatte den samme msgid på tvers av flere språkfiler.

2. msgstr som en unik, strukturert nøkkel

vil dette beskrive setningsrollen i applikasjonen på en strukturert måte, inkludert malen eller delen der strengen er plassert i stedet for innholdet.

dette er en fin måte å få koden organisert på, og skille tekstinnholdet fra mallogikken. Det kan imidlertid gi problemer til oversetteren som ville savne konteksten.

en kildespråkfil ville være nødvendig som grunnlag for andre oversettelser. For eksempel vil utvikleren ideelt sett ha en » en.po «fil, som oversettere ville lese for å forstå hva du skal skrive i» fr.po».

Manglende oversettelser vil vise meningsløse taster på skjermen («top_menu.velkommen «i stedet For» Hei Der, Bruker!»på nevnte uoversatt fransk side).

det er bra som det ville tvinge oversettelsen til å være komplett før publisering-men dårlig som oversettelsesproblemer ville være veldig forferdelig i grensesnittet. Noen biblioteker inkluderer imidlertid et alternativ for å angi et gitt språk som «fallback», som har en lignende oppførsel som den andre tilnærmingen.

gettext-håndboken favoriserer den første tilnærmingen, da det generelt er lettere for oversettere og brukere i tilfelle problemer. Det er den tilnærmingen vi skal bruke her også.

Det bør imidlertid bemerkes at Symfony-dokumentasjonen favoriserer søkeordbasert oversettelse, for å tillate uavhengige endringer av alle oversettelser uten å påvirke maler også.

Daglig Bruk

i et vanlig program vil du bruke Noen gettext-funksjoner mens du skriver statisk tekst på sidene dine.

disse setningene vil da vises i .po filer, få oversatt, kompilert inn mo filer, og deretter brukt Av Gettext når rendering selve grensesnittet. Gitt det, la oss knytte sammen det vi har diskutert så langt i et trinnvis eksempel:

1. En eksempelmalfil, inkludert noen forskjellige gettext-anrop

<?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() oversetter bare en msgid til den tilsvarende msgstr for et gitt språk. Det er også shorthand-funksjonen _() som fungerer på samme måte

  • ngettext() gjør det samme, men med flertallsregler

  • det er også dgettext() og dngettext(), som lar deg overstyre domenet for en enkelt samtale (mer om domenekonfigurasjon i neste eksempel)

2. En eksempeloppsettfil (i18n_setup.php som brukt ovenfor), velge riktig locale Og konfigurere Gettext

Ved Hjelp Av Gettext innebærer litt av en standardtekstkode, men det er for det meste om å konfigurere locales katalogen og velge riktige parametere (en locale og et domene).

<?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. Forbereder oversettelse for første løp

En av de store fordelene Gettext har over custom framework i18n pakker er dens omfattende og kraftig filformat.

kanskje du tenker «Oh mann, det er ganske vanskelig å forstå og redigere for hånd, en enkel matrise ville være enklere!»Gjør ingen feil, programmer Som Poedit er her for å hjelpe-mye. Du kan få programmet fra deres hjemmeside, det er gratis og tilgjengelig for alle plattformer. Det er et ganske enkelt verktøy å bli vant til, og en veldig kraftig samtidig – ved hjelp Av Alle funksjonene Gettext har tilgjengelig. Vi skal jobbe her med den nyeste versjonen, Poedit 1.8.

Se innsiden Av Poedit.

I første løp bør du velge «Fil > Ny …» fra menyen. Du vil bli bedt om språket; velg / filtrer språket du vil oversette til, eller bruk formatet vi nevnte tidligere, for eksempel en_US eller pt_BR.

Valg av språk.

nå lagre filen-ved hjelp av den katalogstrukturen vi nevnte også. Deretter bør du klikke «Utdrag fra kilder», og her vil du konfigurere ulike innstillinger for utvinning og oversettelse oppgaver. Du vil kunne finne alle de senere gjennom «Katalog > Egenskaper»:

  • Kilde baner: Inkluder alle mapper fra prosjektet der gettext() (og søsken) kalles – dette er vanligvis dine maler / visninger mappe (r). Dette er den eneste obligatoriske innstillingen.

  • Oversettelsesegenskaper:

    • Prosjektnavn og versjon, Team og Teamets e-postadresse: Nyttig informasjon som gar i den .po fil header.
    • Flertallsformer: dette er reglene vi nevnte før. Du kan legge det med standardalternativet mesteparten av tiden, Da Poedit allerede inneholder en praktisk database med flertallsregler for mange språk.
    • Tegnsett: UTF-8, helst.
    • Kildekode charset: charset som brukes av kodebasen din – sannsynligvis UTF-8 også, ikke sant?
  • Kilde nøkkelord: den underliggende programvaren vet hvordan gettext() og lignende funksjonskall ser ut i flere programmeringsspråk, men du kan like godt lage dine egne oversettelsesfunksjoner. Det vil være her du vil legge til de andre metodene. Dette vil bli diskutert senere i» Tips » – delen.

Etter å ha satt disse egenskapene, Vil Poedit kjøre en skanning gjennom kildefilene for å finne alle lokaliseringsanropene. Etter hver skanning Vil Poedit vise et sammendrag av hva som ble funnet og hva som ble fjernet fra kildefilene. Nye oppføringer vil være tom i oversettelsestabellen, slik at du kan legge inn lokaliserte versjoner av disse strengene. Lagre det og en. mo fil vil bli (re)kompilert i samme mappe og, presto!, prosjektet ditt er internasjonalisert!

internasjonalisert prosjekt.

Poedit kan også foreslå vanlige oversettelser fra nettet og fra tidligere filer. Det er praktisk, så du må bare sjekke om de gir mening, og godta dem. Hvis du er usikker på en oversettelse, kan du merke den Som Uklar, og den vil bli vist i gul. Blå oppføringer er de som ikke har noen oversettelse.

4. Oversette strenger

Som du kanskje har lagt merke til, er det to hovedtyper av lokaliserte strenger: enkle og de med flertallsformer.

Enkle har bare to bokser: kilde og lokalisert streng. Kildestrengen kan ikke endres, Siden Gettext / Poedit ikke inkluderer muligheten til å endre kildefilene dine; i stedet må du endre kilden selv og skanne filene på nytt. (Tips: Hvis du høyreklikker en oversettelseslinje, vil den vise et hint med kildefilene og linjene der den strengen blir brukt.)

Flertallsformerstrenger inkluderer to bokser for å vise de to kildestrengene, og faner slik at du kan konfigurere de forskjellige endelige skjemaene.

Konfigurere endelige skjemaer.

Eksempel på en streng med flertallsform På Poedit, som viser en oversettelsesfane for hver enkelt.

når du endrer kildekodefilene dine Og trenger å oppdatere oversettelsene, bare trykk Refresh og Poedit vil skanne koden, fjerne ikke-eksisterende oppføringer, slå sammen de som endret og legge til nye.

Poedit kan også prøve å gjette noen oversettelser, basert på andre du gjorde. Disse gjetningene og de endrede oppføringene vil motta en» Fuzzy » markør, som indikerer at de trenger gjennomgang, vist i gult i listen.

Det er også nyttig hvis du har et oversettelsesteam og noen prøver å skrive noe de ikke er sikre på: bare merk Det Fuzzy og noen andre vil vurdere det senere.

Til Slutt anbefales det å la «Vis > Uoversatte oppføringer først» merkes, da det vil hjelpe deg med å unngå å glemme eventuelle oppføringer. Fra denne menyen kan du også åpne deler av BRUKERGRENSESNITTET som lar deg legge igjen kontekstuell informasjon for oversettere om nødvendig.

Tips & Triks

Webservere kan ende opp med å bufre dine .mo-filer.

hvis DU kjører PHP som en modul På Apache (mod_php), kan du få problemer med .mo-filen som bufres. Det skjer første gang det leses, og for å oppdatere det, må du kanskje starte serveren på nytt.

På Nginx OG PHP5 tar det vanligvis bare et par sideoppdateringer for å oppdatere oversettelsesbufferen, OG PÅ PHP7 er det sjelden nødvendig.

Biblioteker gir hjelpefunksjoner for å holde lokaliseringskoden kort.

som foretrukket av mange, er det enklere å bruke _() i stedet for gettext(). Mange tilpassede i18n-biblioteker fra rammer bruker også noe som ligner på t() for å gjøre oversatt kode kortere. Men det er den eneste funksjonen som idrett en snarvei.

du vil kanskje legge til i prosjektet noen andre, for eksempel __() eller _n() for ngettext(), eller kanskje en fancy _r() som ville bli med gettext() og sprintf() samtaler. Andre biblioteker, som oscaroteros Gettext, gir også hjelpefunksjoner som disse.

i slike tilfeller må Du instruere gettext-verktøyet om hvordan du trekker ut strengene fra de nye funksjonene. Ikke vær redd, det er veldig enkelt. Det er bare et felt i den .po-fil eller En Innstillingsskjerm I Poedit (i redigeringsprogrammet er dette alternativet inne i «Catalog > Properties > Sources keywords»).

Husk: Gettext kjenner allerede standardfunksjonene for mange språk, så vær ikke bekymret hvis listen virker tom. Du må inkludere i den listen spesifikasjonene til de nye funksjonene, etter dette bestemte formatet:

  • hvis du lager noe som t(), som bare returnerer oversettelsen for en streng, kan du angi den som t. Gettext vil vite det eneste funksjonsargumentet er strengen som skal oversettes;

  • hvis funksjonen har mer enn ett argument, kan du angi hvilken den første strengen er og, om nødvendig, flertallsformen også. For eksempel, hvis vår funksjonssignatur er __('one user', '%d users', $number), vil spesifikasjonen være __:1,2, noe som betyr at den første formen er det første argumentet, og den andre formen er det andre argumentet. Hvis nummeret ditt kommer som det første argumentet i stedet, vil spesifikasjonen være __:2,3, noe som indikerer at det første skjemaet er det andre argumentet, og så videre.

Etter å ha inkludert de nye reglene i .po-fil, en ny skanning vil bringe inn dine nye strenger like enkelt som før.

Gjør DIN PHP App Flerspråklig Med Gettext

Gettext Er et svært kraftig verktøy for internasjonalisering AV PHP-prosjektet. Utover sin fleksibilitet som tillater støtte for et stort antall menneskelige språk, sin støtte for mer enn 20 programmeringsspråk lar deg enkelt overføre din kunnskap om å bruke DEN MED PHP til andre språk som Python, Java eller C#.

Videre Kan Poedit bidra til å jevne banen mellom kode og oversatte strenger, noe som gjør prosessen enklere og enklere å følge. Det kan også effektivisere felles oversettelse innsats med Sin Crowdin integrasjon.

når det er mulig, bør du vurdere andre språk brukerne kan snakke. Dette er mest viktig for ikke-engelske prosjekter: Du kan øke brukertilgang hvis du slipper den på engelsk, så vel som morsmålet ditt.

selvfølgelig har ikke alle prosjekter behov for internasjonalisering, men det er mye lettere å starte i18n i løpet av et prosjekts barndom, selv om det ikke først var nødvendig, enn det er å gjøre det senere nedover veien hvis det senere skulle bli et krav. Og med verktøy Som Gettext Og Poedit er det enklere enn noensinne.

Relatert: Introduksjon TIL PHP 7: Hva Er Nytt og Hva Er Borte

Leave a Reply

Din e-postadresse vil ikke bli publisert.