Talk:How to localize
From Lift
this page is currently use to share some thoughts about localization before
writing the real HowTo.
This not necessarily the way lift currently works
Contents |
Overview
Lift has full support for internationalization and localization of text in code and templates. Here’s how it works.
How lift selects the current locale (now it doesn't work that way??)
From higher to lower priority:
- user selection
- locale selected by a user with a link, popup list or something else and stored in a cookie. The user is not necessarily logged or has a preferred locale in his profile. If the user selects a new locale the application should change the locale for the current session and either:
- not change at all the user preferred locale in his profile
- change also subsequent sessions when the user is not logged.
- update the preferred locale in the user profile if the user can have one and if he is logged (what if not, should we ask for the user to login :(
- What is the best solution in term of usability? are they other things to do?
- profile
- logged in user profile preferred locale
(interaction with user selection as above can be tricky in term of usability, many very usable sites I know don't rely on a preferred locale in the user profile). - browser
- the user browser locale
- application default
- default locale for the application. Used when the user is not logged, or has no preferred locale in his profile or has not selected a locale stored in the current session or in previous one (cookie) and his browser locale cannot match any of the locales that can be served by the application.
In that case why not simply let the application serve the pages with no locale like my-page.html? There are cases where it's really not convenient.(See: Why we need an application default locale) - jvm or container default locale
- it has the same role as the application default locale except that all applications that have not their default locale explicitly set inherit from the container default locale.
--- This is how lift currently works (dpp 2007/12/16):
By default (with no program change), lift uses the locale supplied by the browser. If none is supplied it will use the server's default locale.
Applications can choose how to implement locale detection by defining a function that returns the current locale.
The ProtoUser trait contains a locale field which can be used for locale detection
Oscar comments (2007/12/16)
Does ProtoUser allow a user that is not logged to select the language? Many multilocale sites have simple links that allow the user to switch locales without the need for the user to be logged. The selected locale is then stored in a cookie. This behavior is so pervasive that I think it should work almost out-of-the-box with minimal coding or configuration.
Why we need an application default locale
Example
I build a bilingual english/french application for the Canadian public. Depending on the provinces, let say Quebec and New Brunswick they will have different domain names or urls but the application will be exactly the same except that in Quebec the default locale for the application is French and in New Brunswick it is English. If I rely on the "no local" pages to be the default I need to do the following:
Quebec
A- my-page.html (default content in french)
B- my-page_en.html
New Brunswick
C- my-page.html (default content in english)
D- my-page_fr.html
In that case, even if the content of A is the same as D and the content of B is the same as C, if we rely on the "no locale" templates and properties as the mechanism to select the default application locale:
- we need to duplicate and rename all the pages
- we cannot use the same instance of the application to serve both Quebec pages and New Brunswick pages.
Solution
There are no "no local" templates and properties, only locale qualified ones.
my-page_fr.html
my-page_en.html
The framework selects a default locale according to some mechanism like the request url (for example its domain name), the user IP address or simply the jvm default locale and serves the appropriate page accordingly.
current locale selection (dpp 2007/12/16)
lift does not present users with different URLs based on locale and I'm pretty sure that this is the right behavior.
when a URL comes in (e.g. /foo/bar), lift will look for a template based on the current locale (language and country). For example: /foo/bar_fr_CA.html
If there's no match for language and country, lift will look for just language: /foo/bar_fr.html
If there's no match, then lift will look for a default template: /foo/bar.html
Also, if the template is rendered as a Scala class (rather than a text resource), it is up to the class to choose the appropriate locale. /foo/bar will always be serviced by mypackage.view.Foo using the bar method.
- Oscar Comments 2007/12/16
The behavior you describe is correct. I am not sure we are talking about the same think. I should have limited my example to locale selected on the domain name for example we could have:
www.quebec.com/foo/bar => serves /foo/bar_fr.html by default when the user locale cannot match any supported locale.
www.newbrunswick.com/foo/bar => serves /foo/bar_en.html by default when the user locale cannot match any supported locale.
That should work even if the underlying application is the same.
But that case can just be covered, I think, with the custom function returning the locale.
