• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: -[NSString localizedCompare:] - example of semantic difference with compare?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: -[NSString localizedCompare:] - example of semantic difference with compare?


  • Subject: Re: -[NSString localizedCompare:] - example of semantic difference with compare?
  • From: Deborah Goldsmith <email@hidden>
  • Date: Fri, 24 Mar 2006 12:29:23 -0800

Hmmm. There doesn't appear to be a way to do this with the NSString API. You can do it with CFStringCompareWithOptions:

enum CFStringCompareFlags {
   kCFCompareCaseInsensitive = 1,
   kCFCompareBackwards = 4,
   kCFCompareAnchored = 8,
   kCFCompareNonliteral = 16,
   kCFCompareLocalized = 32,
   kCFCompareNumerically = 64
};

Of course, you can pass an NSString to CFStringCompareWithOptions.

You might want to file a bug against NSString to add either localizedCompare:withOptions:, or to add a NSLocalizedSearch option.

Deborah Goldsmith
Internationalization, Unicode liaison
Apple Computer, Inc.
email@hidden

On Mar 23, 2006, at 6:30 PM, Ricky Sharp wrote:


On Mar 21, 2006, at 9:07 PM, Deborah Goldsmith wrote:

Well, many languages -- like French and Danish -- have a basic collation order that's different from English, so if you don't use localizedCompare: your sort will be in the wrong order for users speaking those languages. Those users will consider your application to be broken. If you want to see a language that's *really* different from English, try setting your sort order to "Hawaiian" in International Preferences, then look at a Finder listing.

Sorted data that is intended to be shown to end users should always be sorted using localizedCompare:.

I'm really glad this thread came up! I was using compare: for a list of students that I display. Specifically, I was doing this:


- (NSComparisonResult)listItemCompare_II:(NSString*)anItemName
{
return [self compare:anItemName
options:NSLiteralSearch | NSNumericSearch | NSCaseInsensitiveSearch];
}


This allowed me to work correctly with numeric data (i.e. '2' comes before '10').


I just completed four runs where I used both Hawaiian and English sort orders along with calling compare: and localizedCompare: Here are the results...


When using compare:, I got the same output regardless if I specified Hawaiian or English:

A hui hou
Maika'i no au
student
Student #1
Student #2
Student #10
student #11
'Ae
'A'ole
<Chinese>

where <Chinese> is a single glyph (U+7389) and ' is actually the proper okina character (U+02BB) used by the Hawaiian language.

I can now see why using compare: is really bad. I believe it's literally (hence the name of the constant NSLiteralSearch) taking the unicode hex value and primarily grouping on that.


When using localizedCompare:, I lost the ability to sort numbers correctly, but the ordering of words/phrases is now proper based on language:


English (Note how the "A" words all group together)
-------
A hui hou
'Ae
'A'ole
Maika'i no au
student
Student #1
Student #2
Student #10
student #11
<Chinese>


Hawaiian (Note how words starting with the okina (') are grouped in their own section.
Also very cool about the 'S' words showing up after all the Hawaiian words as 'S' is not a letter in the Hawaiian alphabet!
--------
A hui hou
Maika'i no au
'Ae
'A'ole
student
Student #1
Student #2
Student #10
student #11
<Chinese>



Now then, for my needs, I much prefer localizedCompare: My product is English-only, but it does sell worldwide and thus student names will be in many different languages. For me, having the numbers sort correctly will most likely not be an issue at all. I would assume most, if not all, of my users would use proper names and not "Student #1", etc.


However, is their any method currently that can give us the logic of localizedCompare:, yet with the other "smarts" like numerical ordering? I can write an enhancement request if need be.

___________________________________________________________
Ricky A. Sharp         mailto:email@hidden
Instant Interactive(tm)   http://www.instantinteractive.com


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: -[NSString localizedCompare:] - example of semantic difference with compare?
      • From: Ricky Sharp <email@hidden>
References: 
 >-[NSString localizedCompare:] - example of semantic difference with compare? (From: Jim Correia <email@hidden>)
 >Re: -[NSString localizedCompare:] - example of semantic difference with compare? (From: Deborah Goldsmith <email@hidden>)

  • Prev by Date: NSStringPathExtensions thread safety?
  • Next by Date: Is it possible to compare two SecKeychainRef?
  • Previous by thread: Re: -[NSString localizedCompare:] - example of semantic difference with compare?
  • Next by thread: Re: -[NSString localizedCompare:] - example of semantic difference with compare?
  • Index(es):
    • Date
    • Thread