Hej, jag har en liten fundering. I den engelska XP med IE 6.x när man i alla fall kör en div-tagg med content editable = true så kan man trycka CTRL+K så kommer en ruta upp där man kan ange en URL. I den svenska versionen är det stört omöjligt att hitta motsvarande knappkombination.

Nån som vet vad den svenska motsvarigheten är?

Schysst! Det där är alla gånger en lokaliseringsbugg - och en som jag inte sett innan dessutom!

Kort förklaring --
Av nåt skäl beslutades det vid nåt bra tillfälle i världshistorien att acceleratorer för Bold, Italic och Underline skulle lokaliseras till de flesta språk. Vi gör därför ofta följande:

Ctrl+B -> Ctrl+F
Ctrl+I -> Ctrl+K
Ctrl+U -> Ctrl+U

Personligen tycker jag att detta är löjligt, för jag lyckas alltid få fetstil när jag ska söka i Word-dokument. Dessutom ger det upphov till "lustiga" buggar som den här.

Jag misstänker att någonstans i en fil som tillhör IE har acceleratorerna ändrats enligt ovan. Därför kan du få kursiv stil i DIV-taggarna genom att trycka ned Ctrl+K.

Om Ctrl+I ändras till Ctrl+K, skulle man tro att Ctrl+K skulle ändras till Ctrl+I -- så att man kunde trycka ned Ctrl+I för att infoga en hyperlink. Icke sa nicke, då får man visst Explorer-fältet Favoriter istället -- eftersom någon (annan?) stans i IE har ingen ändrat från Ctrl+I till någon annan fri bokstav. Mao, Ctrl+I är nog kopplat till två funktioner, och Favoriter "vinner".

Jag ska genast lägga in en bugg på detta, så jag borde kunna fixa det till Longhorn.

Tills vidare, kanske kan du göra nåt med skriptkod för att "stjäla" Ctrl+<nåt bra>? Skriptkoden för att visa själva dialogrutan är ganska enkel, frågan är bara hur du får koden att anropas.

[edit: terminologi]

Lösningen är inget problem - jag är ju utvecklare. Når man inte problemet tar man en annan väg. Jag har därför en egen knapp i min toolbar på CM-systemet här på pellesoft.

Jättebra att du rapporterade det här Pelle. Superstort tack!

Hej igen, någon feedback på detta? Jag behöver rutinen mer och mer nu faktiskt :-)

En liten kuriosa fråga...

Kan ni inte öppna för möjligheten till att i någon framtida version av windows få möjlighet att lokalisera lite själv? De "buggar" som stör mig mest är ofta rena lokaliseringsproblem, och jag har fått intrycket av att andra också tycker så.

Det skulle alltså vara intressant med den möjligheten, en opensource-modell på översättningen som är helt osupportad av microsoft till den grad att det fungerar men att ms inte har någon support på det.

Fördelen är att t.ex. ctrl+f, ctril+i, ctrl+enter != www.[text].sv etc. osv. fungerar "som det ska" och inte beter sig knasigt :)

Är mina funderingar rimliga?

Är det CTRL+L du söker, Pelle?

Hej Oskar,
Intressant fråga. Vi har diskuterat möjligheten att lokalisera vissa av våra produkter med hjälp av externa communities eller organisationer, men detta är ganska nytt så ännu är idén bara på diskussionsstadiet. Nyligen genomfördes dock ett pilotprojekt i Ungern där ett gäng Microsoft-entusiaster lokaliserade Windows XP PowerToys till ungerska. Länk till projektet: http://www.microsoft.com/globaldev/outreach/dnloads/ptls-hu.mspx Förutom att projektet var ett första test (för Windows-teamet i alla fall) av community-lokaliserings-modellen så var det även första gången som vi använde en ny lokaliseringsteknik där översättningen sker "on-the-fly", dvs. programmet installeras och körs som vanligt på engelska men visas ändå på det lokaliserade språket eftersom översättningen sker on-the-fly när gränssnittet ritas upp på skärmen. Intressant teknik för framtiden.

Microsoft samarbetar även med externa myndigheter och organisationer i flera länder vid lokalisering av så kallade LIP-versioner (Language Interface Packs) av Windows och Office. Ett LIP påminner om MUI-versioner men täcker inte lika stor del av produkten (kort uttryckt: genom att lokalisera 20% av strängarna i Windows kan man få en version som är 80% översatt). Genom att erbjuda ett paket med översättningsfiler och -verktyg till myndigheter och organisationer så kan dessa själva skapa översatta versioner av Office och Windows på språk som inte är ekonomiskt lönsamt för Microsoft att lokalisera till.

Vad beträffar lokaliseringsbuggar som exempelvis ctrl+enter-buggen i den svenska versionen av Windows XP så hoppas vi att inga sådana buggar ska slinka igenom i nästa Windows-version genom att dels testa mer lokalt i Sverige med svenska testare (tidigare har en stor del av testningen gjorts i Irland), dels testa med nya testverktyg, dels betatesta mer och dels genom att hela nästa Windows-version bygger på MUI-teknik och kommer att vara betydligt mer språkoberoende.

Microsoft i Sverige håller även på att starta upp en liten lokaliserings-community som vi kommer att samarbeta med för att få in feedback, betatesta lokaliserade Microsoft-produkter, diskutera terminologi osv. Genom denna community hoppas även kunna ge bättre service till de som översätter hjäpfiler och dokumentation till produkterna.

Vänliga hälsningar
Magnus

Det där såg väldigt intressant ut faktiskt :)

Hur fungerar nuvarande "översättningsmodell" egentligen? Ligger alla strängar som översätts i egna .h/.c-filer?

Om det där såg intressant ut, skulle du bara veta vad vi vill göra strax efter Longhorn...

Ang. hur lokaliseringsprocessen fungerar nu, är det ok om jag skriver ett svar på engelska och lägger det på http://blogs.msdn.com/jesperh? Jag tror att det är fler som kan vara intresserade av hur det går till, och iomed att det inte är en svenskspecifik fråga kan det vara käckt att lägga det på den bloggen.

Jag har börjat skriva svaret redan. Jag tänker skriva lite allmänt om hur hela lokaliseringsprocessen går till - från ax till limpa. Är det något mer du vill veta om än bara filformat? Isf, hojta till så ska jag försöka inkludera det med.

Mvh,
Jesper Holmberg
http://blogs.msdn.com/jesperh

Detta inlägg publiceras i befintligt skick och innebär inga garantier eller rättigheter i övrigt.

Tjena, det här är intressant! :)

Jodå, det är mycket som är intressant när det gäller det här med lokalisering.

T.ex. filformat, olika tekniker som används, prestanda, problem med olika tekniker, hur lokaliseringen går till för t.ex. en översättare, hur man undviker att t.ex. engelska ordet no:s två betydelser bara får en sträng, etc. etc.

Allt är av intresse :)

/Mvh
Oskar Johansson

Sedär - jag har skrivit något på http://blogs.msdn.com/jesperh/archive/2005/04/15/408670.aspx nu. Det täcker inte alla dina frågor, men det är en början i alla fall.

Lessen att det tog en stund innan det kom upp. Inte för att innehållet är särskilt känsligt, men jag tyckte det var bäst att låta ett par kollegor ta en titt innan jag publicerade svaret.

Jag ska försöka prata mer om det andra du nämner. Ytterligare förslag på ämnen mottages tacksamt!

Klart intressant :)

En liten följfråga bara: hur hanterar ni det här med unicode (och övergången till unicode)?

Det du föreslår är väldigt intressant, och det är något som har diskuteras internt. Ofta. Och med starka känslor.

Det finns många oomkullrunkeliga skäl för att göra det du föreslår. Windows har iomed XP SP2/Server 2003 SP1 t.ex. stöd för samiska språk, så varför skulle vi inte tillåta att de som kan lokaliserar, bygger och skeppar samiska versioner? Vi samarbetar med olika regionala myndigheter för att nå nya språk (t.ex. kymriskt LIP), så varför låter vi inte vem som helst lokalisera, bygga och skeppa en egen version? Vi säljer en svensk version av Windows, så varför inte låta folk anpassa den till en göteborgsk version?

Argumenten för att tillåta detta är starka - fördelar för både användare och Microsoft är uppenbara. Vi skulle kunna nå nya marknader relativt kostnadseffektivt; vi kan få goodwill & bygga community... Användare med andra språkbakgrunder än det tjugotal språk vi idag släpper som fullständigt lokaliserade versioner kan få Windows på sina språk.

Tyvärr är dock argumenten emot att göra detta än starkare...

Problemet ligger i trovärdighet. Eller supportability. Eller Trustworthy Computing. Eller vad du nu vill kalla det.

Faktum är att det är ofantligt lätt att bryta programvara när du lokaliserar. Windows är idag hyfsat tåligt jämfört med andra program, men det är ändå relativt görlätt att introducera funktionella buggar. Om du i en sträng byter ut platshållaren %d till %s, kommer programmet med största sannolikhet att krascha när strängen sen ska visas*. Om strängen i fråga finns i Explorer.exe och, säg, visas under inloggningen, har du en ganska effektiv DOS-attack...

Det finns andra saker som kan ge än värre problem. Sökassistenten består av XML-filer. Hjälp- och supportcenter är HTML-filer. IPP är HTML; OOBE är HTML, många DLL-filer har inbäddade HTML-filer. Alla dessa kan innehålla kod, kod som kan köras på din dator. Kod som kan ersättas av en lokaliserare. Säkerhetsriskerna borde nu vara uppenbara...

...och tänk om någon skulle skapa en lokaliserad version där hälften av strängarna är översatta till "Jeppe är bög" (bara som exempel). Vem har ansvar? Vems rykte svärtas ner?

...och även om vi inte pratar om medvetet sabotage finns det risker. Om en översättning blir lite för lång eller inte råkar matcha någon annan sträng, kanske en funktionell bugg uppstår. Eller kanske en kosmetisk bugg orsakas. Vem har supportansvar? Idag, om du kör Windows, är det solklart vem som äger ansvar för support - Microsoft! Det finns ingen tvekan! Men om det fanns tolv olika varianter av svensk Windows, hur vet du som användare vem du ska vända dig till, vems skuld det är att Kungen kraschar? Och om ett hemmalokaliseringsteam släpper en förbättrad svensk Windows XP som bygger på SP2, och om vi skulle släppa SP3 med femtiotusen nya ord i nya funktioner, vad gör du som användare?

Så - en stor utmaning är att tillåta fri lokalisering utan att introducera säkerhetsrisker och förvirra slutanvändare. Detta kommer inte att lösas på Windows XP.

Ett sätt att möta detta skulle kunna vara att Microsoft bygger och testar allt som släpps. Mao, du kan lokalisera, men du kan inte bygga eller släppa det du bygger. Fast i så fall blir frågan, kan vi verkligen testa allt som måste testas? Kan vi garantera att inget skräp slinker igenom? Vi talar inte alla språk på jorden, och vi kan inte korrläsa alla översättningar. Och om något skulle slinka igenom, vilket juridiskt ansvar har vi?

Och hur mycket skulle det kosta för Microsoft att bygga och testa alla möjliga fria språkvarianter? Det är en sak att vi arbetar tillsammans med myndigheter i ett gäng länder för att släppa LIPs, en helt annan sak att försöka stödja alla möjliga initiativ... Personligen lägger jag hellre de resurserna på att få ut Media Center och Longhorn.

