Jesper snackar dynga då och då. Här är beviset. : General localization

Localization Quality

jesperh — Tue, 17 Mar 2009 08:07:00 GMT

Localization bugs are often classified into these symptom buckets:

Build/BVT (1) breaks

This kind of bug would make it impossible to produce a localized build, or would make a build completely unusable. These bugs are increasingly rare; when they do occur, they're hard not to notice, so customers should never suffer this.

Functional

This kind of bug is one where functionality is affected. It might be as serious as an application crashing because of a localization bug, or as trivial as a menu with duplicate hotkeys.

These bugs typically occur because a dependency between code and localization has been broken. Maybe a translation is longer than code allows (2). Or maybe a translation contains more placeholders than expected - think:
Console.WriteLine("Are you sure you want to {0} the file \"{1}\"", fi.Name);

These days we're pretty good at preventing these bugs, and test automation finds most of the ones that aren't prevented. We're still not perfect - there's always room for weird problems (3), but we've gotten pretty good.

Cosmetic

This kind of bug usually affects layout or display. They might make Windows look ugly or they might confuse the user, but they typically don't cause any loss of functionality.

Common causes are poor layout (4) and truncated text (5).

This is tricky to prevent, because the difference between what the translator sees and the user sees is growing with every Windows release. Auto-layout technologies give the translator less control over the look'n'feel and makes it harder to predict how a translation will be used. Controls may be rendered slightly differently depending on e.g. DPI setting. Font linking makes things interesting. Text is often supplied at runtime. These are just some reasons why it's hard to predict and prevent cosmetic issues.

The good news is that test automation is pretty good at spotting clipped text. Many issues can be found fairly easily. Other types of cosmetic issues (e.g. misaligned controls) are harder to spot through automation and may slip through.

Linguistic

This is the final bucket. This covers translations that are too vague, too specific, or totally wrong. It covers typos, poor grammar, inconsistent terminology and style, profanity, and other fun stuff.

These types of issues are the hardest to prevent and to spot.

We're dealing with natural language, which is iffy enough when processing large bodies of text. Software often deals with disconnected paragraphs, sentences or even fragments. Automated tests therefore tend to either have low coverage or be very noisy.

Different languages have different rules , which makes it expensive to create and maintain validation. The rules for a given language may change across time and projects - maybe there's a spelling reform or a terminology change; the new rules are in effect for Windows 7, but the old rules may still apply for Windows Vista Service Pack 2. Oftentimes linguistic bugs are subjective - what one person might consider a show-stopper; someone else might think is perfectly fine.

Of course, fixing one bug may cause another. Maybe a string is abbrev'd to work around a functional problem, but the result may be an ugly transl'n.

Oftentimes, there's disagreement whether something should even be translated. Service display names? Event provider names? Command line utilities? The display names of Unicode characters (6)? Different language versions of Windows have made different decisions.

What'll Windows 7 Look Like?

Linguistic bugs is definitely our weakest area. Linguistic bugs are hard to prevent and expensive to find, but we try and we are getting better. We spend a lot of effort on terminology work before and through-out any new Windows version. In Windows 7, our translators are given better context than ever before. Language packs makes it very easy to try out languages, which enables broader self-hosting within Microsoft. The amount of user interface being reviewed for linguistic issues is higher in Windows 7 than in any previous version.

That's not to say that we're "done". The whole reason for my group - Windows International - to exist is to produce localized versions of Windows and related projects. Now, there's a difference between the Highest Possible Quality and the Highest Quality Possible. We're aiming for the former; we're still not even achieving the latter.

In fact, I don't think we can achieve this on our own. We desperately need the help of users across the globe. Some languages are available under the beta programs, but that's not nearly enough. I think we have a lot of work to do to simply make it possible for any user to offer their help and for us to listen and react.

Make no mistake, localized Windows 7 will look good. But we got a ton of work to do to make Windows 8 noticably better.

(1) BVT: Build Verification Test. Answers questions like "Can this build even be installed?"
(2) E.g. http://blogs.msdn.com/jesperh/archive/2004/12/23/331412.aspx.
(3) E.g. http://blogs.msdn.com/jesperh/archive/2004/11/15/257694.aspx
(4) E.g. http://blogs.msdn.com/jesperh/archive/2006/07/25/678001.aspx, http://blogs.msdn.com/jesperh/archive/2004/12/08/278403.aspx
(5) E.g. http://blogs.msdn.com/jesperh/archive/2004/12/14/301273.aspx
(6) http://blogs.msdn.com/jesperh/archive/2004/12/15/316184.aspx; Swedish text

Blue Belle, och andra över- och undersättningsproblem

jesperh — Thu, 22 Nov 2007 10:56:00 GMT

”JFK-flygplatsen ligger längst ut i Queens, nära gränsen till Long Island, och sticker ut i bukten. Den omgivande träskmarken genomkorsas av tvåfiliga avfarter från motorvägen. Lagerbyggnader, lätt industri, motell.

Vägverket håller vägarna i skick, men de slösar inga pengar på gatlysen. Ett paradis för banditer.”

I augusti bröt jag vänster handled. Sved rätt bra. Veckorna därefter läste jag mer skönlitteratur än jag gjort sen, tja, nittiotalet säkert. Bland annat gick jag igenom alla mina Vachss-böcker (1), inklusive Blue Belle. Och denna på svenska, må du tro (2). Just den här boken måste ha följt med mig sen jag pluggade på Hvitfeldtska Gymnasiet.

Citatet ovan är inledningen på kapitel 25. När jag läste det var jag något distraherad av både smärta & smärtstillande, så kanske var det inte så konstigt att jag blev fascinerade. Av själva översättningen. Av ordvaldet. Vägverket.

”Klart som korvspad att Vägverket inte sponsrar gatlyktor ute i Queens”, tänkte jag, ”varför skulle svenska Vägverket mecka runt i New York?”

Så här lyder källtexten (3):

”JFK Airport sits at the end of Queens, near the Long Island border, sticking out into the bay. The surrounding swampland is slashed with two-lane side roads running off the expressway. Warehouses, light industry, short-stay motels.

The Highway Department keeps the roads in good shape, but they don’t waste any money on streetlights. A bandit’s paradise.”

