[text] TEXT-64, ExtendedMessageFormat Locale.getDefault() handling

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[text] TEXT-64, ExtendedMessageFormat Locale.getDefault() handling

Rob Tompkins
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-64, ExtendedMessageFormat Locale.getDefault() handling

Bruno P. Kinoshita-3
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 <[hidden email]>
To: Commons Developers List <[hidden email]>
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: [hidden email]
For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [text] TEXT-64, ExtendedMessageFormat Locale.getDefault() handling

Rob Tompkins-2

> On Feb 28, 2017, at 4:18 AM, Bruno P. Kinoshita <[hidden email]> wrote:
>
> 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 —>

This is just a feeling here, but for some reason I think this is the default locale scenario happening again. Did you put the “Locale.Category.FORMAT” in ExtendedMessageFormat on both lines 120 and 143? If so, then indeed, we will have to investigate further.

-Rob

>
> 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 <[hidden email]>
> To: Commons Developers List <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]