Download to read offline
![Volg @King_Software en twitter mee met #KingSoftware!
"Æ".Equals("AE") –[en-US] > False
"Æ".Equals("AE") –[da-DK] > False
string.Compare("Æ“, "AE“)
StringComparison.CurrentCulture
[en-US]-> 0 | [da-DK]-> 1
StringComparison.InvariantCulture
[en-US]-> 0 | [da-DK]-> 0
StringComparison.Ordinal
[en-US]-> 133 | [da-DK]-> 133
String Collation Functions (2/3)
Culture ≠ Invariant ≠ Ordinal](https://image.slidesharecdn.com/internationalizationquadrant-120911004127-phpapp01/75/Internationalization-quadrant-13-2048.jpg)
Uploaded byAndries Nieuwenhuize
Internationalization quadrant
The document discusses globalization and localization in .NET applications. It provides examples and best practices for internationalizing apps, including using CultureInfo and format specifiers correctly. Case studies demonstrate number formatting, date parsing, and string comparisons in different cultures. The conclusion recommends letting the .NET Framework handle globalization and designing apps to be localized after global development.
Internationalization quadrant
- 1. Volg @King_Software entwitter mee met #KingSoftware! The global minded programmer Andries Nieuwenhuize Quadrant software B.V. September 2012
- 2. Volg @King_Software entwitter mee met #KingSoftware! Awareness & pragmatic .Net implementation Case studies: 3 Agenda
- 3. Volg @King_Software entwitter mee met #KingSoftware! Iedere programmeur is cultureel gekleurd Awareness
- 4. Volg @King_Software entwitter mee met #KingSoftware! • International Domain Name Mapping • DNS (ASCII) • quadrant.nl | bücher.de • punycode – bücher > > bcher-kva – büücher > bcher-kvaa – www.münchhausen.at – www.xn—mnchhausen-9db.at Case Study 1: DNS new IdnMapping() .GetAscii() .GetUnicode()
- 5. Volg @King_Software entwitter mee met #KingSoftware! • Learned – Globalization is more than translation – Localized assumptions are everywhere • Best Practice – Let the (.Net) Framework do the talking. – Design Localizable, do localization afterwards. Resumé
- 6. Volg @King_Software entwitter mee met #KingSoftware! System.Globalization.CultureInfo 3 levels : • Invariant (cultureel agnostisch) “” – lijkt een beetje op Engels • Neutral (een taal, niet gebonden tot een region) “en” • Specific (een taal binnen een bepaalde region) “en-US” .NET Building blocks (1/3)
- 7. Volg @King_Software entwitter mee met #KingSoftware! • Thread.CurrentThread.CurrentCulture – default culture for all classes in System.Globalization and thus affects issues such as culture-specific formatting (such as date/time and number/currency formats), parsing, and sorting. • Thread.CurrentThread.CurrentUICulture – default culture used by ResourceManagermethods and thus affects the retrieval of user interface resources such as strings and bitmaps. .NET Building blocks (2/3)
- 8. Volg @King_Software entwitter mee met #KingSoftware! • CultureInfo vs. RegionInfo • "{0} | {1}", c.NativeName, new RegionInfo(c.LCID).NativeName – Nederlands (Nederland) | Nederland • RegionInfo : currency • CultureInfo (remaining parts) • Resumé – CurrentCulture vs. CurrentUICulture – CultureInfo vs. RegionInfo – Invariant vs. Neutral vs. Specific .NET Building blocks (3/3)
- 9. Volg @King_Software entwitter mee met #KingSoftware! Multilanguage with resources • Thread | CurrentUICulture • Strongly typed
- 10. Volg @King_Software entwitter mee met #KingSoftware! Don’t Multilanguage with resources Trans.Found + search.getNumberfound() + Trans.Out_of + search.getTotalEntries(); English: “Found 4 out of 5”; Nederlands: “Gevonden 4 buiten 5”; Do • String.Format string.Format(Trans.FoundTotalNu mberFoundOutOfTotalEntries, search.getNumberfound(), search.getTotalEntries()); “Found {0} out of {1}.” “{0} van de {1} gevonden.”
- 11. Volg @King_Software entwitter mee met #KingSoftware! Case Study: Format specifiers C | D | E | F | G | N | P | R | X var money = 123.456m; "The money {0:C} is mine."; Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US"); "The money {0:C3} is mine.";
- 12. Volg @King_Software entwitter mee met #KingSoftware! Linguistic (Equals) • IEqualityComparer<T> • (==) equality operator | "α".Equals("β") Lexicographic (Compare to) • IComparable<T> • "α".CompareTo("β") String Collation Functions (1/3) Compare ≠ Equals
- 13. Volg @King_Software entwitter mee met #KingSoftware! "Æ".Equals("AE") –[en-US] > False "Æ".Equals("AE") –[da-DK] > False string.Compare("Æ“, "AE“) StringComparison.CurrentCulture [en-US]-> 0 | [da-DK]-> 1 StringComparison.InvariantCulture [en-US]-> 0 | [da-DK]-> 0 StringComparison.Ordinal [en-US]-> 133 | [da-DK]-> 133 String Collation Functions (2/3) Culture ≠ Invariant ≠ Ordinal
- 14. Volg @King_Software entwitter mee met #KingSoftware! linguistic - lexicographic CurrentCulture 100% - 100% += CaseInsensitive 100% - 52% InvariantCulture 80% - 100% += CaseInsensitive 80% - 41% Ordinal 0% - 100% += CaseInsensitive 0% - ? String Collation Functions (3/3) Compare
- 15. Volg @King_Software entwitter mee met #KingSoftware! Don’t • Parse() – “01/02/05” • Jan 2 2005 US • Feb 1 2005 UK • Feb 5 2001 PR China – ToString(“YY/mm /dd”); DateTime Do • ParseExact() • ToString(“d”) • “d” ShortDatePattern • “D” LongDatePattern • “F” FullDateTimePattern
- 16. Volg @King_Software entwitter mee met #KingSoftware! Case Study 3: “-20000.15” zh-HK (HK$20,000.15) • The number -20000.15 formatted as currency. da-DK kr -20.000,15 de-AT -€ 20.000,15 ja-JP -¥20,000 es-AR $-20.000,15 en-GB -£20,000.15 es-CL -$ 20.000,15 id-ID (Rp20.000) de-DE -20.000,15 €
- 17. Volg @King_Software entwitter mee met #KingSoftware! • Kentekenplaten • Postcodes • Continent van een land • Solution: – Extent CultureInfo Not covered
- 18. Volg @King_Software entwitter mee met #KingSoftware! • Awareness: – Be a global minded programmer! • Pragmatic – Let the (.Net) Framework do the talking! • Resources, format-specifiers, cultureInfo, invariant, ordinal. Conclusion
- 19. Volg @King_Software entwitter mee met #KingSoftware! • http://blogs.msdn.com/b/michkap/ • .NET Internationalization: The Developer’s Guide to Building Global Windows and Web Applications Consulted Guy Smith-Ferrier
Editor's Notes
- #4 Rood (waarschuwing of geluk?). Hoeveel maanden heeft een jaar? Hoeveel dagen heeft een jaar? Year -> 353 | 354 | 355 | 356 | 365 | 366 | 383 | 384 | 385 days! Voornaam voor de achternaam die vervolgens achter de voornaam komt. Een maand schrijf je hetzelfde wanneer deze een dag bezit. Dus, januari (in een rijtje) is gelijk aan 1 januari. – Niet in iedere taal. Windows heeft een map Program Files. Links rechts oriëntatie scherm. Iconen. CompuServe (brooddoos / mailbox) Icoon man/vrouw. Uppercasing.
- #5 Domain Name Service uses 7bits ASCII-set. Een casestudy om aan te geven hoe diep culture-assumptions geworteld zitten.
- #6 Localizable is configurabel voor specifieke land/cultuur aanpassingen.
- #7 Het antwoord van Microsoft voor dit probleem. Sla data op in de invariant culture. Dit maakt de applicatie los van cultuurveranderingen.
- #8 Op thread niveau is dit aan te passen. Maar, een nieuwe thread heeft doodleuk de default instellingen.
- #9 Let op het verschil tussen deze twee. Kan voor verwarring zorgen. Kortom, er zijn drie knoppen waarmee kan woren afgestemd. Vuistregels: CurrentUICulture is enkel voor resources, RegionInfo is enkel voor Currency.
- #10 Why resources? Plaatjes en strings.
- #11 Vertaal het liefst de hele tekst. Geen SPOD! Hergebruik in vertalingen is bad practice. Te veel verschillen. Gebruik string.format + formatspecifiers + interpunctie!
- #12 Wat kan er allemaal met format specifiers. Te veel om op te noemen, daarom een case study voor de valuta. Let op de samenwerking tussen de CurrentCulture en de CurrentUICulture! Wanneer ik mijn vermogen in dollars beheer en de Culture (niet de UI-culture!) staat op een Europees land dan worden de dollars in euro’s weergegeven!
- #13 Als het gaat om collation is het belangrijk de twee totaal verschillende vormen te kunnen onderscheiden: Het ene is linguistic en houdt zich bezig met de vraag of twee zinnen taalkundig aan elkaar gelijk zijn. Het andere is lexicographic en houd zich bezig met de vraag in hoeverre twee zinnen van elkaar verschillen. Of, met de alfabetische volgorde (een volgorde impliceert verschil, ongelijkheid). "are they equal?“ vs. "which comes first?" Deze totaal verschillende uitgangspunten hebben ook totaal verschillende implementaties en side-effect e.g. Performance. Zie dit ook terug in de verschillende interfaces, die daarom ook niet van elkaar erven! Let op dat wij in het Nederlands hiervoor geen verschillende (werk)woorden hebben: vergelijken : equals vs. compare
- #14 De equals methode geeft nooit problemen, gebruik wel altijd de case.insensitive i.p.v. ToUpper / ToLower. CompareTo is gevoelig voor de culturele context en de uitkomst wordt daardoor ook (mede) bepaald, of gekleurd zo men wil. Voor de GUI is dit juist gewenst, een gebruiker verwacht dit ook. De invariant optie is om maar volgens een soortje standaard cultuur te werken (toevallig engels), de ordinal is om helemaal niets met culture te doen. Puur unicode points vergelijking. -> wel snel. Een normale stringcomparisson neemt een hele bulk aan culture load mee. Dit resulteert soms in verschillende sorteringsresultaten afhankelijk van cultuurcontext. Dit hoeft geen probleem te zijn, sterker nog dit is een feature. Geef gebruikers de sortingsvolgorde die men verwacht. String.CompareOrdinal gebruikt de Unicode code points voor de vergelijking. Ordinal gebruikt de Unicode code point voor iedere letter. == en Equals zijn het zelfde. De compiler gebruikt equals wanneer “” == “” wordt gedetecteerd.
- #15 Wanneer we vergelijken (compare) in de huidige cultuur is dit 100% huidige cultuur en 100% alfabetisch. Wanneer kapitalen worden genegeerd geven ongeveer dubbel zo veel karakters dezelfde waarde terug: bijv. A en a. Maar, niet in iedere taal is een uppercase gelijk aan zijn lowercase! Vandaar 52%. Voor de invariant culture geldt hetzelfde behalve dat we ons beperken tot een soort engelse subset die op enkele punten afwijkend is van andere culturen. Hier wordt dus iets aan ingeboed. De ordinal doet helemaal niets met cultuur en vergelijkt enkel de unicode code points. Heeft dus ook weinig weet van kapitalen e.d.
- #16 De DateTime.Parse methode verbruikt veel resources omdat deze de inputstring vergelijkt met verschillende schema’s. Daarnaast kan een ingegeven string ambigu zijn. Hiermee wordt de integriteit (CIA) van informatie aangetast! Gebruik daarom altijd parse exact met een mask. De andere kant op geeft natuurlijk precies hetzelfde probleem. Hierbij is het de gebruiker die de datum interpreteert. Geef bij de ToString bij voorkeur patronen die een jaar, maand en dag omvatten waarbij het .Net Framework zelf kiest op welke manier er geformateerd wordt, afhankelijk van de current (UI) culture.
- #17 In al de verschillende specifieke talen is het getal 20000.15 naar valuta anders geformatteerd. Let op de verschillende posities van de valutasymbool, decimaal scheidingsteken en de plaats van het min-teken. Kortom: Let the (.Net) Framework do the talking!
- #20 En hiermee heeft u ook direct het overgrootte deel van al het leesvoer te pakken. Onvoorstelbaar hoe weinig informatie over dit onderwerp is te vinden.