tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Montero Canabal (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (TAP5-2551) module t5/core/messages and default locale
Date Tue, 24 May 2016 20:43:12 GMT

     [ https://issues.apache.org/jira/browse/TAP5-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Carlos Montero Canabal updated TAP5-2551:
-----------------------------------------
    Description: 
In the js for module messages:

    var locale;
    locale = document.documentElement.getAttribute("data-locale") || "en";
    define("t5/core/messages", ["./messages/" + locale, ....

If my webapp is not configured for locale "en" requirejs returns a 404 not found error because
the "t5/core/messages/en" doesn´t exist and the page doesn´t load (it only shows the mask
meanwhile all modules are loading).  You will put the first locale configured into SymbolConstants.SUPPORTED_LOCALES
as the documentation says.

In fact, there is another bug but I don't found the point of code where it occurs. Yesterday
a Google Chrome update force my locale to en_US (i'm spanish and my locales is es or es_ES)
and when I enter on my webpage who load the messages module, the data-locale attribute was
"en_US", but my webapp only have configured "es". I think there is a missing check between
browser locale and locales supported. I have a webapp store and today any user can buy because
the checkout page (with forms that require messages module) doesn´t load. I fix it with a
workaound (threadLocale.setLocale(new Locale("es")) in the activate method of pages), but
I think that it's a important bug because many websites as mine can be off.
 
UPDATED: As I comment at the bottom, It was a fortuity that my Chrome locale was the same
that the Java VM locale (en_US), so the main bug is in the default locale who returns ThreadLocaleImpl
meanwhile LocalizationSetter is not called.

  was:
In the js for module messages:

    var locale;
    locale = document.documentElement.getAttribute("data-locale") || "en";
    define("t5/core/messages", ["./messages/" + locale, ....

If my webapp is not configured for locale "en" requirejs returns a 404 not found error because
the "t5/core/messages/en" doesn´t exist and the page doesn´t load (it only shows the mask
meanwhile all modules are loading).  You will put the first locale configured into SymbolConstants.SUPPORTED_LOCALES
as the documentation says.

In fact, there is another bug but I don't found the point of code where it occurs. Yesterday
a Google Chrome update force my locale to en_US (i'm spanish and my locales is es or es_ES)
and when I enter on my webpage who load the messages module, the data-locale attribute was
"en_US", but my webapp only have configured "es". I think there is a missing check between
browser locale and locales supported. I have a webapp store and today any user can buy because
the checkout page (with forms that require messages module) doesn´t load. I fix it with a
workaound (threadLocale.setLocale(new Locale("es")) in the activate method of pages), but
I think that it's a important bug because many websites as mine can be off.


> module t5/core/messages and default locale
> ------------------------------------------
>
>                 Key: TAP5-2551
>                 URL: https://issues.apache.org/jira/browse/TAP5-2551
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.4, 5.4.1
>            Reporter: Carlos Montero Canabal
>              Labels: locale, messages
>         Attachments: image.jpeg
>
>
> In the js for module messages:
>     var locale;
>     locale = document.documentElement.getAttribute("data-locale") || "en";
>     define("t5/core/messages", ["./messages/" + locale, ....
> If my webapp is not configured for locale "en" requirejs returns a 404 not found error
because the "t5/core/messages/en" doesn´t exist and the page doesn´t load (it only shows
the mask meanwhile all modules are loading).  You will put the first locale configured into
SymbolConstants.SUPPORTED_LOCALES as the documentation says.
> In fact, there is another bug but I don't found the point of code where it occurs. Yesterday
a Google Chrome update force my locale to en_US (i'm spanish and my locales is es or es_ES)
and when I enter on my webpage who load the messages module, the data-locale attribute was
"en_US", but my webapp only have configured "es". I think there is a missing check between
browser locale and locales supported. I have a webapp store and today any user can buy because
the checkout page (with forms that require messages module) doesn´t load. I fix it with a
workaound (threadLocale.setLocale(new Locale("es")) in the activate method of pages), but
I think that it's a important bug because many websites as mine can be off.
>  
> UPDATED: As I comment at the bottom, It was a fortuity that my Chrome locale was the
same that the Java VM locale (en_US), so the main bug is in the default locale who returns
ThreadLocaleImpl meanwhile LocalizationSetter is not called.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message