An Oracle blog about BI Publisher

Vietnamese Number Formatting

This one is a bit 'out' there, unless you are one of our Vietnamese users. In which case, welcome and this is for you. If I have not lost the rest of you already, read on it's a good story and a good lesson to be learnt today ...

Dorothy Teoh, from the Singapore Support team, dropped a question to our internal mailing list recently asking:

Hi Gurus,

Does anyone experienced any MLS issue after upgrade to jdk 6 ?  Panasonic logged a severity 1 SR for this issue : 


Customer is using e-Business Suite and recently experinced f60webmx spinning 100% CPU after upgraded to Linux Redhat 4 updates 6.  As a result, support suggested customer to upgrade to latest JDK which is jdk 6.  Customer experienced xml report for Vietnamese default language printed thousand character as '.' instead of comma.  Customer is in Developer 6i patchset 18.  Patches 5488542, 6195758 and 5884875 applied but could not solve the issue.

May I check with wide audience if anyone hit the same issue ?  Could this be new bug in BI publisher ?

We were flattered at being called 'Gurus' but dismayed that, shock, horror, there might be a bug in our product and a new one at that!

Now, it had me beat without a lot of leg work - so I held out for a day or two to see if someone else jumped in. Our internal mailing list probably generates close to 50 mails a day that do not require a one line answer. So we tend to play chicken in the dev team - who is going to hold out longest before answering. But we were saved, Ryoji Suzuki from the Internationalization (i18n) team stepped in with a bomb shell shocker!

This is the expected behavior because:

- Vietnamese has been supported since Java5.
- BI Publisher gets the default decimal and thousand separators from Java.
- Before Java5, the decimal and thousand separator for Vietnamese was:
     Decimal: . (dot)
     Thousand: , (comma)
     Example: 123,456.78
- After Java5 where Vietnamese has been supported, the decimal and thousand separator
   for Vietnamese are:
     Decimal: , (comma)
     Thousand: . (dot)
     Example: 123.456,78

So what you are seeing in Vietnamese report should be expected behavior, and what you saw before upgrading java6 could be considered as a bug.

Regarding this default values (decimal is comma, and thousand is dot), if we see MS Windows regional options (Control Panel -> Regional and Language Options, and choose "Vietnamese") , MS also defines the decimal and thousand separators for Vietnamese as "," (comma) and "." (dot) respectively. So I think the default values should generally work for Vietnamese users.

Would you please double check if the default decimal and thousand separators (decimal is comma, and thousand is dot) are acceptable for the Vietnamese users. I hope it is acceptable.

But if they don't like these default separators, we should file an ER. If you generate the report through concurrent program. there are already two ERs filed. You may want to track them.

For Concurrent manager: Bug#4250828

For OA Framework Region: Bug#5407152

How's that for service:

1. The i18n team are monitoring our mailing list
2. Ryoji does the investigation and finds that its not a bug at least not for BIP. Sun might not be so happy about it thou!

Awesome result, a case of finding the right person looking at the right email at the right time - thanks Suzuki-san!


Join the discussion

Comments ( 2 )
  • aquos bakugan brawlers Wednesday, February 24, 2010
    Hard to know exactly what you're spouting about here. Possibly you could read around the subject before giving such thoughts to the rest of us.
  • battle brawlers Sunday, April 25, 2010
    Hey whats up?. I happened upon your web site while I was searching for something else. While I don't agree with some of what you said we do have almost the same viewpoints by and large. I've bookmarked your blog and may visit again in the near future to see what you're blogging about in 2010!
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.