Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@jroper
Copy link
Member

@jroper jroper commented Jun 26, 2013

I use Mac with locale zh_CN

In application.conf
application.langs="en,zh-CN"

and I add messages.zh-CN right.

Message of Chinese show right for Chrome, but wrong for Safari and Mozilla(show english words).

and if I change all zh-CN to zh-cn, Mozilla and Safari becomes right and Chrome becomes wrong.

and I check with
curl --header "Accept-Language:zh-CN" http://localhost:9000/products
curl --header "Accept-Language:zh-cn" http://localhost:9000/products

Best Regards!

jroper added 3 commits June 26, 2013 16:13
…guage without country to match language with country
Fixes playframework#820 - matching country should be case insensitive
Fixes playframework#1229 - q value sorting should be stable on order in request
header
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be a lazy val? Lazy vals are expensive.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure. If it is called in a request, it is called many times, and so it should definitely by memoised (once calculated, a lazy val costs a volatile read). I'm not sure though how often Lang is instantiated in a request, and code not called. If that happens most requests, then lazy val seems to be the right thing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could "lazy" be a premature optimisation then? We shouldn't start with something being lazy right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depends. We use a lot of lazy vals on RequestHeader for example, since many of those fields are never touched by the average request, but they are expensive because they parse headers. This might be in a similar category.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok - still seems a bit lazy though... :-)

@cloudbees-pull-request-builder

play2-master-PRs #279 SUCCESS
This pull request looks good

huntc added a commit that referenced this pull request Jun 27, 2013
i18n lang should ignore uppercase/lowercase
@huntc huntc merged commit bee040d into playframework:master Jun 27, 2013
jroper added a commit that referenced this pull request Jun 27, 2013
Fixes #820 - matching country should be case insensitive
Fixes #1229 - q value sorting should be stable on order in request
header
@jroper jroper deleted the messages-matching branch June 27, 2013 17:17
@jroper
Copy link
Member Author

jroper commented Jun 27, 2013

Cherry picked to 2.1.x branch:

2903421
f4824cb
a2c3a7b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants