Hi Rob,
Followed your hints, and spent some time reading our code and comparing to
java.tet.MessageFormat, and also to other classes in the JVM.
>From what I understood, the Category type, used for specifying whether a
>locale can be used for format and/or display, started with JVM 1.7, and hasn't
>been applied to all classes. e.g. while MessageFormat supports it,
>ResourceBundle still uses Locale.getDefault(), without specifying any category
>(though it's also not clear if it will applied to all classes that use Locale).
That said; I can successfully reproduce this in my environment. Should anyone
would like to reproduce it locally, here's the basic steps I think:
* Install Ubuntu LTS in English
* Run the tests (all tests should be OK)
* Add support to Portuguese (sudo apt install ubuntu-keyboard-portuguese
language-pack-pt
calligra-l10n-ptbr firefox-locale-pt kde-l10n-ptbr thunderbird-locale-pt-pt
hunspell-pt-pt hunspell-pt-br wbrazilian thunderbird-locale-pt hyphen-pt-pt
libreoffice-l10n-pt-br kde-l10n-pt libreoffice-help-pt-br
thunderbird-locale-pt-br gimp-help-pt hyphen-pt-br mythes-pt-pt
libreoffice-l10n-pt wportuguese libreoffice-help-pt calligra-l10n-pt
language-pack-gnome-pt)
* Open the Language Support menu, and set the language to Portuguese
* Restart
* Run the tests (5 errors)
Updating ExtendedMessageFormat with your suggestion to use the Category.FORMAT,
fixed **most** failing tests, with one exception:
<-- snip -->
Failed tests:
ExtendedMessageFormatTest.testExtendedAndBuiltInFormats:141 null
expected:<Name: JOHN DOE DOB: [23/01/07 Salary: R$ 12.345,]67> but was:<Name:
JOHN DOE DOB: [1/23/07 Salary: $12,345.]67>
<-- snip -->
I had a look at the source code for that test, and I think the method that
returns the locales would have to support category, or we would have to have a
way to define the global category during the tests. As is now, the test
retrieves a list of locales, which are not aware of the category type. When we
format the text with our pattern, the locale keeps platform-dependent. So in my
case, it will format the date for Portuguese).
Not sure how to fix this last one. Any thoughts?
Cheers
Bruno
----- Original Message -----
From: Rob Tompkins <chtom...@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Sent: Tuesday, 28 February 2017 2:27 AM
Subject: [text] TEXT-64, ExtendedMessageFormat Locale.getDefault() handling
Hello all,
In researching the build issue that Bruno came across in the release of
text-1.0-beta-1, I’ve discovered that it seems that
java.text.MessageFormat(String pattern) differs in its retrieval of the default
locale from out org.apache.commons.text.ExtendedMessageFormat in that it calls
locale = Locale.getDefault(Locale.Category.FORMAT);
whereas we call
locale = Locale.getDefault();
I believe this to be the underlying cause to the issue that Bruno saw when
running the local build of the release candidate. Does anyone have any
heartburn over taking the default locale handling for us and adding
“Locale.Category.FORMAT” to be in line with how java handles this?
As a novice in the locale area, any thoughts and suggestions are entirely
welcome.
Cheers,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
