Internationalization and localization tools


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:

    • NSString
    • CFString
    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.

    I18n Support for Dates and Times

    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

     

    Lingoport internationalization and localization services and software