Japanese

Well, first of all, why using an string iterator instead of directly assigning the string to your text area?

Then, what does "doesn't render the 'sti' String in terms of the same characters." mean?

And finally, is the font you're using is installed?

I'm having to guess that your intention - as you haven't stated your goal - is to print out Japanese characters in some way.
That will so far only print out the word 'japanese' as that is the string given as input

    public JTextArea getJap() {
        // Show Katakana codes 
        final char START = 0x30A1;
        final char END   = 0x30FB;
        JTextArea result = new JTextArea();
        result.setLineWrap(true);
        for(char c = START;c <= END;c++) {
          result.append(String.valueOf(c));
        }  

        return result;
    }

Select allOpen in new window

Would be a good tester

Well, first of all, why using an string iterator instead of directly assigning the string to your text area?

Simply because I want to try this class out. It's investigational.

Then, what does "doesn't render the 'sti' String in terms of the same characters." mean? 

Well if :

(loc.getDisplayLanguage()).toString() 

Select allOpen in new window

returns a String, and the return value is displayed as Japanese characters, then what would be stopping a different String being displayed as Japanese also ?

And finally, is the font you're using is installed?

I've tried many but it's tedious retrying with every possible one, but no, it's not evidently in the set.

Oh i think i see where you're going with the Locale - you want to display the name of the language in that language with the correct glyphs for that language?

You'd be best loading a font known to have those characters as a resource

result.append(loc.getDisplayLanguage().toString());

Select allOpen in new window

gives for me

what would be stopping a different String being displayed as Japanese also ?

Did you post that code?

Yup, that's exactly where I am with this, and the result you get is the same at my end.

So now my question is "what's going on" ? Because if I now append the result of :

String sti = new String("We would like this to appear in Japanese"

Select allOpen in new window

 to the JTA, it comes out "in English" (i.e. exactly as in the line above.

(  Obviously this new String is getting run through the same StringCharacterIterator, and the Locale is the same (iow was already changed to being  <<new Locale("ja","JP");>>   )

it comes out "in English" (i.e. exactly as in the line above.

Well i'm not sure why it wouldn't - unless it were some kind of translation program

The reason the name of the language appears in Japanese is because it's a Japanese word

Sorry - this is amusing (obviously because I don't see the wood from trees with it), but hold on - I've changed the Locale . . ., and obtained a character output (same as the one in your display) in (some sort of) oriental script (not even sure it's Japanese), which is the result of having worked on a String supplied by : loc.getDisplayLanguage();

So what do you mean when you say that it appears in Japanese because it's a Japanese word ? It's not a Japanese word, it's the word "Japanese".

So what do you mean when you say that it appears in Japanese because it's a Japanese word ? It's not a Japanese word, it's the word "Japanese".

Well i think it might return the word in the language of the Locale but i'm going to test that to see if i'm right

Yes, CEHJ, I think that's what is happening. (I need to say that I don't expect the string I've given to be literally translated into Japanese. I don't care it it's meaningless in real terms - what I was expecting is an output that interprets the "Western" characters, as whatever their bytes would represent in Japanese. That resulting string could be entirely meaningless for all I care at this point.

Yes, this is what you're seeing in your program text area. Because it's the word for 'Japanese' in Japanese

what I was expecting is an output that interprets the "Western" characters, as whatever their bytes would represent in Japanese.

Well it doesn't really work like that. The 'lower' character codes are really the same for everyone and represent the old 'ASCII' characters. Japanese characters simply have their own (much higher) codes

Right. Well that's good because for quite a moment, I thought I was losing it. Especially when the console output came back with the word "Japanese", and it was only when I stuck it in a JTextArea that it output the Japanese characters. Spooky.

So this of course leads me to wonder . . . what is it that needs to be done to get Japanese output in the JTA? It can only be by inputting Japanese presumably. And that, presumably, involves switching the keyboard over. So how is that done, and what was the use of setting the Locale and font to the exotics ?

:)

Just in case there's any confusion, consider the following change and its outcome:

        //Locale loc = new Locale("ja", "JP");
        Locale loc = new Locale("cs", "CZ");
       System.out.println(loc.getDisplayLanguage().toString());

Select allOpen in new window

Yes indeed.
Peculiar notion somehow - the fact that "foreign" character output is obtainable (from somewhere under the hood, as the system apparently understands what the programmer has in mind when asking for  specific Locale), but can't follow through on repeating that outside the 'getDisplayLanguage()' context. And that's without having the correct Font live. : )

Yes, localisation is central to the OS. When you first set it up, it will ask what your country and language is. That becomes your default locale. Java gets this from your OS, Others can be created at will. As for "following through", i'd need to know your goal in order to advise

Right, yes, thanks.

My aim is along the lines of 'professional development' I suppose you'd say, which sounds more serious than just wondering about something, if you follow. : 0 ) It will come in useful however, as I have a couple of small programmes that send files and messages, and need to get to grips with the vernacular on producing and reading foreign script.

On the immediate question . . . I admit to having a conceptual problem with getDisplayLanguage() being able to render Japanese script . . . why, for instance, if it's not going to be able to render my English strings into "Japanese bytes" (as I said, no problem if that amounts to gibberish), then why bother telling me - in Japanese - that the language locale I've chosen is Japan and Japanese ?

I'm now looking at part of the API I haven't seen before :

java.awt.im

Class InputContext

and wondering if some kind of answer lies in there  perhaps . . . ?

then why bother telling me - in Japanese - that the language locale I've chosen is Japan and Japanese ?

Mostly, programmers are interested in internationalisation since their goal is that they want as many different countries as possible to use their software. Obviously that's a tradeoff. In order, for instance, to produce a button caption that says 'Off' in all the languages of the world, you'd have to produce that string by translating 'Off' into all the languages of the world. That effort is probably going to wasted for some countries. But if you thought there might be a large enough Japanese market, it would maybe be worthwhile to produce all your UI strings in Japanese.

Let's say you had a local-choosing interface button (you might not want to only enable the OS-default locale). Being able to put up the word 'Japanese' IN Japanese could be quite useful in such circumstances.

Remember that the actual production of all the foreign language text all has to be done by you

CEHJ -

(I can ask another Q on this if you like, but equally I can just give points here if you like) . . .

. . .  is there maybe something you can say about this class, and what I may be able to do with it to obtain the effects I have been mentioning in this question above - i.e. obtaining 'foreign' characters ? The comment in this class spec seem promising :

​Input​​​

I think it would probably be better to have a fresh question

ok