amir877amir877 Registered User
Hi, I have some question about the Keyboard, when i swich to "Israeli" keyboard and try to set a name to one of the palettes, i can type in Hebrew and i can see Hebrew language in the Quickname window but the time i press Enter, the palette name is in a different language.
Way? way it can't be in the same language that i type? cuz i can see Hebrew in the Hog so way it can't be see in a palette or cuelist ?? :dunno:



  • teericksonteerickson Registered User, HES Alumni
    edited September 2006

    I've taken a look at this, and it appears that support for internationalization was never properly completed. Characters appear properly while you are editing a name, but when the name has been saved it doesn't seem to be rendering using the proper code page.

    I've opened bug #10004 for this issue and I've added your comments to the defect.

    Thanks for the report.
  • amir877amir877 Registered User
    edited September 2006
    So it should work?! ye ! :headbang:

    I tall you the truth, when the Hog start to show Hebrew on palettes and cue's, i never leave that console !!!

    Thank you so much !

    WHOLE :hogsign:

  • Akito.HAkito.H Registered User, Hog Beta
    edited September 2006
    Is Japanese scheduled to be supported some time?

    This is the most difficult demand in the thing that I know.

  • teericksonteerickson Registered User, HES Alumni
    edited September 2006
    I hope you're interested in a bit of background, because I'm going to try and explain some of the logic behind this to help with answering your questions.

    Internationalization is the term used to describe implementing locale-specific content and functionality into an application. It's a *huge* process that can touch just about every portion of an application and its source code.

    The operating system (Windows, linux, etc.) generally provides some basic services and support for multiple languages, but large amounts of planning and development are still required to ensure that an application can take advantage of this and do everything that it needs to do.

    One of the issues is the support for the characters of different languages. Each language generally has a code page, which is a specific character encoding table for mapping individual characters to numbers. ASCII (American Standard Code for Information Interchange) is a very common character encoding based on he English alphabet.

    Each ASCII character is stored using 7 bits. This allows for 128 characters (95 printable and 33 control).

    Extended ASCII is far more common these days. It added an 8th bit (to use a full Byte) and allows for 256 characters.

    The C++ programming language offers a data type called char that (usually) uses 1 Byte of storage and is usually the data type used for storing single characters. At a very basic level, strings are basically just collections of characters.

    Here's where things get interesting.

    There are a number of languages that have far more than 256 characters.

    In 1991, an industry standard called Unicode was developed to allow text and symbols from all of the writing systems in the world to be consistently represented and manipulated by computers. There are a number of different Unicode encodings, but the most common use either 16 or 32 bits of data to store each character. The C++ language has a data type called wchar_t (wide character) that can be used for storing Unicode characters.

    And now the problems.

    If you have an existing computer application that you want to internationalize and it wasn't originally planned and designed to have Unicode support, it may take a lot of work to add that support. Every single time that you work with a character, whether you're accepting it as input, passing it or receiving it from a function, storing it to disk, or displaying it on screen, it will need to be done using a data type that can support Unicode characters.

    Even when this (potentially massive amount of) work has been done, you still need to consider many other points that relate to how text is input and displayed. A good example, (and Amir can probably correct me here if I'm wrong) is that I believe that Hebrew is written and read from right-to-left, unlike English.

    In summary:
    1) Groundwork has been done for multi-lingual support on the Wholehog 3.
    2) Bug #10004 is open describing at least one problem with characters not displaying properly.
    3) I'm not sure at this point what multi-lingual features are working and not working. I'll dig into this a bit and chat with some of the developers who may have a better understanding of where we're at, but I'd be glad to continue getting feedback from everyone here and I will certainly continue to open bugs for the problems that you report.

  • Akito.HAkito.H Registered User, Hog Beta
    edited September 2006

    Thank you for a very detailed explanation.

    Japanese certainly has the character of 256 or more.

    However, a Japanese environment has been achieved in Linux.

    Therefore, I will not throw away the dream of inputting Japanese to Wholehog some time.

    Thank you again,
Sign In or Register to comment.