Internasjonalisering i prosjekter

stemmer
44

Hvordan har du implementert Internasjonalisering (i18n) i faktiske prosjekter du har jobbet med?

Jeg tok en interesse i å gjøre software tverrkulturell etter at jeg leste den berømte innlegg av Joel, det absolutte minimum Hver Software Developer absolutt, positivt må vite om Unicode og tegnsett (Ingen unnskyldninger!) . Men jeg har ennå ikke i stand til å dra nytte av dette i et reelt prosjekt, i tillegg til å sørge for at jeg brukte Unicode-strenger der det er mulig. Men gjør alle dine strenger Unicode og sørger for at du forstår hva koding alt du jobber med er i er bare toppen av i18n isfjellet.

Alt jeg har jobbet med hittil har vært for bruk av en kontrollert sett med amerikanske engelsktalende mennesker, eller i18n bare var ikke noe vi hadde tid til å jobbe på før du skyver prosjektet levende. Så jeg er ute etter noen tips eller krigshistorier folk har om å gjøre programvaren mer lokalisert i reelle prosjekter.

Publisert på 04/08/2008 klokken 00:08
kilden bruker
På andre språk...                            


11 svar

stemmer
48

Det har vært en stund, så dette er ikke fullstendig.

tegnsett

Unicode er stor, men du kan ikke komme unna med å ignorere andre tegnsett. Standard tegnsett på Windows XP (engelsk) er Cp1252. På nettet, trenger du ikke vet hva en nettleser vil sende deg (men forhåpentligvis beholderen vil håndtere det meste av dette). Og ikke bli overrasket når det er feil i hva implementering du bruker. Tegnsett kan ha interessante interaksjoner med filnavn når de flytter til mellom maskiner.

sette Strings

Oversettere er, generelt sett, ikke programmerere. Hvis du sender en kilde fil til en oversetter, vil de bryte den. Strenger bør trekkes ut til ressursfiler (f.eks egenskaper filer i Java eller ressurs DLL-filer i Visual C ++). Oversettere bør gis filer som er vanskelig å bryte og verktøy som ikke la dem bryte dem.

Oversettere vet ikke hvor strenger kommer fra i et produkt. Det er vanskelig å oversette en streng uten sammenheng. Hvis du ikke gi veiledning, vil kvaliteten på oversettelsen lide.

Apropos av kontekst, kan du se den samme strengen "foo" dukker opp i flere ganger og tror det ville være mer effektivt å ha alle forekomster i brukergrensesnittet peker til den samme ressursen. Dette er en dårlig idé. Ord kan være svært kontekstavhengig i noen språk.

Sette strenger koster penger. Hvis du slipper en ny versjon av et produkt, er det fornuftig å gjenopprette de gamle versjonene. Har verktøy for å gjenopprette strenger fra gamle ressursfiler.

Streng sammensetning og manuell manipulering av strenger bør minimaliseres. Bruke funksjonene format der det er aktuelt.

Oversettere må være i stand til å endre hurtigtaster. Ctrl+ PEr print på engelsk; tyskerne bruk Ctrl+ D.

Hvis du har en oversettelse prosess som krever noen til å klippe og manuelt lime strenger til enhver tid, ber du om trøbbel.

Datoer, klokkeslett, Kalendere, valuta, antall formater, tidssoner

Disse kan alle variere fra land til land. Et komma kan brukes til å betegne desimaler. Ganger kan være i 24-timers notasjon. Ikke alle bruker den gregorianske kalenderen. Du må være entydig, også. Hvis du tar vare å vise datoer som MM / DD / ÅÅÅÅ for USA og DD / MM / ÅÅÅÅ for Storbritannia på nettstedet ditt, datoene er tvetydige med mindre brukeren vet du har gjort det.

spesielt Valuta

Lokalitets funksjonene som tilbys i klassebiblioteker vil gi deg lokal valuta symbol, men du kan ikke bare holde et pund (sterling) eller euro symbol foran en verdi som gir en pris i dollar.

brukergrensesnitt

Layout bør være dynamisk. Ikke bare er strenger sannsynlig å doble i lengde på oversettelsen, kan hele UI måtte snus (hebraisk, arabisk), slik at kontrollene går fra høyre til venstre. Og det er før vi kommer til Asia.

Testing før Oversettelse

  • Bruk statisk analyse av koden for å finne problemer. På et minimum, utnytte de verktøy innebygd i IDE. (Eclipse brukere kan gå til Window> Innstillinger> Java> Compiler> Feil / advarsler og sjekk for ikke-utagerende strenger.)
  • Røyk test ved å simulere oversettelse. Det er ikke vanskelig å analysere en ressurs fil og erstatte strenger med en pseudo-oversatt versjon som dobler lengden og setter funky tegn. Du trenger ikke å snakke et språk å bruke en utenlandsk operativsystem. Moderne systemer bør la deg logge inn som en ekstern bruker med oversatte strenger og utenlandske locale. Hvis du er kjent med operativsystemet ditt, kan du finne ut hva som gjør hva uten å vite et eneste ord av språket.
  • Tastatur kart og tegnsett referanser er svært nyttig.
  • Virtualisering vil være svært nyttig her.

