Ska sätta upp en liten sajt som ska ha möjlighet att utökas till flera språk och tänker bygga rätt från början.
Texterna för sidorna kommer att administreras via en adminsida där respektive land översätter de engelska texterna till lokalt språk.

Vad är att föredra för att slippa problem med "konstiga" tecken som finns i tex polska, slovenska, kinesiska etc?
Dels vad det gäller inställningar för MySQL men också det som skickas från formuläret (accept-charset?), om textsträngarna som ska sparas ned bör encodas på något sätt samt vad som är att föredra då sidorna ska visas, för att hantera så många språkvarianter som möjligt.

Någon som har några bra regler att tänka på eller någon länk till en guide?
Tack på förhand!

Detta (utf8/teckenhantering) står det rätt bra om i boken "building scalable websites" (ISBN 0596102356). Sen så skulle jag väl rekommendera att om du nu skall göra "rätt" så använder du gettext (http://www.gnu.org/software/gettext/) istället för ett eget system.

Om du använder Unicode i form av utf-8 så kommer du inte ha problem med några språk (kinesiska, ryska, arabiska, polska - inget problem). Se till att ha MySQL att lagra text som utf8, hämta och lagra text som utf8 och se också till att ha alla dina websidor encodade som utf-8. Det är i sig inget besvärligt att använda utf-8 genomgående (även om en del verkar vara lite oroade över detta nya).
för att skapa en utf8 databas, välj utf8 för överföring innan du hämtar eller sparar dataFramförallt ska du se till att använda MySQL 5, tidigare versioner än 4.1 har inget som helst stöd för utf8… Naturligtvis är bästa platsen att lära sig mer MySQLs hemsida och dokumentationen där:
http://www.mysql.se/doc/refman/5.0/en/charset.html

accept-charset har ingen praktisk betydelse, encodingen på sidan avgör:
form skickar då tillbaks input med samma encoding (utf-8) som sidan är.

Se också till att det serversidespråk som du använder hanterar utf-8 riktigt. Exempelvis med mb_string i php (sätt internal encoding utf-8). Om du tänker använda php så kolla:
http://de3.php.net/manual/en/ref.mbstring.php
(och se till att din server/ditt webbhotel har mb_string installerat)

Det enda som gettext kan välja dynamiskt är pluralform. Hur gör man för att bry sig om kön och ålder? Misstänker att en hälsningsfras på t.ex. Japanska inte så enkel som på Svenska ("Hej <förnamn> <efternamn>")... Finns det mer argument man behöver bry sig för för att kunna översätta en fras till alla jordens språk?

kullervo, jag tror det mesta sånt går, men inte i phps implementation av gettext. gettext är bra mycket mera avancerat på systemnivå än vad php har valt att implementera. martine's inlägg var också mycket bra, det sammanfattar bokens innehåll om det hela rätt bra. MySQL5 och rätt collations samt även tänka på att inte använda varchar som fälttyper. En fallgrop är som jag har förstått det att vissa browsers skiter i att skicka form-content som utf-8 även om man har specat det, så man måste hålla ett litet öga öppet för det.

Varför ska man inte använda varchar, och vad ska man använda istället då?

Boken säger såhär (jag är tyvärr ingen överdriven hejare på detta själv):
"UTF-8 can be binary sorted and comes out in code point order. This means that the regular MySQL sort works fine with your UTF-8 data, as long as you define your columns with the BINARY attribute (for CHAR and VARCHAR columns) and use BLOB instead of TEXT types."

Det är ju en klassiker annars att utf-8 data inte sorterar nåt vidare.. men om om man kör med mb_*, mysql5 och ovanstående tips så skall det tydligen lösa sig. Jag är än så länge en av dem som martine säger "inte riktigt vågar ta steget fullt ut till utf-8".. men det kommer väl :P

För att svara på din fråga: du kan använda VARCHAR, men med attributet BINARY. Det är TEXT som skall vara BLOB (där jag rörde ihop det för mig).

Aha, tack för svaret. Har undrat ibland när man ska använda binary på varchar fält men inte orkat kolla upp det.

Skulle väl potentiellt kunna vara ett problem, men jag använder genomgående utf-8 och har aldrig haft problem med detta. Så länge man har html-sidan i utf-8 och en riktig meta-tagg (se ovan) så fungerar det utmärkt i Explorer, Netscape, Firefox, Opera, mm. En fallgrop kan eventuellt vara Netscape 4 och Explorer 4 och tidigare, där är stödet för unicode var minimalt. Möjligtvis kan problem också uppstå om användaren avsiktligt ändrar text-encoding i menyn på sidan med formuläret efter att sidan har laddats (men det finns ju ingen rimlig anledning varför någon skulle göra detta, det syns ju då uppenbart att tecknen på sidan blir fel).

Blanda inte iso och utf-8 på en site och ha alltid metatagg som anger utf-8.

MySQL kan ju även spara "äkta" unicode (ucs2) vilket dels löser problemet med 1 till 3 bytes tecken (struligt med varchar) och dels borde göra sortering och liknande betydligt snabbare. (Om man sparar huvudsakligen latinska tecken utan prickar, streck och ringar så kan det dock bli något mer platskrävande). Att använda UCS2 borde alltså vara det optimala för dig (kan såvitt jag förstår fortfarande hämtas med SET NAMES 'utf8', alltså som utf-8 som är bättre för webben).
Vi har alla varit där… B) Efter allt strul med teckenuppsättningar jag hade innan jag bytte till utf-8 genomgående så var jag också aningen tveksam, men kör man bara med utf-8 rakt igenom så blir det sällan problem (java, javascript och alltfler serverskriptspråk och operativsystem använder ju redan utf-8). ;) (Sorry, det här låter visst som någon reklamramsa för tvättmedel… :D )