Överlag, tycker jag, en alldeles förträfflig översättning. ”Slashed” översattes med ”genomkorsad” – kanske är ordet i källtexten något mer dramatisk, men översättaren lyckades hitta ett ord som målar upp samma bild utan att låta krystat. ”Short-stay motels” blev helt enkelt ”motell”, för med våra referensramar var ordet ”short-stay” garanterat överflödigt.

Men att ”Highway Department” blev ”Vägverket”? Bra eller dåligt? Rätt eller fel? Tja.

Vi brottas med snarlika problem när vi lokaliserar programvara på Microsoft: källtexten innehåller ofta ett par ord som ser ut att kunna vara en produktreferens, men som lika gärna kan hänvisa till ett allmänt begrepp. Om det rör sig om ett allmänt begrepp, då har man hyfsat stor frihet att leka med formuleringen – bara själva meddelandet går fram. Man kan använda strikt terminologi eller en lite lösare beskrivning, beroende på vad som verkar passa bäst. Om orden däremot refererar till en produkt eller en funktion i programvaran, då bör vi givetvis vara konsekventa med produktens eller funktionens namn.

Kanske låter detta enkelt och uppenbart, men ju mer man funderar, desto klurigare blir det. Här är ett fiktivt exempel på en programvarusträng:

”There is no disk with sufficient space. Free up at least 100 MB and try again.”

Notera ordet ”disk” här. Det är tydligt att det inte refererar till en specifik produkt eller program, så det måste vara ett allmänt begrepp. Men vad innefattar ”disk”? Enbart hårddiskar? Alla slags skrivbara, lokalt anslutna media – inklusive hårddiskar, disketter, flash-minnen, DVD+R-skivor, DAT-band, osv? Eller bara media som traditionellt anses vara permanent anslutna? Kanske allt som har en enhetsbeteckning, inklusive resurser på fjärrmaskiner? Varför var den som skrev källtexten inte mer specifik?

Utan att veta hur strängen används, kan man inte veta vad rätt svar är. Man kan bara gissa. Säg att ”disk” enbart refererar till enbart lokala hårddiskar, om man då väljer en alltför vag översättning – ”Det finns ingen enhet […]” , då blir användaren frustrerad om han har kopplat in ett USB-minne som har mer än tillräckligt utrymme. Men om man översätter ”disk” till ”hårddisk” och det faktiskt refererar till precis vilket slags skrivbart lagringsmedium som helst, då kan man lura användaren att avinstallera program eller rensa bort ”semesterbilder” från fotobiblioteket helt i onödan. Oavsett, översättaren har misslyckats. Ju mer man gissar, desto mer gissar man fel.

Vi som har arbetat med svensk lokalisering i synnerhet har nog inte hjälpt situationen heller. Testa detta: Klicka på Start, Kör. Skriv ”services.msc” och klicka på OK. (Klicka på Fortsätt om du kör Vista och om du litar på mig…) Nu visas nog snapin-modulen Tjänster, där du kan se vilka tjänster – bakgrundsprogram – som är installerade på datorn. Notera att nästan alla tjänstnamn är på engelska, men antagligen ser du några som är översatta till svenska. I så fall ser du några översättningsmisstag. På min hemdator ser jag exakt fem sådana (4).

Vid något tillfälle bestämdes det att sådan här text – visningsnamn på tjänster – inte skulle översättas. Beslutet var inte enkelt. Många högljudda röster hördes. Men till slut fattades ett beslut utifrån de argument som gavs. Jag kommer inte ihåg alla argument längre, men de jag kommer ihåg just nu kan summeras som:

· Vissa tjänstnamn kan helt enkelt inte översättas, så listan skulle kunna innehålla en blandning av engelska och svenska – lika bra att låta allt vara oöversatt, för det är i alla fall konsekvent.

· Om man över huvud taget tittar i just den här listan då vet man vad man sysslar med, och då förstår man engelska.

· Många tjänstnamn är så kryptiska att det är helt enkelt omöjligt att hitta någon svensk översättning som betyder något över huvud taget. Lika bra att lämna hela rasket på engelska.

Personligen tycker jag att det sista plus det första skälet är starkt nog att låta regeln leva kvar: Översätt inte om det bara blir svårare att förstå och översätt inte endast det som är enkelt. Det andra argumentet är mer tveksamt, men det är en helt annan diskussion.

OK, så det finns en fast regel för en väldigt specifik slags text. Översätt inte. Verkar enkelt, va? Men nu måste återigen översättaren förstå hur en viss sträng används, eller vad en viss del av en mening faktiskt hänvisar till. Och det kan vara svårare än vad man först tror.

Det finns tjänster som ”Application Information”, ”Cryptographic Services”, ”DHCP Client” och ”Workstation”. Visningsnamnen för dessa tjänster ska inte översättas, men det betyder inte att dessa ord aldrig kan översättas. Om man ser en sträng med enbart ordet ”Workstation”, hur kan man som översättare vet om den ska översättas eller ej? Är det just den här strängen som bestämmer visningsnamnet på systemtjänsten ”Workstation”, eller är det här bara en beskrivning av en viss dators roll i en viss miljö?

Låt oss säga att vi kunde identifiera vilka strängar som bestämmer visningsnamn för tjänster (vilket vi faktiskt kan med acceptabel korrekthet), hur gör vi med programfunktioner som har samma namn som systemtjänster? Dags för ytterligare ett exempel, denna gång fiktivt:

”If you use the Automatic Updates control panel applet to disable the Automatic Updates service, your computer will receive automatic updates”

Här har vi 1) en referens till en funktion i Kontrollpanelen, vilken ska översättas konsekvent med funktionens faktiska namn, 2) en referens till en systemtjänst, vilken ju inte ska översättas, och 3) en referens till automatiska uppdateringar som ett allmänt begrepp. Fiktivt, visst, men snarlika exempel finns i programvaran. Vilken av dessa termer översätter man hur?

Åter till Blue Belle. Vachss skrev ”The Highway Department keeps the roads in good shape, but they don’t waste any money on streetlights.”. ”The Highway Deptarment” översattes till ”Vägverket” med stort V, vilket jag tyckte såg lite konstigt ut.

Låt oss se vilka alternativ översättaren hade för att översätta ”the Highway Department”:

1) Behandla det som en systemtjänst; referera direkt till den amerikanska – eller New Yorkska – myndighet som skiter i att belysa vägen i fråga.

2) Behandla det som en systemtjänst, men en som ska översättas.

3) Referera till ”vägverket” som ett allmänt begrepp, underförstått ”den amerikanska motsvarigheten till vårt svenska vägverk”.