Ikke-tekniske problemer

Noen ganger må du være følsomme for kulturelle forskjeller (krenkelser eller uforstand kan resultere). En feil du ofte ser er bruk av flagg som et visuelt velge et nettsted språk eller geografi. Med mindre du vil at programvaren til å erklære sider i global politikk, er dette en dårlig idé. Hvis du var fransk og tilbudt muligheten for engelsk med St. George flagg (flagg England er et rødt kors på et hvitt felt), dette kan føre til forvirring for mange engelsktalende - anta lignende problemer vil oppstå med fremmedspråk og land . Ikoner må vetted for kulturell relevans. Hva gjør en tommelen opp eller en grønn hake betyr? Språk bør være forholdsvis nøytral - adressering brukerne på en bestemt måte, kan være akseptabelt i en region, men anses frekk i en annen.

ressurser

C ++ og Java-programmerere kan finne ICU nettstedet nyttig: http://www.icu-project.org/

Svarte 04/08/2008 kl. 17:58
kilden bruker

stemmer
15

Noen morsomme ting:

  1. Å ha en PHP og MySQL-program som fungerer godt med tysk og fransk, men nå må støtte russisk og kinesisk. Jeg tror jeg flytte denne over til Net, som Unicode-støtte PHP er - etter min mening - virkelig ikke bra. Jada, sjonglerer rundt med utf8_de / kode eller mbstring-funksjoner er gøy. Nesten like gøy som å ha Freddy Krüger besøke deg om natten ...

  2. Innser at noen språk er mye mer Verbose enn andre. Tysk er mye mer detaljert enn engelsk vanligvis, og se hvordan den tyske versjonen ødelegger brukergrensesnittet for liten plass ble tildelt var ikke morsomt. Noen produkter har fått noen berømmelse for sine kreative måter å omgå det, med Oblivion er "Schw.Tr.d.Le.En.W." å være minneverdig :-)

  3. Spille rundt med datoformater, woohoo! Ja, det er faktisk mennesker i verden som bruker datoformater der dagen går i midten. Sooooo mye moro å prøve å finne ut hva 07/02/2008 er ment å bety, bare fordi noen brukere kan tro det kunne være 2 juli ... Men så igjen, kan dere over dammen mener det samme om brukere som setter den måned i midten :-P, spesielt fordi i engelsk 2. juli høres mye bedre enn den andre juli, noe som ikke nødvendigvis gjelder for andre språk (dvs. i tysk, du vil aldri si juli 2, men alltid Zweiter juli). Jeg bruker 2008-02-07 når det er mulig. Det er klart at det betyr 7 februar, og det sorterer riktig, men dd / mm vs. dd / mm kan være en veldig vanskelig problem.

  4. Anoter morsom ting, Tallformater ! 10.000,50 vs 10,000.50 vs 10 000,50 vs. 10'000,50 ... Dette er mitt største mareritt akkurat nå, å måtte støtte en flerkulturell environent men ikke har noen måte å pålitelig vite hva tallformat brukeren vil bruke.

  5. Formell eller uformell. I noen språk, er det to måter å løse mennesker, en formell måte og en mer uformell måte. På engelsk, du bare si "du", men på tysk du må bestemme mellom formelle "Sie" og den uformelle "Du", samme for fransk Tu / Vous. Det er vanligvis et sikkert kort å velge formell måte, men dette er lett oversett.

  6. Kalendere. I Europa, den første dagen i uken er mandag, mens i USA er det søndag. Kalender Widgets er fin. Viser en kalender med søndag til venstre og lørdag om retten til et europeisk brukeren er ikke så fint, forvirrer det dem.

Svarte 04/08/2008 kl. 00:35
kilden bruker

stemmer
8

Jeg jobbet på et prosjekt for min tidligere arbeidsgiver som brukes NET, og det var en innebygd .resx format vi brukte. I utgangspunktet hadde vi en fil som hadde alle oversettelser i .resx filen, og deretter flere filer med ulike oversettelser. Konsekvensen av dette er at du må være veldig flittig om å sikre at alle strenger synlige i søknaden lagres i .resx, og når som helst en endres du må oppdatere alle språk du støtter.

