Locale-Sensitive Objective-C Methods
I18n Overview
Unicode String Support and String Processing
Locale Support
I18n Support for for Formatting Dates and Times
Summary List of Locale-Sensitive Objective-C Method
I18n Overview
Objective-C is a superset of ANSI C that has been extended with a few syntactical and semantic features
derived from Smalltalk to support object-oriented programming. These added syntactic constructs are easy
to identify but are not required in an Objective-C program. One can freely intermix straight C code with
Objective-C code, for example - utilizing code written to take advantage of either Foundation Framework
(Objective-C) or Core Foundation (straight C).
The older Carbon API is the pure C side of the Mac OS X.
With the introduction of Mac OS 10.5 and preference for Objective-C API, some significant set of Carbon functions are deprecated.
Supporting the full set of old C functions is questionable, but a better target is the set of API functions
beginning with the CF prefix (Core Foundation). It largely corresponds to functionality also found in the
Foundations API which is the pure Objective-C side of the Mac OS X which has the prefix NS (NextStep) in
naming of classes. In effect, this means when utilizing an I18n tool like Globalyzer, one is looking for a
mix of both C and Objective-C issues in parallel. Presently Globalyzer tries to take both issue sets into
account when scanning code.
In addition, code can call C or even C++ functions defined in non-native programmatic interfaces, e.g., BSD library interfaces in /usr/include or perhaps 3rd party code that has been ported from a non-Apple platform. You can even mix C++ code with your Cocoa code and link the compiled code into the same executable. This level of intermixing is significantly more problematic. Presently, this sort of external code needs to be handled by Globalyzer by configuring a separate ruleset (e.g., ANSI C or C++ ruleset) and using it to make a separate scan in addition to whatever scans have been made with Objective-C rulesets.
Support is largely tied to either a NS Foundation class or its corresponding CF Core Foundation record reference type. A summary of the areas that need to be specifically analyzed in an Objective-C application are:
- Unicode String Support and String Processing
- Locale Infrastructure
- I18n Support for for Formatting Dates and Times
Apple I18n Developer References
General Overview -
I18n overview and links - MAC OS and iOS
Introduction to Apple I18n - MAC OS
General Guidelines for Apple I18n
I18n Apple Developer Conference -
Apple I18n Slides
Examples and Sample Code -
Localization
Internationalization
Unicode String Support and String Processing
Although Objective-C permits the treatment of strings in the base C/C++ style (char* or char or perhaps STL string type), the newer tradition has 2 indigenous types:
Although both have
Unicode as the underlying base technology for strings, at API boundaries especially when I/O is involved, these often convert the internal Unicode Strings to external byte sequences corresponding to another encoding and back again as needed. These encodings are variously called "ANSI", "ISO", or "native" encodings. Since these are generally language-specific, this conversion can cause problems and corruption of character data unless the target encoding is simply a Unicode transformation encoding.
Typically the conversion process uses the default or system encoding which generally is not Unicode. Thus in the
case of a backend that serves many clients in many locales, the system encoding
page often is not the correct encoding for the client being served.
Locale
Objective-C also uses the default or system locale settings for Date and Time formatting, which is just as
incorrect as using the system default encoding in a server environment where the client is not on the host
machine.
In an internationalized application, code that contains formatting
strings such as "mm/dd/yyyy" should be refactored if the dates are to
be displayed to an end user. For example, whereas May 03,
2005 in the U.S. would be displayed as 05/03/2005, in Spain it would be
displayed as 03/05/2005 ("dd/mm/yyyy").
Unfortunately, the locale-sensitive formatting methods that Objective-C provides, may or may not
be dependent on the system locale.
Another problem with a date-time method can be its use of a system
timezone setting when formatting dates and times, which is incorrect in a
server setting as the dates and times will be wrong if a user/client is in a
different timezone.
Locale-Sensitive Objective-C Method List
Click on a specific method below to get more information.
File and Path Operations Method List
Locale and Character Set Method List
Number Format Method List
Collation Method List
Date/Time Method List
String Formatting Operations Method List
 Locale-Sensitive Methods Table of Contents
|