När jag läste boken – med sveda i näven och opiater i hjärnan, förvisso – tolkadet jag det direkt som om översättaren valde alternativ 2, och detta irriterde min hypoterminologus (5). Mycket, tror jag, för att det verkade inkonsekvent – man översatte inte ”JFK”, ”Queens” eller ”Long Island”, så varför översätta ”Highway Department”?

Om översättaren hade valt alternativ 1 istället, hade detta låtit bättre? ”Highway Department håller vägarna i skick, men de slösar inga pengar på gatlysen.” Um, nej, det hade låtit rätt fjantigt, tycker jag nu, i relativt nyktert tillstånd. Det är nog OK att låta referenser till lokal geografi vara på originalspråket när det inte finns någon etablerad översättning, men samma princip funkar inte riktigt för allmänna samhällsfunktioner som har svenska motsvarigheter.

Bättre hade varit alternativ 3. Men hur skulle det låta? Enkelt – om jag ignorerar min svenska bok och direkt översätter källtexten får jag: ” Vägverket håller vägarna i skick…”. Men för fan! Nu är jag tillbaka till det jag störde mig på! Vägverket med versalt V!

Nytt försök: ”Den lokala motsvarigheten till Vägverket…” - stop, no and don’t (6). Det där låter alldeles för formellt. Nu låter det helt enkelt inte trovärdigt – den som ”pratar” har bott i New York hela sitt liv. Vadå ”lokal motsvarighet”? Inte snackar han så.

Men nu då: ”Den avdelning som ansvarar för att underhålla vägarna…” nej nej nej. Krystat. Dels är det ospecifikt. Men vad värre är, ”jag” i boken är djupt kriminell, ”jag” ifrågasätter inte hur samhället i stort är organiserat och skulle därför inte peka ut specifik avdelning. Burke – huvudpersonen – vill inte förbättra situationen; han vill visa att han är medveten om de förhållanden som råder där han råkar befinna sig, och att han har lagt märkte till dessa ifall han kan använda dem till sin fördel senare.

Det här då: ” Asfalten är i gott skick, men ingen har investerat i gatulyktor”. Nu har jag gått alltför långt från källtexten: en stor del av poängen är skillnaden i värderingar mellan Burke och samhället i stort. Vachss visade att Burke hade medvetande om, om än inte empati för, the Highway Department. Vem är jag som översättare att ta bort detta? Mitt försök till fri översättning är helt värdelöst.

Bara att krypa till korset. Jag hade nog fel. Jag lät mig luras av att ”vägverket” var det första ordet i meningen och därför gavs ett versalt V. Jag trodde att översättaren hänvisade till vår version av Vägverket, men faktiskt avsågs den allmänna, regionsoberoende funktion som representeras av det vi kallar Vägverket. Och vad kunde bättre beskriva detta begrepp än just ordet ”vägverket”, med gement ”v”?

Vad är oklart? Förutom J-per H-bergs H-järna?

Vad fan är poängen? Tja, det är ofta lätt att kritisera andras lösningar. Men det är än oftare svårare att hitta en bättre lösning själv. Framför allt när det gäller saker som, relativt sett, inte spelar någon som helst roll.

Fotnötter:

(1) Vachss: se http://www.vachss.com/.

(2) Blue Belle. Bra Böcker; översättning av Gunilla Dahlblom och K G Johansson; ISBN: 91-7119-838-5

(3) Blue Belle, The Bodley Head. Jag köpte denna på Chapters i Dublin för £3.50. ISBN: 0-370-31316-x, men se även http://www.amazon.com/Blue-Belle-Andrew-Vachss/dp/0679761683/ref=sr_1_1?ie=UTF8&s=books&qid=1195717669&sr=1-1.

(4) De här ser jag på min Vista-burk hemma i skrivande stund:

· Läsartjänsten USN Journal för mappdelning i Messenger

· Net.Msmq-lyssnaradapter

· Net.Pipe-lyssnaradapter

· Net.Tcp-lyssnaradapter

· Net.Tcp-portdelningstjänst

Brasklapp: Ingen av dessa kommer från filer som jag arbetat med. De kommer alla från tilläggskomponenter.

(5) Ungefär som hypothalamus, men mer av en arbets- och miljöskada. Tur att man bor i USA; jag såg precis en reklamsnutt på TVn om en advokat som sysslar med preics såna hära fall. Precis efter reklamen för medicin mot Restless Leg Syndrome.

(6) Redman. The Blackout Tape.

Ny release, nya buggar...

jesperh — Wed, 10 Jan 2007 22:53:00 GMT

Svensk IE7 nådde massorna strax före jul och svensk Windows Vista är på väg ut till butikerna - vissa kan redan hämta Vista från MSDN. Detta är alltså ett bra tillfälle att börja söka efter kommentarer från de användare som inte kunde delta i betaprogrammet.

Än så länge är det givetvis svårt att hitta feedback om svensk IE7/Vista, men jag snubblade över den här bloggposten: http://slammastera.blogspot.com/2006/12/bugg-i-ie7.html.

Problemet är följande: Om man startar svensk IE7 och öppnar menyn Sida ser man att kommandot "Nytt fönster" har acceleratorn Ctrl+W. Detta stämmer dock inte; Ctrl+W stänger aktuell flik (eller hela IE-instansen, om endast en flik är öppen). Rätt kommando för att öppna ett nytt fönster är istället Ctrl+N.

Jag har forskat i problemet, och så här ligger det till:

Detta rör sig om ett menyalternativ som även visar vilken accelerator som kan användas för att nå samma funktion. Som vi alla vet definieras den accelerator som visas i menyn helt separat från den accelerator som faktiskt leder till funktionen.*

Mitt favoritlokaliseringsverktyg har en funktion för automatöversättning, vilket innebär att vi kan översätta en strängresurs en gång och sedan återvinna översättningen när samma källtext förekommer igen. Den här funktionen är smart nog att identifiera och ignorera acceleratorer när den söker efter matchningar, men korkad nog att den i vissa fall kan resultera i en sträng där acceleratorn i översättningen skiljer sig från källtexten och från den accelerator som faktiskt fungerar.

