hvordan man opbygger en flersproget App: en Demo med PHP og Gettekst

hvordan man opbygger en flersproget App: en Demo med PHP og Gettekst

uanset om du bygger en hjemmeside eller et fuldt udbygget internetprogram, gør det tilgængeligt for et bredere publikum kræver ofte, at det er tilgængeligt på forskellige sprog og lokaliteter.

grundlæggende forskelle mellem de fleste menneskelige sprog gør dette alt andet end let. Forskellene i grammatikregler, sprog nuancer, datoformater, og mere kombineres for at gøre lokalisering til en unik og formidabel udfordring.

overvej dette enkle eksempel.

regler for pluralisering på engelsk er ret ligetil: du kan have en entydig form af et ord eller en flertalsform af et ord.

på andre sprog er der dog – såsom slaviske sprog – to flertalsformer ud over den entallige. Du kan endda finde sprog med i alt fire, fem eller seks flertalsformer, såsom på slovensk, irsk eller arabisk.

den måde, din kode er organiseret på, og hvordan dine komponenter og interface er designet, spiller en vigtig rolle for at bestemme, hvor let du kan lokalisere din applikation.

internationalisering (I18n) af din kodebase hjælper med at sikre, at den kan tilpasses til forskellige sprog eller regioner med relativ lethed. Internationalisering sker normalt en gang, helst i starten af projektet for at undgå at behøve store ændringer i kildekoden nede ad vejen.

når din kodebase er blevet internationaliseret, lokalisering (l10n) bliver et spørgsmål om at oversætte indholdet af din ansøgning til et bestemt sprog/locale.

lokalisering skal udføres hver gang et nyt sprog eller en ny region skal understøttes. Når en del af grænsefladen (der indeholder tekst) opdateres, bliver nyt indhold også tilgængeligt – som derefter skal lokaliseres (dvs.oversættes) til alle understøttede lokaliteter.

i denne artikel vil vi lære at internationalisere og lokalisere programmer skrevet i PHP. Vi gennemgår de forskellige implementeringsmuligheder og de forskellige værktøjer, der er tilgængelige til vores rådighed for at lette processen.

værktøjer til internationalisering

den nemmeste måde at internationalisere PHP-programmer på er ved hjælp af array-filer. Arrays vil blive befolket med oversatte strenge, som derefter kan slås op fra skabeloner:

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

dette er dog næppe en anbefalet måde til seriøse projekter, da det helt sikkert vil udgøre vedligeholdelsesproblemer nede ad vejen. Nogle problemer kan endda forekomme i begyndelsen, såsom manglen på støtte til variabel interpolation eller pluralisering af navneord og så videre.

et af de mest klassiske værktøjer (ofte taget som reference for i18n og l10n) er et unikt værktøj kaldet Gettekst.

selvom det går tilbage til 1995, er det stadig et omfattende værktøj til oversættelse af programmer, der også er let at bruge. Selvom det er ret nemt at komme i gang med, har det stadig kraftfulde understøttende værktøjer.

Gettekst er, hvad vi vil bruge i dette indlæg. Vi vil præsentere et godt GUI-program, der kan bruges til nemt at opdatere dine l10n-kildefiler og derved undgå behovet for at håndtere kommandolinjen.

biblioteker for at gøre tingene lette

der er store PHP-rammer og biblioteker, der understøtter Gettekst og andre implementeringer af i18n. nogle er lettere at installere end andre, eller sport yderligere funktioner eller understøtter forskellige i18n-filformater. Selvom vi i dette dokument fokuserer på de værktøjer, der leveres med PHP-kernen, er her en liste over nogle andre, der er værd at nævne:

• oscarotero/ Gettekst: understøttelse af Gettekst med en objektorienteret grænseflade; inkluderer forbedrede hjælpefunktioner, kraftfulde ekstraktorer til flere filformater (nogle af dem understøttes ikke indbygget af kommandoen gettext). Kan også eksportere til formater ud over just. mo/. po-filer, hvilket kan være nyttigt, hvis du har brug for at integrere dine oversættelsesfiler i andre dele af systemet, som en JavaScript-grænseflade.

• symfony / translation: understøtter mange forskellige formater, men anbefaler at bruge verbose. inkluderer ikke hjælpefunktioner eller en indbygget emhætte, men understøtter pladsholdere, der bruger strtr() internt.

• send / i18n: Understøtter array-og INI-filer eller Fåtekstformater. Implementerer et cachelag for at undgå at skulle læse filsystemet hver gang. Omfatter også se hjælpere, og locale-bevidste input filtre og validatorer. Det har dog ingen meddelelsesudtræk.

andre rammer inkluderer også i18n-moduler, men de er ikke tilgængelige uden for deres kodebaser:

• Laravel: understøtter grundlæggende array-filer; har ingen automatisk emhætte, men inkluderer en @lang hjælper til skabelonfiler.

• Yii: Understøtter array -, Gettekst-og databasebaseret Oversættelse og inkluderer en udtræk af meddelelser. Støttet af Intl – udvidelsen, tilgængelig siden PHP 5.3, og baseret på ICU-projektet. Dette gør det muligt for Yii at køre kraftige udskiftninger, som stavning af tal, formatering af datoer, tider, intervaller, valuta og ordinaler.

hvis du beslutter dig for at gå til et af de biblioteker, der ikke indeholder nogen udsugningsapparater, kan du bruge Gettekstformaterne, så du kan bruge den originale Gettekstværktøjskæde (inklusive Poedit) som beskrevet i resten af kapitlet.

installation af Gettekst

du skal muligvis installere Gettekst og det relaterede PHP-bibliotek ved hjælp af din pakkehåndtering, som apt-get eller yum. Når den er installeret, skal du aktivere den ved at tilføje extension=gettext.so eller extension=php_gettext.dll (vinduer) til din php.ini fil.

her bruger vi også Poedit til at oprette oversættelsesfiler. Du vil sandsynligvis finde det i dit systems pakkehåndtering; det er tilgængeligt til PC, Mac og vinduer og kan også hentes gratis på sin hjemmeside.

typer af Gettekstfiler

der er tre filtyper, du normalt beskæftiger dig med, mens du arbejder med Gettekst.

de vigtigste er Po (Portable Object) og Mo (Machine Object) filer, den første er en liste over læsbare “oversatte objekter” og den anden er den tilsvarende binære (skal fortolkes ved Fettekst, når du laver lokalisering). Der er også en POT (PO Template) fil, der blot indeholder alle eksisterende nøgler fra dine kildefiler, og kan bruges som en guide til at generere og opdatere alle PO-filer.

skabelonfilerne er ikke obligatoriske; afhængigt af det værktøj, du bruger til at gøre l10n, vil du være fint med kun PO/MO-filer. Du har et par PO/MO-filer pr. sprog og region, men kun en POT pr.domæne.

adskillelse af domæner

der er nogle tilfælde i store projekter, hvor du muligvis skal adskille oversættelser, når de samme ord formidler forskellig betydning i forskellige sammenhænge.

i disse tilfælde skal du opdele dem i forskellige “domæner”, som grundlæggende hedder grupper af POT/PO/MO-filer, hvor filnavnet er det nævnte oversættelsesdomæne.

små og mellemstore projekter bruger normalt kun et domæne for enkelhed; dets navn er vilkårligt, men vi bruger “main” til vores kodeprøver.

i Symfony-projekter bruges domæner for eksempel til at adskille oversættelsen til valideringsmeddelelser.

Locale Code

en locale er simpelthen en kode, der identificerer en version af et sprog. Det er defineret efter ISO 639-1 og ISO 3166-1 alpha-2 specs: to små bogstaver til sproget, eventuelt efterfulgt af en understregning og to store bogstaver, der identificerer land eller regional kode.

for sjældne sprog anvendes tre bogstaver.

for nogle talere kan landdelen virke overflødig. Faktisk har nogle sprog dialekter i forskellige lande, såsom østrigsk tysk (De_at) eller brasiliansk portugisisk (pt_BR). Den anden del bruges til at skelne mellem disse dialekter – når den ikke er til stede, tages den som en “generisk” eller “hybrid” version af sproget.

mappestruktur

for at bruge Gettekst skal vi overholde en bestemt struktur af mapper.

først skal du vælge en vilkårlig rod til dine l10n-filer i dit kildelager. Inde i den har du en mappe til hver nødvendig lokalitet og en fast “LC_MESSAGES” – mappe, der indeholder alle dine PO/MO-par.

flertalsformer

som vi sagde i indledningen, kan forskellige sprog have forskellige pluraliseringsregler. Men Gettekst sparer os denne ulejlighed.

når du opretter en ny .po-fil, du bliver nødt til at erklære pluraliseringsreglerne for det sprog, og oversatte stykker, der er flertalsfølsomme, vil have en anden form for hver af disse regler.

når du ringer til Gettekst i kode, skal du angive et nummer relateret til sætningen (f.eks.”, skal du angive værdien af n), og det vil udarbejde den korrekte formular til brug – selv ved hjælp af streng substitution, hvis det er nødvendigt.

Flertalsregler er sammensat af antallet af regler, der er nødvendige med en boolsk test for hver regel (test for højst en regel kan udelades). For eksempel:

• Japansk: nplurals=1; plural=0; – en regel: der er ingen flertalsformer

• engelsk: nplurals=2; plural=(n != 1); – to regler: Brug kun flertalsform, når n ikke er 1, ellers brug entalformularen.

• brasiliansk portugisisk: nplurals=2; plural=(n > 1); – to regler, Brug kun flertalsform, når n er større end 1, ellers brug entalformen.

For en dybere forklaring er der en informativ LingoHub-tutorial tilgængelig online.

Gettekst bestemmer, hvilken regel der skal bruges, baseret på det angivne nummer og bruger den korrekte lokaliserede version af strengen. For strenge, hvor pluralisering skal håndteres, skal du medtage i .po fil en anden sætning for hver flertalsregel defineret.

Sample implementering

efter alt det teori, lad os få lidt praktisk. Her er et uddrag af en .po-fil (du skal ikke bekymre dig endnu for meget om syntaksen, men i stedet bare få en fornemmelse af det samlede indhold):

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"

det første afsnit fungerer som en overskrift, der har msgid og msgstr tom.

det beskriver filkodningen, flertalsformer og et par andre ting. Det andet afsnit oversætter en simpel streng fra engelsk til Brasiliansk portugisisk, og den tredje gør det samme, men udnytter strengudskiftning fra sprintf, hvilket gør det muligt for oversættelsen at indeholde brugernavnet og besøgsdatoen.

det sidste afsnit er en prøve af pluraliseringsformer, der viser ental og flertalsversion som msgid på engelsk og deres tilsvarende oversættelser som msgstr 0 og 1 (efter nummeret givet af flertalsreglen).

der bruges også strengudskiftning, så tallet kan ses direkte i sætningen ved at bruge %d. Flertalsformer har altid to msgid (ental og flertal), så det anbefales at ikke bruge et komplekst sprog som kilde til oversættelse.

Lokaliseringsnøgler

som du måske har bemærket, bruger vi den faktiske engelske sætning som kilde-ID. At msgid er den samme brugt i hele din .po-filer, hvilket betyder, at andre sprog vil have samme format og de samme msgid felter, men oversat msgstr linjer.

når vi taler om oversættelsestaster, er der to standard “filosofiske” tilgange her:

1. msgstr som en reel sætning

de vigtigste fordele ved denne tilgang er:

• hvis der er dele af programmet, der ikke er oversat på et givet sprog, vil den viste nøgle stadig have en vis betydning. For eksempel, hvis du ved, hvordan du oversætter fra engelsk til spansk, men har brug for hjælp til at oversætte til fransk, kan du muligvis offentliggøre den nye side med manglende franske sætninger, og dele af hjemmesiden vises i stedet på engelsk.

• det er meget lettere for oversætteren at forstå, hvad der foregår, og lave en ordentlig oversættelse baseret på msgid.

• det giver dig “gratis” l10n til et sprog – kilden en.

på den anden side er den primære ulempe, at hvis du skal ændre den faktiske tekst, skal du erstatte den samme msgid på tværs af flere sprogfiler.

2. msgstr som en unik, struktureret nøgle

dette ville beskrive sætningsrollen i applikationen på en struktureret måde, inklusive skabelonen eller delen, hvor strengen er placeret i stedet for dens indhold.

dette er en fantastisk måde at få koden organiseret, adskille tekstindholdet fra skabelonlogikken. Det kunne dog give problemer for oversætteren, der ville gå glip af konteksten.

en kildesprogfil ville være nødvendig som grundlag for andre oversættelser. For eksempel ville udvikleren ideelt set have en “en.PO ” fil, at oversættere ville læse for at forstå, hvad de skal skrive i “fr.po”.

manglende oversættelser ville vise meningsløse taster på skærmen (“top_menu.velkommen “i stedet for” Hej der, bruger!”på den nævnte uoversatte franske side).

det er godt, da det ville tvinge oversættelsen til at være komplet før udgivelse – men dårligt, da oversættelsesproblemer ville være virkelig forfærdelige i grænsefladen. Nogle biblioteker inkluderer dog en mulighed for at specificere et givet sprog som “fallback”, der har en lignende opførsel som den anden tilgang.

Gettekstmanualen favoriserer den første tilgang, da det generelt er lettere for oversættere og brugere i tilfælde af problemer. Det er den tilgang, vi også vil bruge her.

det skal dog bemærkes, at Symfony-dokumentationen favoriserer søgeordsbaseret oversættelse for at muliggøre uafhængige ændringer af alle oversættelser uden også at påvirke skabeloner.

daglig brug

i et almindeligt program bruger du nogle få Tekstfunktioner, mens du skriver statisk tekst på dine sider.

disse sætninger vises derefter i .po-filer, få oversat, kompileret i. mo-filer, og derefter brugt af Gettekst, når du gengiver den faktiske grænseflade. I betragtning af det, lad os binde sammen det, vi hidtil har diskuteret i et trin-for-trin eksempel:

1. Et eksempel skabelon fil, herunder nogle forskellige gettekstopkald

<?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() oversætter simpelthen en msgid til dens tilsvarende msgstr for et givet sprog. Der er også stenografi funktion _() der fungerer på samme måde

• ngettext() gør det samme, men med flertalsregler

• der er også dgettext() og dngettext(), der giver dig mulighed for at tilsidesætte domænet for et enkelt opkald (mere om domænekonfiguration i det næste eksempel)

2. En eksempelopsætningsfil (i18n_setup.php som brugt ovenfor), valg af den korrekte lokalitet og konfiguration af Gettekst

brug af Gettekst involverer lidt af en standardtekst-kode, men det handler mest om at konfigurere lokalitetsmappen og vælge passende parametre (en lokalitet og et domæne).

<?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. Forberedelse af oversættelse til første kørsel

en af de store fordele, som tekst har i forhold til brugerdefinerede rammer i18n-pakker, er dens omfattende og kraftfulde filformat.

måske tænker du “Åh mand, det er ret svært at forstå og redigere for hånd, et simpelt array ville være lettere!”Tag ikke fejl, applikationer som Poedit er her for at hjælpe – meget. Du kan få programmet fra deres hjemmeside, det er gratis og tilgængeligt for alle platforme. Det er et ret nemt værktøj at vænne sig til, og en meget kraftfuld på samme tid – ved hjælp af alle funktioner Gettekst har til rådighed. Vi arbejder her med den nyeste version, Poedit 1.8.

i det første løb skal du vælge “File > ny…” i menuen. Du bliver bedt om sproget; vælg / filtrer det sprog, du vil oversætte til, eller brug det format, vi nævnte før, f.eks. en_US eller pt_BR.

Gem nu filen – ved hjælp af den mappestruktur, vi også nævnte. Derefter skal du klikke på” uddrag fra kilder”, og her konfigurerer du Forskellige indstillinger til udvindings-og oversættelsesopgaverne. Du kan finde alle dem senere gennem “katalog > egenskaber”:

• kilde stier: Inkluder alle mapper fra projektet, hvor gettext() (og søskende) kaldes – dette er normalt dine skabeloner/visningsmapper. Dette er den eneste obligatoriske indstilling.

• Oversættelsesegenskaber:

  • Projektnavn og version, Team og teams e-mail-adresse: nyttige oplysninger, der går i .PO fil header.
  • flertalsformer: dette er de regler, vi nævnte før. Du kan lade det være med standardindstillingen det meste af tiden, da Poedit allerede indeholder en praktisk database med flertalsregler for mange sprog.
  • tegnsæt: UTF-8, fortrinsvis.
  • Kildekodetegn: det tegnsæt, der bruges af din kodebase – sandsynligvis også UTF-8, ikke?

• kilde nøgleord: det underliggende program ved, hvordan gettext() og lignende funktionsopkald ser ud på flere programmeringssprog, men du kan lige så godt oprette dine egne oversættelsesfunktioner. Det vil være her, du vil tilføje de andre metoder. Dette vil blive diskuteret senere i afsnittet” Tips”.

når du har indstillet disse egenskaber, kører Poedit en scanning gennem dine kildefiler for at finde alle lokaliseringsopkald. Efter hver scanning viser Poedit en oversigt over, hvad der blev fundet, og hvad der blev fjernet fra kildefilerne. Nye poster vil være tomme i oversættelsestabellen, så du kan indtaste de lokaliserede versioner af disse strenge. Gem det og en .mo fil vil blive (re) kompileret i den samme mappe og, presto!, dit projekt er internationaliseret!

Poedit kan også foreslå almindelige oversættelser fra internettet og fra tidligere filer. Det er praktisk, så du kun skal kontrollere, om de giver mening, og acceptere dem. Hvis du er usikker på en oversættelse, kan du markere den som uklar, og den vises i gult. Blå poster er dem, der ikke har nogen oversættelse.

4. Oversættelse af strenge

som du måske har bemærket, er der to hovedtyper af lokaliserede strenge: enkle og dem med flertalsformer.

Simple dem har kun to bokse: kilde og lokaliseret streng. Kildestrengen kan ikke ændres, da Gettekst/Poedit ikke inkluderer muligheden for at ændre dine kildefiler; snarere skal du ændre selve kilden og scanne filerne igen. (Tip: Hvis du højreklikker på en oversættelseslinje, viser den et tip med kildefilerne og linjerne, hvor strengen bruges.)

Pluralformularstrenge inkluderer to felter til at vise de to kildestrenge og faner, så du kan konfigurere de forskellige endelige formularer.

eksempel på en streng med en flertalsform på Poedit, der viser en oversættelsesfane for hver enkelt.

når du ændrer dine kildekodefiler og har brug for at opdatere oversættelserne, skal du bare trykke på Opdater, og Poedit vil scanne koden igen, fjerne ikke-eksisterende poster, flette dem, der er ændret, og tilføje nye.

Poedit kan også prøve at gætte nogle oversættelser, baseret på andre, du gjorde. Disse gæt og de ændrede poster vil modtage en” uklar ” markør, der angiver, at de har brug for gennemgang, vises i gult på listen.

det er også nyttigt, hvis du har et oversættelsesteam, og nogen prøver at skrive noget, de ikke er sikre på: bare marker det uklar, og en anden vil gennemgå det senere.

