Hvordan ville du forvandle en pre-eksisterende web app til en flerspråklig en?

stemmer
21

Jeg kommer til å jobbe med et prosjekt der en ganske stor web app må forskjøvet til å håndtere flere språk. Saken går med en håndlaget PHP-kode, men det er ganske ren.

Jeg lurte på hva som ville være den beste måten å gjøre det?

  1. Å gjøre noe på egen hånd, prøver å passe selve arkitekturen.

  2. Omskriving en god del av det ved hjelp av et rammeverk (f.eks Symfony) som skal forvalte i18n for meg?

For alternativ 1, hvor skal jeg lagre i18n data? * .Po, xliff, ren DB?

Jeg tenkte på et alternativ: å bruke Symfony bare for oversettelsen, men å sette kontrolleren til å laste nettstedet som det allerede er. Rask, men skitne. På den annen side, gjør det oss til å gjøre neste endring, beveger seg sakte til full Symfony: Dette nettsted er virkelig en god kandidat for det.

Men kanskje det er noen frittstående oversettelse motorer som ville gjøre jobben bedre enn en hel web rammeverk. Det er litt som å bruke en bazooka å drepe en flue ...

Publisert på 01/10/2008 klokken 09:54
kilden bruker
På andre språk...                            


6 svar

stemmer
12

Arbeid med språk filer.

  1. Erstatte hver tekststreng ved hjelp av en variabel
  2. Lag en språkfil per språk, og i det definere hver variabel med sin tilhørende tekst. (French.inc, dutch.inc ...)
  3. Inkluder riktig fil i hver side.

Det er for små områder.

Hvis få større, erstatte filene med en DB. :)

Svarte 01/10/2008 kl. 09:57
kilden bruker

stemmer
11

Det finnes en rekke måter å takle dette. Ingen av dem "den beste måten", og alle av dem med problemer på kort sikt eller lang sikt. Det aller første du må si er at flerspråklige nettsteder er ikke lett, oversettere og herlige mennesker, men vanskelig å jobbe med, og de fleste programmerere se problemet som en teknisk man bare. Det er også en annen dimensjon, utenfor rammen av dette svaret, som om du skal oversette eller lokalisering. Dette innebærer å se på målgrupper kulturelle skikker og deretter skreddersy språk, stil, layout, farger, skrifttype osv, til denne kulturen. Til slutt ikke bruke MT, Maskinoversettelse, for noe alvorlig eller om det er behov for å være nøyaktig, og når anskaffe oversettere sikre at de oversette fra et fremmed språk til sitt eget morsmål som betyr at de forstår alle nyansene i målspråket.

Ikke sant. Løsninger. På grunnlag av at du ikke ønsker å omskrive nettstedet så bare klone nettstedet du har og oversette kopier til målspråket. Forutsatt at kodebasen er stabil kan du bruke en VCS å håndtere eventuelle kodeendringer. Du kan justere enkelte deler av området for å passe målspråket, for eksempel fransk tekst er i gjennomsnitt 30% større enn den tilsvarende engelske teksten så bruker man for å levere dette betyr at du kan (vil) ha formatering problemer og trenger å bytte en forskjellige css fil inn og ut avhengig av språket. Det kan virke clunky måte å gjøre det, men så hvor lenge er nettstedene kommer til å eksistere? Ledelsen overhead av å gjøre det på denne måten kan godt være mindre enn andre alternativer.

Andre måten uten ombygging. Erstatt alt innhold i gjeldende område med tags og deretter sette annet språk i filen eller db tabeller, snuse brukerne ønsket språk (du har registrert brukere som kan gjøre en preferanse eller ønsker du å få nettleseren språkkode, eller er det kommer til å være URL dot-com dot-fr, dot-de som gjør valget) og deretter erstatte kodene med målspråket. Deretter må du ta opp dimensjonering problemer og bildespørsmål separat. Denne løsningen er i kraft når rammeverk som Symfony og Zend gjøre for å implementere l10n.

Deretter kan du bygge et rammeverk eller med gettext og og muligens ha en renere løsning, men husk rammer ble utviklet for å løse andre problemer, ikke oversettelse og oversettelsen komponenten har kommet inn i rammen som delvis løsning ikke full en.

Det store problemet med alle løsningene er løpende vedlikehold. Fordi ikke ikke bare har du en kode base, men også flere språk baser å vedlikeholde. Med mindre du alt i ett-løsning er virkelig smart og effektiv deretter til løpende oppgave vil være vanskelig.

Svarte 25/10/2009 kl. 07:50
kilden bruker

stemmer
3

Det er viktig å legge merke til at det er to trinn involvert før sette:

  1. Internasjonalisering: det vil si, slik at nettstedet ditt for å håndtere flere språk
  2. Lokalisering: Dette inkluderer oversette tekstene dine (fås i trinn 1) til hvert språk du har tenkt å støtte

Se mer om dette i Wikipedia .

Trinn 1 vil kreve at du tar hensyn til det faktum at noen språk er skrevet fra høyre mot venstre (RTL) og ikke-europeiske tegn, for eksempel japansk eller kinesisk. Hvis du ikke planlegger å håndtere disse språk og tegn kan det være enklere.

For denne typen situasjon ville jeg foretrekker å ha en språkfil (faktisk så mange språkfiler som språk jeg har tenkt å støtte, navngi hvert som langcode.phpsom i en.phpeller fr.php) med en assosiativ array som inneholder alle tekster som brukes i området. Prosedyren vil gå som følger:

  1. Skann nettstedet ditt for hver enkelt tekst som skal lokaliseres
  2. For hver side / del ville jeg lage en $lang['sectionname'][]matrise
  3. For hver tekst ville jeg lage en $lang['sectionname']['textname']oppføring
  4. Jeg ville skape en Lang.phpklasse som skulle få en langparameter ved oppretting, men ville ha en standard i sak nr langmottas (denne metoden laster langcode.phpavhengig av parameter eller en standard avhengig av ønsket språk)
  5. Klassen ville ha en setPage()metode som ville motta side / seksjonen vil du være å vise
  6. Klassen ville ha en show()metode som ville motta teksten som skal vises ( show()vil bli kalt så mange ganger som tekster er vist i en gitt side ... show()å være en slags wrapper for echo $lang['mypage']['mytext'])

På denne måten kan du ha så mange språk som du ønsker på en svært enkel måte. Du kan selv ha et språk admin hvor du åpner din base språket siden (du faktisk bare lese rekursivt arrays og vise dem i textareas) og kan deretter "Lagre som ..." noen andre språk.

Jeg bruker en lignende tilnærming i området mitt . Det er bare én side om, men jeg har gjort på flere sider nettsteder med denne ideen.

Hvis du har bruker innsendt innhold eller noen ganske komplisert CMS det ville være en annen historie. Du kan se etter i18n vennlige rammer (Drupal kommer til hjernen).

Svarte 25/10/2009 kl. 08:09
kilden bruker

stemmer
2

Du kan se på Zend_Translate , det er en ganske omfattende, godt dokumentert og generelle kodekvalitet er stor. Den lar deg også til å bruke en enhetlig API for gettext, csv, db, ini-fil, array eller hva du ender opp med å spare dine oversatte strenger i.

Også se på / se denne tråden: Hva er gode verktøy / rammeverk for i18n av en php kodebase? . Det virker som ligner på spørsmålet ditt.

Svarte 01/10/2008 kl. 11:00
kilden bruker

stemmer
1

Hvis det er multibyte tegnstøtte så kan det være verdt å sjekke ut de multibyte strengfunksjoner i PHP:

http://uk.php.net/manual/en/book.mbstring.php

Disse vil bedre håndtere multi-byte tegn.

Svarte 01/10/2008 kl. 11:07
kilden bruker

stemmer
-2

Jeg bruker hl parameter og gettext kombinere motor oversettelser allerede der med egen .po som gjør nye oversettelser og språk vises når motoren eller min Django / gae eksempel legger til:

{% get_current_language as LANGUAGE_CODE %}{{ LANGUAGE_CODE }}{% get_available_languages as LANGUAGES %}{% for LANGUAGE in LANGUAGES %}{% ifnotequal LANGUAGE_CODE LANGUAGE.0 %}{{ LANGUAGE.0 }}{% endifnotequal %}{% endfor %}

Så å holde fra duplikater og fullt hjelp oversettelser allerede det lar frem her mangler f.eks arabisk måneden navnene skal vises direkte enten når motoren teamet legger til eller app

Svarte 25/10/2009 kl. 04:31
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more