Just den här strängen förekommer flera gånger i filen ieframe.dll, en av huvudfilerna för Internet Explorer 7. En av förekomsterna av strängen är den som visas i Arkiv-menyn, en annan förekomst används i Sida-menyn. Båda strängarna har följande källtext: "&New Window\tCtrl+N". Den första förekomsten översattes helt korrekt till "&Nytt fönster\tCtrl+N". På morgonen den 2006-03-15 automatöversatte sedan undertecknad den andra förekomsten - men av något skäl blev resultatet "&Nytt fönster\tCtrl+W". Varför? Ingen aning, faktiskt. Acceleratorerna i IE7 ändrades rätt ofta runt den här tiden, kanske användes tidigare Ctrl+W i källtexten och kanske innehöll den databas jag automatöversatte från en tidigare översättning med Ctrl+W... svårt att veta nu.

(Det är värt att notera att vi inte har någon funktionell bugg här, utan "bara" en ganska missvisande översättning. Acceleratorerna Ctrl+N och Ctrl+W fungerar som det är tänkt, men en av översättningarna kan lura användaren att använda fel accelerator. Ungefär som om man hade råkat översätta "OK" till "Avbryt" och "Cancel" till "OK". Kanske verkar detta som hårklyverier, men skillnaden innebär att det är lätt och säkert att fixa.)

Nu tänker kanske Vän av ordning att om acceleratorer är så vanliga och om Holmberg ska skylla på verktygen, borde inte detta problem finnas på fler ställen? I så fall har Vän av ordning helt rätt. Man kan hitta liknande miss på ytterligare ett halvdussin ställen i svensk Vista. Det tydligaste exemplet är i Kungen. Menyalternativet för funktionen "Ångra" visar att F10 är en giltig accelerator, men i själva verket är det Ctrl+Z som gäller.

I det här fallet kan jag tydligt se vad som skedde. Tidigt under Vista användes faktiskt F10 som accelerator för "Ångra". Vid något tillfälle ändrade utvecklaren accelerator till Ctrl+Z; vi såg att strängen i uppdaterats; vi automatöversatte och automatöversättningen återanvände glatt den tidigare acceleratorn.

Jag har kontrollerat ett dussin andra språk, och det verkar som om de flesta har en handfull sådana här problem. Mönstret börjar bli ganska tydligt; det rör sig ofta om situationer då acceleratorn har uppdaterats under projektets gång.

Ok, så nu har vi hyfsad förståelse för hur problemet uppstår. Vad gör vi åt det?

1) Jag har lagt in en bugg om just Ctrl+W-buggen i svensk IE7 och ska hoppas kunna fixa den strängen i Vista SP1. Det bör ta hand om just den här förekomsten.
2) Vi håller på att bygga på våra kvalitetskontrollverktyg så att de i framtiden kan fånga upp sådana här problem. Det bör innebära att vi tidigt kan upptäcka om detta sker igen, oavsett språk.
3) Vi ska försöka få automatöversättningsfunktionen fixad så att den hanterar acceleratorer bättre. Det bör dramatiskt minska risken att felet över huvud taget uppstår.

Om du använder svensk Vista, IE eller Media Player och hittar något översättningsfel, ser nåt som ser knas ut, eller bara har några frågor eller synpunkter på översättningsarbetet får du hemskt gärna kontakta mig. Stort eller litet spelar ingen roll - allt som kan leda till att vi levererar en bättre produkt är av intresse!

* se http://blogs.msdn.com/jesperh/archive/2007/01/09/vad-r-skillnaden-mellan-snabbtangenter-och-acceleratorer.aspx

Vad är skillnaden mellan snabbtangenter och acceleratorer?

jesperh — Wed, 10 Jan 2007 01:48:00 GMT

Snabbtangenter (kallas även "hotkeys") har till syfte att gör det lättare att navigera runt i användargränssnittet med tangentbordet. Detta är viktigt för användare som inte kan eller vill använda musen.

Snabbtangenter definieras i enskilda kontroller, och att trycka ner en snabbtangent är jämförbart med att ge fokus till eller klicka på den kontroll där snabbtangenten är definierad. Exakt vad som sker beror på vilken slags kontroll det rör sig om.

Snabbtangenter kan nås genom att man trycker ner Alt-tangenten följt av den tangent som motsvarar den kontroll man vill aktivera. Alt+A brukar öppna menyn Arkiv, för Arkiv har snabbtangenten A. Alt+N kan ta dig till nästa sida i en guide, för knappen Nästa har snabbtangenten N. Dock, om det fönster som har fokus inte har någon aktiverad och synlig kontroll med t.ex. Alt+A, då sker ingenting när man trycker ner den tangentkombinationen.

Snabbtangenter inkodas i kontrollernas text genom att utvecklaren eller lokaliseraren använder ett &-tecken före den bokstav som ska fungera som snabbtangent. Menyalternativet "Arkiv" har alltså texten "&Arkiv" och knappen "Verkställ" har texten "&Verkställ". Snabbtangenter för ett givet alternativ brukar skilja sig markant mellan olika språkversioner, eftersom det inte finns någon garanti för att min översättning ens innehåller samma bokstav som används som snabbtangent i källtexten. "&Verkställ" är på engelska "&Apply", "&Arkiv" är "&File".

Som standard visas inte vilken snabbtangent som har definierats för olika kontroller, för tydligen har forskning visat att användare blir förvirrade när de ser att vissa bokstäver är understrukna. Den som vill kan dock ändra en inställning i Windows så att snabbtangenten alltid visas - Michael Kaplan förklarar hur på http://blogs.msdn.com/michkap/archive/2006/09/28/774885.aspx.

Acceleratorer å andra sidan har till syfte att låta användare direkt nå vanliga eller viktiga funktioner utan att alls behöva navigera runt i användargränssnittet.

Acceleratorer brukar inte vara direkt bundna till enskilda kontroller och de definieras i Win32-filer genom en acceleratortabell som är helt separat från användargränssnittet. Acceleratorer brukar nås genom att man trycker ner någon F-tangent eller en kombination av Ctrl och någon eller några andra tangenter.

Acceleratorer är inte direkt bundna till en viss översättning så de har inte samma behov av att skilja sig mellan olika språkversioner. Ctrl+O brukar betyda "Öppna" oavsett språkversion. Vissa undantag finns dock. Ett svenskspecifikt exempel är att man för länge sedan beslutade sig för att "översätta" Ctrl+B (bold) till Ctrl+F (fet) och Ctrl+I (italic) till Ctrl+K (kursiv). Personligen tycker jag att det var ett misstag, men nu är det som det är...