Men som sagt. Detta är något vi diskuterar, och ofta. Personligen vill jag absolut se att du har möjlighet att skapa en egen lokaliserad Windows-version - även om du grundtemat är "B!|| $u>< - |00ni>< r0><0r". Eller kanske just precis för att du får möjlighet att göra så. Jag hoppas och tror att vi har chans att göra detta strax efter Longhorn.

Men den som lever får se...

Förresten, önskan att rätta till lokaliseringsproblem kan jag känna sympati för. Men jag hoppas att Pellesoft och ökad betatestning i Sverige kan funka än bättre. Om du gör en egen version där du rättar till X buggar, hur får du sprdning? Vore det inte bättre att jag rättade till i själva källtexten? Mao, om du ser något - precis vad som helst - som är kass i den svenska Windows-versionen, hojta till! Jag gör allt jag kan för att rätta till det så snabbt jag bara kan. Vilket antagligen innebär Longhorn...

Förresten, Ctrl+Returär fixat. I 64-bitars Windows XP och Server 2003. Det är bara att uppgradera :) Eller följa tipset på http://blogs.msdn.com/jeffdav/archive/2004/09/09/227502.aspx.


*%d är ett decimalt värde. %s tolkas som adressen till en sträng. Om strängen har %s där det borde vara %d, försöker programmet läsa in en sträng från den adress som anges i den efterföljande variabeln, och detta värde är med största sannolikhet utanför processens minnesområde. Detta leder till en krasch, eftersom program i NT och nyare inte får rota utanför sina egna minnesområden.

Jo, jag förstår dilemmat (och jag har varit inne på samma tankebanor förut när jag tänkte på det; vem har supporten?)

Skulle följande kunna fungera: en helt osupportad version av windows (eller nästan, det finns alltså inte så mycket mer än självhjälp/communities att använda för att lösa problemen) som är enkel att lokalisera och ändra bäst man vill i när det gäller texter.

När det gäller en sådan version är ju fördelen att man kan t.ex. skräddarsy vissa instruktionstexter, byta ut vissa termer som stör, göra stöd för konstiga språk etc. etc.

Fördelen med detta är ju att vissa användare inte bryr sig ifall mer än just det viktigaste är översatt, vad som står på bluescreen, hjälptexter, vissa dialoger, annat som en normalanvändare inte behöver så ofta etc. etc. kan nog ofta vara på engelska. Och just den här biten med det viktigaste kanske kan få vara helt osupportat och delvis översatt istället för helt oöversatt för många.

Den intressantaste frågan också: Hur gör man när man vill testa rubbet, är det virtuell pc som behövs alt. extra fysisk pc? Och om så fallet: finns det smidiga verktyg för att hålla saker uppdaterat?

Och visst, det är intressant att rätta lokaliseringsproblem i de vanliga versionerna, tänkte dock mer på "akuta" problem så man slipper vänta ;)

Tackar och bockar för informationen :)

Varför fungerar inte "communitybaserad översättning" för Windows, när det fungerar väl för fri/libre mjukvara/open source (FLOSS)? Har Windows-applikationer sämre säkerhet än FLOSS-applikationer? Är Windows-användare mindre pålitliga än FLOSS-användare?

Community-baserad översättning fungerar säkert utmärkt för Windows med, men Microsoft har än så länge använt sig av en annan lokaliseringsmodell med interna översättare och vendor-företag.

Om Windows-applikationer har sämre säkerhet än FLOSS-applikationer är inte jag rätt person att svara på. Jag arbetar med lokalisering och detta är ett forum för diskussion av Windows-lokalisering, inte säkerhet.

Vänliga hälsningar
Magnus

<b>detta är ett forum för diskussion av Windows-lokalisering, inte säkerhet.</b>

Jag vet, men jag syftade på det Jesper skrev:

<b>Så - en stor utmaning är att tillåta fri lokalisering utan att introducera säkerhetsrisker och förvirra slutanvändare. Detta kommer inte att lösas på Windows XP. </b>