Hi Scott,
You are right - I should have said when the plugin code is run, during Trinidad
compilation. Thanks for catching that. So,
1. Trinidad compile - this needs to be bumped up
2. Trinidad run-time - this should stay the same because we are modifying some
client Locale files (Locale_*.js), so only Javascript changes needed to uptake
them.
Yee Wah
On 2/24/2012 2:23 PM, Scott O'Bryan wrote:
I think this sounds reasonable, especially for these bugs. I do have some
questions though..
1) would the minimum version of the JDK need to be bumped up for trinidad as
well?
2) would these changes only need to be made at compile time, or would the min
java version need to be upped for Trinidad runtime as well.
As you know, there are many options here. Of course if this only impacts
"compiling" the plugins, I don't see any issues at all.
Scott
On Thu 23 Feb 2012 04:24:24 PM MST, Yee-Wah Lee wrote:
Hi everyone,
I have seen a couple of issues in the maven-i18n-plugin which could be resolved
by some code changes + moving to a higher JDK version. My understanding is that
the plugins currently need to compile in JDK1.5 as well as 1.6.
1) TRINIDAD-2126 : convertdatetime fails with datestyle=full, th_th or ja_jp_jp
locale
https://issues.apache.org/jira/browse/TRINIDAD-2126
The JSLocaleElementsGenerator uses DateFormatSymbols#getEras() to generate era
strings like 'BC', 'AD'.
However, in non-Gregorian calendars like Thai Buddhist (th_TH) and Japanese
Imperial (ja_JP_JP), these return the translations of 'BC'/'AD' instead of the
different eras of the calendar, e.g. ‘Heisei', 'Meiji' for Japanese.
The problem in DateFormatSymbols#getEras() was reported against jdk1.4 (by
developer), and fixedin jdk1.6.
http://monaco.us.oracle.com/detail.jsf?cr=4833268
2) Trinidad-2225: Client numberConverter with type=percent fails in tr_TR locale
https://issues.apache.org/jira/browse/TRINIDAD-2225
The JSLocaleElementsGenerator uses DecimalFormat.getPositiveSuffix() to
generate the suffix used when formatting percentages. In Turkish locale,
percentages are formatted using prefixes.
To detect this case, we will need to send the prefix data down. However,
getPositivePrefix() did not always return the correct value, it was fixed for
tr_TR locale starting in jdk 6u10 .
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4494727
Because of these two issues, I wanted to get your feedback on moving the
minimum version for the plugins to 1.6u10 and up. Any comments?
Thank you,
Yee-Wah Lee
