3903 - Locale- No GetPlatformLocale for Macintosh

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P3)

Description

[nhottanscp]

Need a mapping function from a locale to
script id, lang id, region code and charset name.

Comment 1

[Frank Tang]

mark this m4

Comment 2

[nhottanscp]

Proposed interface for Macintosh.

class nsIMacLocale : public nsISupports {

public:

  // locale to script code, language code and region code
  NS_IMETHOD GetPlatformLocale(const nsString* locale, PRInt16* script, PRInt16*
lang, short* region) = 0;
  // locale to charset name
  NS_IMETHOD GetPlatformLocaleCharset(const nsString* locale, nsString* charset)
= 0;
  // language code and region code pair to locale
  NS_IMETHOD GetXPLocale(const PRInt16 lang, const PRInt16 region, nsString*
locale) = 0;
};

Comment 3

[Frank Tang]

We should use PRInt16* instead of short* for region on GetPlatformLocale

Comment 4

[tague]

Frank :-

The appropriate types to use are short - that is how Script, Region, etc. are
defined in the Macintosh headers.  They aren't defined as PRInt16.  The return
types should match what is in the system headers.

/t

Comment 5

[tague]

Checked in this functionality 4/27/99.

Comment 6

[Katsuhiko Momoi]

Naoki, in what functions are we using this in Mac? Also will we be using this in M5?

Comment 7

[nhottanscp]

There is no way that the client code can use the interface which was checked in
30 min before the tree close for M5 :-)
My plan is to integrate this for M6 also make Mac unit test available.
Tague's unit test may be able to verify this.

Comment 8

[Katsuhiko Momoi]

Tague, I'm inclined to mark this bug verified since there
seems to be no apparent way to check how this works in the
product. If you have a SelfTest program I can use to see if this
is working, I'll attempt to use it. Otherwise, rather than
having this on my plate, we should get it out of the way.

Comment 9

[tague]

look at intl/locale/tests/nsLocaleTest.  that is my self test.   the self tests
build but won't run on Mac because of some changes in the registry which I
haven't nailed down yet.

Comment 10

[Katsuhiko Momoi]

I'm marking this bug fix verified without further testing on Mac which
we are not doing.
Montse,I'm going to mark it verified fixed and put it on your plate.
If you other thoughs, e.g.me doing Mac mail headers sort testing,
then send it back to me.

Comment 11

[bobj]

You verify this in other places using the RDF tree widgets (e.g., Manage
Bookmarks).  I don't know if these are locale sensitive yet.

Comment 12

[nhottanscp]

In my original request, it had script, lang and region while the implementation
doesn't have region returned. I noticed that I need a resion code when I was
debugging yhe date format interface. Sorry for the late notice but I need to
reopen this bug.
The change is just to add an additional mapping table with a look up code. Can I
do the change? I can also do the verification by using it in the date format
interface.

Comment 13

[tague]

sure.  go ahead if you feel comfortable making the changes, otherwise I have M9
work on Macintosh locale and I can take a look at this problem while I do that
work.

Comment 14

[nhottanscp]

I probably cannot do that for M9, in case if you not finish for M9 then move to
M10 and reassign to me, thanks.

Comment 15

[tague]

Naoki :- I added a region code to both GetPlatformLocale and GetXPLocale in the
nsIMacLocale interface.  I made the corresponding changes to the other locale
functionality to keep it building, but I didn't do anything with the region code
in your services.

Comment 16

[nhottanscp]

Set myself as QA Contact.

Comment 17

[nhottanscp]

Tested/verified US,GB,FR,DE,IT,AU,JP using scriptable date format.
Also checked the table, doesn't seem to have any typo.
Marking as VERIFIED.