Acceleratorer är inte direkt bundna till några kontroller, men givetvis är det käckt om det finns någon text som låter användaren upptäcka vilka acceleratorer som är tillgängliga. Det är därför vanligt att någon annan kontroll - t.ex. ett alternativ i en meny - visar vilken accelerator som kan användas för ett visst kommando. I menyer görs detta genom att menyns text och acceleratorn avgränsas med en tabb. Menykommandot kan givetvis även ha en snabbtangent, så det här är en vanlig syn: "&Öppna...\tCtrl+O" (\t betyder tabb)

Användning

De vanligaste funktionerna kan oftast nås på flera sätt. I Anteckningar kan man öppna en fil genom att:
1) Klicka på menyn Arkiv och sedan på alternativet Öppna
2) Trycka ner snabbtangenten Alt+A för att öppna &Arkiv-menyn och sedan trycka ner Ö för att välja alternativet &Öppna
3) Trycka ner acceleratorn Ctrl+O

Detta är bara en kortfattad förklaring av normalfallen. Mycket kan skilja sig i specialfall - man kan t.ex. använda en accelerator så att användaren uppfattar den som en snabbtangent; Winforms-program implementerar acceleratorer annorlunda än Win32-program; jag vill inte ens tänka på HTML... Syftet här är bara att ge bakgrund inför nästa bloggpost.

Bug Bar Limbo

jesperh — Wed, 25 Oct 2006 20:08:00 GMT

Checkin Limbo

I just read Larry Osterman's post where he describes Last Checkin Chicken (http://blogs.msdn.com/larryosterman/archive/2006/10/25/last-checkin-chicken.aspx). Here in the localization team we have sorta the opposite. I like to call it "Bug Bar Limbo".

Dev teams usually have bug bars that are gradually raised during the product cycle, so the closer you are to release, the higher the bar is for deciding which fixes to take. Towards the end, only really bad bugs are accepted. No fit and finish work. In my team, things are different.

In the localization team, we're free to check in almost anything we want until the day we hit the magic "showstopper mode". Even though we're really close to shipping Vista right now, Swedish Vista isn't in showstopper mode, so I can still change pretty much whatever I feel like: move a button two pixels to the left to prettify a dialog slightly; fix a spelling mistake in an event log message; correct a preposition here, change word order there... anything goes. No approval or justification needed.

But, soon we'll be in showstopper mode, and then any change I make must meet The Bar. If an issue does not meet The Bar, it is not considered a Showstopper Issue, and so I can not check in a fix. It's at this point people start playing Bug Bar Limbo.

The idea behind Bug Bar Limbo is simple: If you can't get over the bar, you can always try sneak under it. Any tactic is valid: exaggerate the importance of an issue to try and make it seem like it meets the bar, maybe by claiming that the users in the market in question will be confused or even offended; justify the change with "well, my language has had so few showstoppers, so cut us some slack"; compare with other dubious bugs that were already accepted, maybe even in a different language or even a previous product cycle; piggy-back on other approved fixes in the same binary; check if the bug is repro in more languages, and if so start recruiting supporters for your cause...

At times it can appear funny how hard some folks will fight for what's altogether fairly trivial issues. Objectively, it probably doesn't matter if we reject many of the changes - the overall quality of the product isn't improved in any noticeable way. At the same time, it's amazing to see how passionate people are for their language and their Windows. I guess that's part of why people rarely leave this team.

När kommer Internet Explorer 7 på svenska, och varför kommer finsk IE7 före svensk?

jesperh — Mon, 23 Oct 2006 21:48:00 GMT

Över helgen kontaktade Lars Olofsson mig. Lars hade bloggat om IE7 på http://www.larsolofsson.se/index.php?title=20061021&more=1&c=1&tb=1&pb=1 och i en av kommentarerna ställdes följande fråga:

Den svenska versionen kommer i december och den finska redan i november, varför är det på detta viset, tro? Hur prioriterar Microsoft eller är det bara tillfälligheter?

Lars skickade frågan till mig; svaret kan du se på http://www.larsolofsson.se/index.php?title=20061023&more=1&c=1&tb=1&pb=1. Kanske finns det fler som undrar över detta, så jag repeterar i stort sett samma innehåll här - frågor och kommentarer är välkomna.

Jag är inte 100 % säker på exakt vilket datum svensk IE blir tillgänglig, men det kommer att ske ganska snart. Vi är i praktiken klara att skeppa nu, men det kommer att ta i alla fall några veckor till. Internt har vi hanterat IE7 som ett delprojekt i Vista (det är samma med t.ex. WMP10, Windows Defender och en del annat), och det följer i stort sett samma schema mot release. Vi kommer att släppa språken i vågor om c:a 5-6 styck i taget, och den första vågen med bl.a. tyska, japanska, spanska och franska är redan helt nedlåst. Testarna jobbar nästan dygnet runt för att säkerställa att det inte finns några allvarliga buggar i de språken; vi på lokaliseringsavdelningen fixar buggar i stort sett i realtid.

Svenska ingår i den fjärden vågen, så vi har några veckor kvar att finputsa produkten innan vi skeppar. Och finputsar är precis vad vi gör nu: klickar igenom precis varenda dialogruta igen, korrläser allt vi kan igen, kontrollerar att all terminologi är konsekvent igen, småfilar på formuleringar där man hittar nåt som kunde se lite bättre ut. Just nu hjälper även folk på Microsoft-kontor över hela världen till med att testa och ge förslag på förbättringar, och vi har fått förslag och buggar genom betatestare ända sen Beta 2. ...förhoppningsvis Det skulle vara kul om man kunde undvika en klantighet som Ctrl+Enter-buggen igen...

Vad gäller Vista ligger svenska, danska, norska och finska i samma våg, men det skulle inte förvåna mig om finsk IE släpps innan de andra språken. Varför? Tja, det råkar vara så att han som har koordinerat all lokalisering och testning av IE heter "Mikko" i förnamn.

Svaret på frågan "är det bara tillfälligheter" är "nej"; samtidigt som Mikko arbetade med att koordinera alla internationella versioner, lokaliserade han den finska versionen. Detta gjorde att han kunde upptäcka och lösa många problem tidigt, så arbetet blev mycket smidigare för oss andra. Så här gör vi ofta; väljer ett eller några språk som pilotspråk för att hitta problem. Finska är ett bra språk att välja, för deras översättningar tenderar att vara ganska långa - det är inte ovanligt att stränglängdsproblem leder till t.ex. avklippt text eller t.o.m. krascher. Mikko är dessutom en alldeles utmärkt projektledare, hans arbete har hjälpt till att höja kvaliteten i alla internationella versioner.

