Results 1 to 7 of 7
  1. #1
    Join Date
    Jan 2004
    Location
    Austin
    Posts
    62

    Unanswered: Help database internationalization Chinese

    Had a question. Lets say I have a database designed in English. For internationalization purposes, what should be converted over to Chinese?

    Can the tables, columns, and codes values defined in English stay that way? Yeah, seems like a stupid question, but I was wondering how they would write queries if these things stayed in English?

    Regards,

    Mike

  2. #2
    Join Date
    Jun 2004
    Location
    Liverpool, NY USA
    Posts
    2,509
    SQL is a programming language and doesn't change depending on the host language.
    Bill
    You do not need a parachute to skydive. You only need a parachute to skydive twice.

  3. #3
    Join Date
    Aug 2004
    Location
    France
    Posts
    754
    SQL does not change, and metadata (table names, index names, sequence names...) don't have to change either. Internationalization is only a matter of data : only the contents of the tables/views have to be correctly stored/converted.

    See the Oracle Globalization Support Guide for more information.

    HTH & Regards,

    rbaraer
    ORA-000TK : No bind variable detected... Shared Pool Alert code 5 - Nuclear query ready .

  4. #4
    Join Date
    Jan 2004
    Location
    Austin
    Posts
    62

    Valid points on programming language and structures

    I should have only really asked about the data. So going back to a code
    value. Lets say I have states or countries for instance.

    US - United States
    CH - China
    BZ - Brazil

    Can/should the codes stay intact or would I have to translate to a chinese character?

    Mike

  5. #5
    Join Date
    Aug 2004
    Location
    France
    Posts
    754
    What should be translated is what will be presented to the end user. In your countries example, only country names should be converted, the codes remaining the same (logical since these codes may be used in foreign key relationships, isn't it ).

    For this purpose, for each type of code we have a table which is related to another table with code - language - translated text.

    example :

    Countries

    Code
    US
    CH
    BZ

    CountryText

    Code Language Text
    US en United States
    CH en China
    BZ en Brazil
    US fr Etats-Unis
    CH fr Chine
    BZ fr Brésil

    HTH & Regards,
    rbaraer
    Last edited by RBARAER; 07-20-06 at 04:16.
    ORA-000TK : No bind variable detected... Shared Pool Alert code 5 - Nuclear query ready .

  6. #6
    Join Date
    Jan 2004
    Location
    Austin
    Posts
    62

    Thanks for the info.

    This is pretty much we are planning to do. I just wasn't sure if having english characters in the data elements were going to be a problem if the main characterset is going to be Chinese. I suppose it's not if it will allow for using them to compose queries

    The help is much appreciated.

  7. #7
    Join Date
    Aug 2004
    Location
    France
    Posts
    754
    Quote Originally Posted by PanamaMike
    This is pretty much we are planning to do. I just wasn't sure if having english characters in the data elements were going to be a problem if the main characterset is going to be Chinese. I suppose it's not if it will allow for using them to compose queries

    The help is much appreciated.
    Beware here, "language" and "character set" are different matters, tied but different. Until now you spoke of language only, so I supposed that you knew you would need an universal charset . You won't be able to have western characters with a chinese-only charset : you need an unicode charset that deals with both western and chinese characters as your database charset. With the AL32UTF8 character set for example, you will be able to have data in any language within your database.

    Then client programs may use different character sets (specified via the NLS_LANG environment variable) as far as they are compatible with the displayed data (US7ASCII for english, WE8ISO8859P1 for western europe, a chinese-only character set for chinese clients and so on... or they can simply use AL32UTF8 too if their display support it).

    Beware AL32UTF8 is a variable-length character set and uses between 1 and 4 bytes per character whereas ASCII character sets only use 1, so your database will be bigger .

    FYI UTF8 uses between 1 and 3 bytes and both UCS-2 and UTF-16 are fixed 2-bytes per character charsets. See here for more info on Oracle Unicode support.

    If you follow the link, you will see that UCS-2 and UTF-16 use less space than UTF8 and AL32UTF8 for asian characters (2 instead of 3 bytes per character), but more space for basic ASCII characters (2 instead of 1).

    HTH & Regards,

    rbaraer
    ORA-000TK : No bind variable detected... Shared Pool Alert code 5 - Nuclear query ready .

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •