[
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)