Mikko låg alltså alltid steget före alla andra språk och finska blev därmed "klart" snabbare än svenska. Om min danska kollega hade varit projektledare för IE, kanske danska hade kommit ut först.

Förresten, om du vill se min danska kollega förklara hur lokalisering sköts här, finns det en video på http://download.microsoft.com/download/d/c/a/dca518be-abaa-4309-8663-6727092fbd60/Localization_globalization_team_final.wmv .

[Edit: messing with tags & title]

How we Windows used to be tested

jesperh — Thu, 10 Aug 2006 03:40:00 GMT

This is part One of A Few where I discuss how we used to ensure quality in the software we localize and how we do it today.

It used to be that most European Windows versions were localized, built and tested in Dublin, Ireland. During Windows 2000, functional and cosmetic testing started early for all twenty-odd languages. We were typically working on a two-week cycle, which went roughly like so:

The build team in Redmond would produce a new English build of Windows.
The localization team in Redmond would prepare a localization kit based on the latest bits This would take about a day.
A Technical Specialist (this role doesn't exist in my team anymore) in the localization team in Dublin would copy the localization kit prepared by our colleagues in Redmond. He would then analyze the differences since the last loc kit and prepare instructions so that the individual language teams can update. These instructions included a list of files that have been added, removed, moved or renamed in the project. This would take about a day.
The language teams would update their localization databases based on the latest loc kit. This involves adding/moving/removing/renaming files, as well as bringing in the latest changes from all files into the databases. This would take about a half day. They would then start localizing the changes.
The tech specs now turn their attention to making sure that the script used to check in translations to the build team still works for the latest loc kit.
During the next two weeks, the language teams would check in their translations to hand them to the build team. This would happen in a staggered fashion. Typically French and Spanish would check in just a day or two after the loc kit was available; the next day Italian and Portuguese would check in; followed by Dutch and Swedish a day later and so on. From this follows that the larger languages would get builds first, but the smaller languages would have more time to catch up with any changes and therefore probably get better quality builds.
As the languages checked in, the build team would take the latest files, merge the translations with the English binaries, thus producing a localized, installable product.
The test team would take the latest build and start hacking away until a new build was available. There was a database full of test cases, and all of those test cases were carried out manually. Some of the members of the test team were working directly for Microsoft and sitting in the same building as localization and build, but most of the work was done by a partner company in Greece. The Ireland test team was mostly involved in coordinating the testing.
Two weeks later when a new build was available, the test team would pick that up and continue testing.

There were several problems with this approach. Some examples are:

Manual testing is tedious, slow and inefficient.
Since manual testing is slow testing had to start very early - way before Beta 3. Only the product was still evolving dramatically, which means that all test cases had to be redone.
We were very poor at tracking of what really changed between builds and whether those changes were due to catching up with changes in the English product, or if the changes were for language-specific reasons. Because of this, it was hard to gauge exactly what had been covered and what should be redone.
Since testing had to start early, areas were tested before the language teams were "done". I'm guessing that at least half of the bugs filed could have been caught and fixed by the localization team even before checking in. We were so focused on getting all the text translated that we put off the easy quality work (sizing, static hotkeys etc), and this probably hurt the test team.
Most languages didn't have natives testing the product, so language testing was very poorly covered. We tried to counter this by early self hosting and some collaboration with the in-house language specialists, but far more could have been done in this area.
The test team was always working on old builds. When they'd get around to test, say, Czech, the English build could be two weeks newer than the Czech build. Testing old builds meant that they'd see code bugs that had already been fixed and features that may have changed. Result: bogus bugs and wasted time.

Those were the days...

This posting is provided "AS IS" with no warranties, and confers no rights.

Take a look inside the Windows Localization team...

jesperh — Fri, 04 Aug 2006 00:05:00 GMT

Claus Juhl, my Danish colleague, worked with a bunch of people inside and outside of our team to bring you a Channel 9 video that explains a bit of what we do here in the Windows localization team. Check it out at http://channel9.msdn.com/Showpost.aspx?postid=222513.

Localizability: Unnecessary dynamic behaviour

jesperh — Tue, 25 Jul 2006 18:55:00 GMT

The evidence is overwhelming: if your localizers do not have enough context when they localize, odds are that they will not get it right. Lack of context leads to unnecessary bugs and lower quality overall, both of which can be very costly.

One way for developers to help localization is to avoid UI changes at runtime whenever possible. That is, don't use the same dialog for more than one purpose, don't swap text in and out if you can avoid it, and make sure to keep controls static if there's no need for dynamic behaviour.

Here's an example of what not to do. I have a dialog in Vista that in my favourite localiztion tool looks like this:

I can guess that all text will be taken from the string table at runtime, but I have no way of knowing what piece of text will go in which controls, which means that I don't know what it will look like at runtime and our checks will not be able to find duplicate hotkeys, clippings etc.

Today, I received a bug with this screen shot:

Great, finally I know what it may actually look like at runtime, so I can size the dialog correctly. Only, I still don't know for sure that this is the only possible state of this dialog box so I can't be ceratin if I fix it right, I still can't use our checks to detect clippings or hotkeys, and if the developer ever changes the dialog, it's more than likely that I re-introduce the same or similar problems again. How many man hours did this cost? Any for how many languages does this need to be tested, fixed and regressed?

Localizability: Cluttered dialog boxes

jesperh — Fri, 07 Apr 2006 21:47:00 GMT

In Windows, there are thousands of dialog boxes where the controls do not resize automatically. Us localizers therefore spend quite a bit of time adjusting layout and sizing of controls so that the dialog box still looks neat after the text has been translated.

Sometimes I come across dialog boxes that are built to cover multiple application states. It's often pretty straight forward - maybe a property page that contains the normal controls, but that are alos overlaid by a label explaining "These settings are controlled by a group policy and may not be changed" (or similar). Even though this label may be smack bang on top of some other controls, it's still easy enough for me to imagine what may happen at runtime and resize correctly.

However, sometimes we get stuck with things like this (screen shot taken straight from my loc tool):

There are roughly a hundred controls in this dialog box. I have no idea which ones might actually be shown together at at runtime, so there's now way I can adjust sizing and layout correctly, or assign hotkeys smartly for that matter. I bet that this will be clipped pretty bad in quite a few languages. I bet that we'll spend way too much time finding and fixing bugs in this dialog box.

If you're a developer, please try not to do things like this to me - or to yourself, for that matter. How much work will it be for you to add another option?

This posting is provided "AS IS" with no warranties, and confers no rights.

Questionable Character

jesperh — Tue, 07 Mar 2006 22:52:00 GMT

In Vista, we're doing put a huge emphasis on gauging and improving the functional, cosmetic and linguistic quality in the localized versions. We're using several different strategies to find & fix old mistakes and prevent new ones.

Right now, I'm playing around with extracting strings that contained unexpected characters. The idea goes something like this: if we know which characters are expected for a language (e.g. a-z for Dutch; a-zåäö for Swedish, as well as numbers and symbols), then we can scan all translations to find those that contain any character that is not in the expected list or in the source text (this is to lower the number of false positives). We then log those strings and browse through them to see what the story is.

It's a simple idea, and as such it suffers from several flaws. For one, there's no built-in way in Windows to see whether a letter belongs to a certain language (for good reason), nor can you assume that the translation of a certain string should actually match the source text (localizing software is hard).

Still, I just tried out this simple idea on Russian based on the most commonly used letters, and I did get decent result. Many false positives were logged (gots to tweak the code a little), but there were a few really nice ones were caught too. One example is a resource that's used when dumping your netsh configuration to a script:

English text: # End of Remote Access NBF configuration.
Translation: # Конец конфигурации удаленного доступа AppleTalk

Hm, I wonder what caused this. Maybe fuzzy recycling, maybe manual copy/pasting, maybe something else...?

This is just one simple technique we're toying with, and something we'll probably only use for a few languages. I bet it's pointless to try and run this on Swedish, since the Swedish and English alphabet are so similar, and I bet it'll be very hard to come up with a list of expected characters for some Asian languages. Still, I'll give it a go on Greek and Turkish next, just to see what'll pop out...

This posting is provided "AS IS" with no warranties, and confers no rights.

Localizing accelerators

jesperh — Sat, 25 Feb 2006 03:57:00 GMT

As per old, well established conventions, several languages localized certain accelerators. The most common ones are Ctrl+I, Ctrl+B and Ctrl+U. If an application uses these for Italic, Bold or Underline, the accelerator may be switched during localization.

In Swedish, the word "bold" is "fet", "italic" is "kursiv" and "underline" is "understruken", so in Swedish Word the accelerators Ctrl+I and Ctrl+K are switched, as are Ctrl+B and Ctrl+F. The same is true in e.g. Norwegian and Danish. Whether this is good or bad, well, I guess that it doesn't really matter much now. This is how it is, and it's even prescribed in my copy of the GUI Guide from '93. (I must say that it bugs me though, 'cause I often switch between English and Swedish office, and so I always end up making text Bold when I want to Find)

Only thing is, this causes bugs. Subtle bugs, but bugs nonetheless. One example was reported to me by Pelle at www.pellesoft.se over a year ago, and can be illustrated by this HTML markup:


<html>
 <head />
 <body>
 <div contenteditable style="height:100px;width:500px;border:solid 1px black"></div>
 </body>
</html>

If you save this as an html page and browse it, you see an editable text field. In it you can use Ctrl+I, Ctrl+B and Ctrl+U to format the text, just as one would expect. The control has a lot of interesting features, for instance you can press Ctrl+K to insert a hyperlink. Go on, try it.

The problem is though, that if you have Swedish IE, Ctrl+K does not bring up the Hyperlink dialog. Instead it makes text italic. Ctrl+I in turn does not bring up the dialog either; that one shows/hides the Favorites pane. Funnily, even though Swedish, Danish and Norwegian should do the same mapping, on Norwegian and Danish IE, Ctrl+K does bring up the dialog, whereas there's no key combination that makes text italic.

The same issue gives symptoms in Outlook too. When you author a mail in Outlook, you can enter someone's e-mail alias in the To line and press Ctrl+K to try and resolve the alias to a user in the address book. In Swedish Outlook, this does not work if input focus is in the e-mail's text area, because there Ctrl+K gives you italic text. However, if input focus is on any of the other text fields, Ctrl+K does resolve the address. Ctrl+I however, doesn't do much.

Norwegian Outlook is even funnier. There, how Ctrl+K works depends on whether the mail message is in HTML format or Rich Text format. Sometimes it brings up the Hyperlink dialog, sometimes it makes text italic. Danish Outlook

I'm not sure what's going on here. Maybe the inconsistencies between Swedish, Norwegian and Danish is because Outlook and IE use the same control for editable HTML content and Outlook uses different controls for editing Rich Text and HTML, and we just happen to have some differences in localization. I really don't know. Right now I'm trying to track down where the accelerators used in the editable HTML control are actually defined, and then I'll see what I can do in Swedish IE7 to make it possible for the user to bring up the Hyperlink control through an accelerator.

It's these rather subtle bugs that make the job interesting, and it's enormously gratifying that for every new Windows version, I am able to change pretty much any part of the localization that I'm unhappy with in the previous versions of Swedish Windows - terminology, translations, cosmetic issues, functional bugs, anything...

This posting is provided "AS IS" with no warranties, and confers no rights.

Why does wprintf fail when my app is localized to non-Latin languages?

jesperh — Tue, 25 Oct 2005 19:22:00 GMT

If you have a command line application that works just swell with Latin languages, but where wprintf (or any other Unicode stream I/O call) fails to output any localized text after the application has been translated to e.g. Japanese, Russian or Bengali, odds are that you forgot to call setlocale.

Developing International Software, 2nd ed. explains the Unicode I/O functions quite well, and says on page 87:
"[...] if setlocale was not called [...] only Latin script is processed and the localized text is not displayed at all."

This is a good book. You really ought to get it.

printf-style place holders, #2

jesperh — Fri, 10 Jun 2005 00:25:00 GMT

It's been a while, but in the last post, I showed what a printf format specifier is, how the localizer can spot it and what can happen if it gets messed up during localization. Today, I'll talk about more about what the effect can be if they change during localization and how developers can help ensuring it doesn't happen.

What actually happens if you change a print format specifier while localizing depends on exactly what the change is. Last time, I showed that it can cause an application to crash. Pretty bad, but that's not always the effect.