endelig anbefales det at lade “Vis > uoversatte poster først” være markeret, da det hjælper dig med at undgå at glemme nogen poster. Fra denne menu kan du også åbne dele af brugergrænsefladen, der giver dig mulighed for at efterlade kontekstuelle oplysninger til oversættere, hvis det er nødvendigt.

Tips & Tricks

internetservere kan ende med at cachelagre dine .mo-filer.

hvis du kører PHP som et modul på Apache (mod_php), kan du have problemer med .mo-filen, der cachelagres. Det sker første gang det læses, og for at opdatere det skal du muligvis genstarte serveren.

på Nginks og PHP5 tager det normalt kun et par sideopdateringer for at opdatere oversættelsescachen, og på PHP7 er det sjældent nødvendigt.

biblioteker giver hjælpefunktioner til at holde lokaliseringskoden kort.

som foretrukket af mange mennesker er det lettere at bruge _()i stedet for gettext(). Mange brugerdefinerede i18n-biblioteker fra rammer bruger også noget, der ligner t(), for at gøre oversat kode kortere. Det er dog den eneste funktion, der har en genvej.

du vil måske tilføje nogle andre i dit projekt, såsom __() eller _n() for ngettext(), eller måske en fancy _r(), der ville deltage i gettext() og sprintf() opkald. Andre biblioteker, såsom oscaroteros Gettekst, giver også hjælpefunktioner som disse.

i disse tilfælde skal du instruere Gettekstværktøjet om, hvordan du udtrækker strengene fra disse nye funktioner. Vær ikke bange, det er meget nemt. Det er bare et felt i .po-fil eller en indstillingsskærm i Poedit (i editoren er denne mulighed inde i “katalog > egenskaber > kilder nøgleord”).

husk: Gettekst kender allerede standardfunktionerne for mange sprog, så vær ikke bekymret, hvis listen virker tom. Du skal medtage specifikationerne for de nye funktioner i denne liste efter dette specifikke format:

• hvis du opretter noget som t(), der blot returnerer oversættelsen for en streng, kan du angive den som t. Gettekst ved, at det eneste funktionsargument er strengen, der skal oversættes;

• hvis funktionen har mere end et argument, kan du angive, hvilken en den første streng er, og om nødvendigt også flertalsformen. For eksempel, hvis vores funktionssignatur er __('one user', '%d users', $number), ville specifikationen være __:1,2, hvilket betyder, at den første form er det første argument, og den anden form er det andet argument. Hvis dit nummer kommer som det første argument i stedet, ville spec være __:2,3, hvilket angiver, at den første formular er det andet argument osv.

efter at have inkluderet de nye regler i .po-fil, en ny scanning bringer dine nye strenge lige så let som før.

gør din PHP-App Flersproget med Gettekst

Gettekst er et meget kraftfuldt værktøj til internationalisering af dit PHP-projekt. Ud over sin fleksibilitet, der tillader støtte til et stort antal menneskelige sprog, giver dens støtte til mere end 20 programmeringssprog dig mulighed for nemt at overføre din viden om at bruge den med PHP til andre sprog som Python, Java eller C#.

desuden kan Poedit hjælpe med at udjævne stien mellem kode og oversatte strenge, hvilket gør processen mere ligetil og lettere at følge. Det kan også strømline delt oversættelsesindsats med sin integration.

når det er muligt, overveje andre sprog dine brugere kan tale. Dette er for det meste vigtigt for ikke-engelske projekter: du kan øge din brugeradgang, hvis du frigiver den på engelsk såvel som dit modersmål.

selvfølgelig har ikke alle projekter behov for internationalisering, men det er meget lettere at starte i18n i løbet af et projekts barndom, selvom det ikke oprindeligt er nødvendigt, end det er at gøre det senere på vejen, hvis det efterfølgende bliver et krav. Og med værktøjer som Gettekst og Poedit er det nemmere end nogensinde.