Hvis du får lat og ikke varsle folk ansvaret for oversettelser, eller du legge strenger uten å gå gjennom lokalisering systemet, vil det være et mareritt å prøve å fikse det senere. Tilsvarende, hvis lokalisering er en ettertanke, vil det være svært vanskelig å få på plass. Ergo, hvis du ikke har alle synlige strenger som er lagret eksternt i en standard plass, vil det være svært vanskelig å finne alt som trenger å bli lokalisert.

En annen kommentar, veldig strengt unngå å sette sammen synlige strenger direkte, for eksempel

String message = "The " + item + " is on sale!";

I stedet må du bruke noe sånt

String message = String.Format("The {0} is on sale!", item);

Grunnen til dette er at forskjellige språk ofte bestille ordene annerledes, og sette sammen strenger direkte trenger et nybygg for å fikse, men hvis du har brukt noen form for streng erstatning mekanisme som ovenfor, kan du endre din .resx fil (eller hva lokalisering filer du bruker) for det aktuelle språket som trenger å endre rekkefølgen på ordene.

Svarte 04/08/2008 kl. 00:23
kilden bruker

stemmer
5

Jeg var bare å lytte til en podcast fra Scott Hanselman i morges, der han snakker om internasjonalisering, spesielt de virkelig vanskelige ting, som tyrkisk (med det er fire i tallet) og Thai. Også Jeff Atwood hadde en post :

Svarte 04/08/2008 kl. 15:04
kilden bruker

stemmer
3

I tillegg til alle de tidligere tips, husk at i18n det er ikke bare om å endre ord for deres tilsvarende på andre språk, spesielt for ikke-latinske språk alfabeter (koreansk, arabisk) som skrives fra høyre mot venstre, slik at hele UI må samsvare, som

  • punkt 1
  • punkt 2
  • punkt 3

måtte være

arabisk tekst 1 -

arabisk tekst 2 -

arabisk tekst 3 -

(Omvendt kule liste ikke synes å virke: P)

som kan være en UI mareritt hvis systemet har for å bruke endringene dinamically gang brukeren endrer språket som brukes.

En annen veldig vanskelig ting er å teste forskjellige språk, ikke bare for riktigheten av ordet, men siden språk som koreansk vanligvis har større skrifttype for sine karakterer kan dette føre til språkspesifikke bugs (som "SAVE" tekst på en knapp være større enn selve knappen for noen språk).

Svarte 21/09/2008 kl. 23:44
kilden bruker

stemmer
2

En av de funnier ting å oppdage: kursiv og fet tekst makrup fungerer ikke med CJK (kinesisk / japansk / koreansk) tegn. De rett og slett blitt uleselig. (OK, jeg kunne egentlig ikke lese dem før heller, men spesielt fet skrift skaper bare blekk blotter)

Svarte 14/10/2008 kl. 12:39
kilden bruker

stemmer
1

En annen utfordring vil være å akseptere innspill fra brukerne. I mange tilfeller er dette lindres ved inngangs behandling gitt av operativsystemet, for eksempel IME i Windows, som fungerer transparent med vanlige tekst widgets, men dette anlegget vil ikke være tilgjengelig for alle mulige behov.

Svarte 27/12/2008 kl. 06:48
kilden bruker

stemmer
1

Jeg foreslår å bruke noe sånt 99translations.com å opprettholde oversettelser. Ellers vil du ikke være i stand til å fortelle hva oversettelser dine er oppdatert på alle språk.

Svarte 27/12/2008 kl. 04:05
kilden bruker

stemmer
1

Jeg tror alle som jobber i internasjonalisering bør være kjent med Common Locale data Repository, som nå er et delprosjekt av Unicode:

Common Locale dataregister

De folkene jobber hardt for å etablere en standard ressurs for alle typer i18n problemstillinger: valuta, geografiske navn, tonnevis av ting. Ethvert prosjekt som har beholdt sin lokale egen kjernedata gitt at dette prosjektet foreligger er ganske bonkers, IMHO.

Svarte 18/09/2008 kl. 19:25
kilden bruker

stemmer
0

En ting ingen har nevnt ennå er strenger med noen warying del som i "Enheten vil arive i 5 dager" eller "På mandag noe skjer." hvor 5 og mandag vil endre seg avhengig av tilstand. Det er ikke en god idé å dele de i to og sette sammen dem. Med bare en varierende del og god dokumentasjon kan du komme unna med det, med to forskjellige deler vil det være noen språk som preferes å endre rekkefølgen på dem.

Svarte 07/10/2008 kl. 10:56
kilden bruker

stemmer
0

Ett nettsted jeg bruker har en oversettelse metode eieren kaller "wiki + maskin oversettelse". Dette er et fellesskap basert nettsted så er åpenbart annerledes enn behovene til bedrifter.

http://blog.bookmooch.com/2007/09/23/how-bookmooch-does-its-translations/

Svarte 10/09/2008 kl. 15:12
kilden bruker

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