Take a look at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_format_specification_fields_.2d_.printf_and_wprintf_functions.asp. This page lists all the data types that printf supports. You can divide them into four groups - int, double, pointer and string. If you'd accidentally substitute one type of int specifier for another, the effect isn't dramatic - the only difference is how the value is displayed. Imagine for instance this piece of code:
char message[50] = "Please enter a value between %d and %d."; printf(message, 100, 400);

This would print out the following to the console:
Please enter a value between 100 and 400.

Now, imagine that the message is localized into the following, where the format specifiers are using a different data type:
char message[50] = "Please enter a value between %x and %x."; printf(message, 100, 400);

This would now print the following instead:
Please enter a value between 64 and 190.

As you can see, the message displayed to the user is misleading - the values are printed as hexadecimal numbers instead of decimal integers. Not great, but hey, at least the application didn't crash.

Of course, as we saw the last time, if you substitute across groups, you're a fair bit more likely to crash the application. This code for instance is bound to get the process to go belly-up:
char message[50] = "Please enter a value between %d and %p."; printf(message, 100, 400);

By now I think we can agree that mismatches are generally bad. It's very rare for intentional mismatches, although there are some cases where a placeholder might be dropped. German wizards, for instance, don't say "Welcome to the [wizard name] wizard", they simply say "Willkommen". And the Help menu in Dutch Windows would just say "Info" instead of "About [application name]". Apart from these rare exceptions, mismatches should just not occur. So how come I'm making a big deal about it, how come I even write this?

Well, turns out, unintentional mismatches aren't uncommon enough. There are several ways mistakes can appear during the localization process - maybe you're auto-translating from poor sources or you allow less than perfect matches when auto-translating. Maybe the localizer simply mistypes a placeholder. Maybe a translation memory application doesn't understand placeholders. Maybe the localizer isn't experienced enough to understand what the placeholder is. This is especially likely if the placeholder looks slightly unusual, such as in "%s's Documents".

Another very common cause is that the localizer switches the place holder order for linguistic reasons. Their need to do so may be genuine, but unfortunately it may lead to bad bugs. For instance, the string "Property (%s) has Value (%d), which is out of the legal range for this property." might become "La valeur (%d) de la propriété (%s) est en dehors des valeurs possibles pour cette propriété." in French. Language-wise it might be splendid. Functionality-wise, not as great.

So, if you're authoring strings that will need to be localized, please keep these risks in mind. You have the power to prevent a lot of issues, simply by making the string localization friendly from the start. The more placeholders you include in a sentence, the greater the risk that it'll break for some language. Consider how you can bullet proof the string from the start - maybe change the example above to "The property %s has an invalid value. Value: %d".

In my team, we typically treat any format specifier mismatch as a high severity bug. The cause and the potential effects are well understood, as are the risks of taking such a fix. During the localization process, we run checks that scan through all resources and compare the source and the translation to find any mismatched printf format specifiers. Any unintended mismatch will be fixed before release.

That's it for printf. Next time I'll step it up a bit with the FormatMessage function.

This posting is provided "AS IS" with no warranties, and confers no rights.

prtintf-style place holders, #1

jesperh — Wed, 27 Apr 2005 23:47:00 GMT

When localizing native code applications, it's not unusual to come across strings resembling this:

Couldn't find path "%s", error #%d.

This should be pretty straight forward. It's pretty obvious that there are two placeholders in this string: %s and %d. It's also quite clear what those placeholders will contain at runtime: a path and an error number.

The type of placeholders used tells us a lot. Just by looking at the string, we ought to know that the code is probably using printf (or similar), and therefore we know that we need to be very careful to get the format specifiers right.

Take a gander at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_format_specification_fields_.2d_.printf_and_wprintf_functions.asp. This page has an exhaustive explanation of what valid format specifiers look like. Did you notice that happy note at the bottom of the page? The one that says "Security Note - Ensure that format specification strings are not user-defined"? "User-defined" here also includes "localizer-tampered" - if the localizer makes a mistake, you have a problem.

For the string above, let's pretend* that the code is something like:

char path[10] = "c:\\temp"; char message[50] = "Couldn't find path \"%s\", error #%d."; printf(message, path, 132);

Here, printf would do something along these lines: it walks through the message string, from start to finish, substituting any format specification with the rest of the arguments supplied, and then printing out the result. The function will substitute %s for the string in path, and substitute %d for the value 132. Worth noting here is that the argument "path" isn't actually a string, but the address where the text to be printed can be found. The output from this could would be:

Couldn't find path "c:\temp", error #132.

Very good. Now, let's pretend that the localizer needs to switch the word order around a little bit, and we end up with the equivalent of:

char path[10] = "c:\\temp"; char message[50] = "Error #%d: couldn't find path \"%s\"."; printf(message, path, 132);

What happens here? Well, printf again walks through the string, trying to substitute the format specifiers for the specified arguments. It expects first to find a digit, then the address to a string. Only, because the translation is messed up, the arguments don't actually match the specifiers. The first placeholder - %d - means that the argument "path" is interpreted as a number. This kinda works since it actually is a number, but it means that instead of the text, the memory address of the text will be printed. The second placeholder on the other hand - %s - means that printf will interpret the third argument as the address of some text. The third argument here is 132. When this is interpreted as an address, Windows will notice that the application is trying to poke around in some part of the memory where it doesn't belong, and promptly shut down the process. Que Dr. Watson.

This should make a few things clear:

When localizing, you need to take care to use the same printf format specifiers in your translation as you see in the source, and in the same order too.
When bug-fixing localized software, if you see that a long number is printed instead of a string, a bad placeholder could very well be the cause.
When bug-fixing localized software, if you see that an application crashes or a dialog box just disappears, a bad placeholder could very well be the cause.
Before releasing a localized product, you really should triple-check that all format specifiers in localized strings match the specifiers in the source strings.

The good news is that it is fairly straight forward to avoid or catch these bugs. Assuming that the source text is correct, it should be easy to create a check that would compare each source-translation pair and make sure that the same format specifiers occur in the same order.

That's it for now, next time I'll talk just a little bit more about how to author & translate messages with printf format specifiers.

* My examples hard-code all strings for clarity. I reality, if the path and error number were known at compile time, there wouldn't be any reason not to include them in the message.

This posting is provided "AS IS" with no warranties, and confers no rights.