GWT gets locale from either the locale property or the locale query string. If neither is specified, it uses the "default" (ie en_US) locale.
Why doesn't it get it from the browser settings?
It seems the only solution to this is to replace your static html launch page with something like a JSP that reads the browser locales and sets the locale or redirects using the query string. There has to be a better solution than this or simply hard-coding a locale, surely?
You can also put this switch in your *.gwt.xml
<set-configuration-property name="locale.useragent" value="Y"/>
this will add language selecting based on language selected in browser. You can also control search order for locale by setting
<set-configuration-property name="locale.searchorder" value="queryparam,cookie,meta,useragent"/>
But beware that in IE this doesn't work - you should develop server-side language pick based on 'Accept-Language' header send by the IE.
If you put a list of available languages into your *.gwt.xml file it will by default switch to the first language listed.
<!-- Slovenian in Slovenia -->
<extend-property name="locale" values="sl"/>
<!-- English language, independent of country -->
<extend-property name="locale" values="en"/>
You can use a cookie to save and send this value, but for that you have to add in your *.gwt.xml first
<set-configuration-property name="locale.cookie" value="yourCookieName"/>
<set-configuration-property name="locale.searchorder" value="queryparam,cookie,meta,useragent"/>
Note that "queryparam" has the biggest priority here, that allows to set a new locale using the http query and ignore the value on the cookie.
This worked for me, I hope it also works for you.
My problem was that I have not declared any locale value in .gwt.xml module descriptor. In that case only the default locale is used. GWT does that way because any different supported locale means a new compilation iteration/permutation. Therefore only declared locales are used.
Here you are an example:
<!-- Locales -->
<extend-property name="locale" values="en_US"/>
<extend-property name="locale" values="es"/>
<set-property-fallback name="locale" value="en_US"/>
<set-configuration-property name="locale.useragent" value="Y" />
<set-configuration-property name="locale.searchorder" value="queryparam,cookie,meta,useragent" />
The first and second lines set the available/supported locales (English from US and Spanish without specific country in my example). The third line sets the default locale in case no one is detected (this default declaration must be set after the default value is declared in a extend-property line). The fourth line enables the locale detection by means of the HTTP-Headers Accept-Language sent by browser (probably is enabled by default and not needed to set at all). The final line sets the order in which the different detection mechanisms try to detect the locale:
As a parameter in the URL query
From cookies
As a meta value in the HTML page
From the HTTP header sent by browser
If your entry page is a JSP you can inspect the request's Accept-Language header to dynamically set the locale.
add this entry in your *.gwt.xml file to see the effect!
Please check the following line for more information!
<set-configuration-property name="locale.useragent" value="Y"/>
Related
the <p:calendar> default language is English, I want to change it to French
I added local="fr" but nothing has changed
I add lang="fr" nothing has changed
You need to add script to you page in which localization for calendar is defined. You can see it on Primefaces calendar i18n
Sometimes even though if you change local in code and if it doesn't work then you need to change Browser settings and change local as French or English.
IE --> Tools --> Internet Options --> Under General tab --> languages and add language.
I would like my Chrome extension content script to detect the language or locale of the page's content (not the browser language/locale). I assume there is a method for this in the Chrome extension API, but should I be using standard Javascript libraries instead?
This is the Chrome extension method: chrome.tabs.detectLanguage(...). From the description:
Detects the primary language of the content in a tab.
You could use standard javascript DOM functions to look for a lang attribute on the root html element (or possibly the body element). But keep in mind that a page might not be entirely in one language, so different elements of the page may be marked up with different lang attributes.
Also, if you want to support xhtml, I'd suggest looking the xml:lang attribute as well.
I installed, the bundle: https://github.com/lunetics/LocaleBundle which help to switch between language. Everything works fine, in twig, translation works fine. But when i want to translate any message in the controller, i get french (fr) instead of defined language (en for example).
Please how can i get the current selected locale in the controller ?
i use: $this->getRequest()->getLocale() but it does not work, it give me FR for each culture.
my default setting language in parameter.ini is FR
After looking inside the code of LuneticsLocaleBundle and Symfony 2.1 Documentation, i discovred that, symfony2.1 is passing the Locale in route. The problem exists when rendering an action from twig template, where symfony creates nes request. So, to resolve this, i override the code of LuneticsLocaleBundle and i added $this->get('session')->set('_locale', $_locale); in the switchAction of LocaleController of the bundle.
So, the locale, will be stored in session.
I hope that can helps you too.
Does anyone know if I could use custom HTML attributes in a Web Page, most of mobile devices could read it? or some devices will omit attributes as a default way? In other words: Most default web-browsers installed into mobile devices has the ability to process custom attributes?
I have some code like this:
<input type="text" id="txt1" value="0" percent="50" idColor="12">
the items you are talking about are attributes. If the webbrowser doesn't understand a particular attribute it should ignore them.
Modern browsers generally treat unknown attributes as properties assigned to elements, without any default impact, but recognized as attributes in CSS and JavaScript. In your case, for example, the CSS selector input[idColor] would match those input elements that have the attribute idColor, even though such an attribute is not defined in HTML specs.
In JavaScript, however, they are normally not available directly as properties, so e.g. document.getElementById('txt1').percent would yield undefined, though there are browser differences. But document.getElementById('txt1').getAttribute('percent') would yield 50.
I would expect this to apply to mobile browsers, too, though I only tested this on Android.
It is however unsafe to make up your own attribute names in HTML. What happens if some future HTML spec, or just some browser, assigns a meaning to an attribute called percent? The meaning could be quite surprising, for all that we can now.
Therefore the recommended way to use attributes that carry arbitrary data for use in client side scripting is to use names that start with data-. This gives you your own naming space to play with. No reasonable browser or search engine will ever treat such attributes as anything but page author’s private playground, not to be messed up with. So it would be better to use e.g. data-percent="50" data-color="12".
I have a localized website for different languages
Users can select which language to use in a profile and this will be applied beforePageLoad
using
context.setLocalString("en")
"en" is default to en-US i believe so the dates on the website is displayed in the US format so I learned that I can use instead.
context.setLocale(new Locale("en","gb"))
the problem with setLocal is that is does not update the HTML lang="en" attribute so event though the dates are correct after using setLocal the language file that is used is still the englisn(US) and not the english(uk) one. (i.e not html lang="en-gb")
so when users from england set their language to en-uk in thier profile they get the US language file.
So I tried to do both like this
context.setLocale(new Locale("en","gb"))
context.setLocalString("en-GB")
but then the setLocalString overrides the setLocalString and vice versa. so it looks like I can't use them both
Is there any way I can add code on beforePageLoad to make sure both the html lang attribute gets updated with correct language and my dates dispay in the correct format for the language set?
Instead of using the context object try to set the locale directly in the view root during beforeRenderResponse:
<xp:this.beforeRenderResponse>
<![CDATA[#{javascript:
facesContext.getViewRoot().setLocale( new java.util.Locale("en-GB") );
}]]>
</xp:this.beforeRenderResponse>
Or you can switch the locale in a phase listener as described here:
http://openntf.org/XSnippets.nsf/snippet.xsp?id=xpages-localization-setter
EDIT:
The locale setting is a little bit strange. You have to use an underscore between en and GB when using context.setLocaleString() (as Panu Haaramo answered), but this won't solve problem, because the ViewRootRender uses only the language setting for the generation of the lang attribute while rendering the HTML output.
This
new java.util.Locale("en", "GB").getLanguage()
will return en only, the "GB" is ignored.
Using the context.setLocaleString will bring the same result because this only parses the given string and converts it into a java.util.Locale which returns the same result as descibed.
But using an undefined Locale will generate a lowercased lang attribute. F.e. this
<xp:this.beforeRenderResponse>
<![CDATA[#{javascript:
facesContext.getViewRoot().setLocale( new java.util.Locale("en-Blabla-Blubb") );
}]]>
</xp:this.beforeRenderResponse>
generates the following HTML tag:
<html lang="en-blabla-blubb">
Thats why the code at top of this answer sets the lang attribute to en-gb, but this is still incorrect: It should set it to en-GB as described here: w3.org: Best Practices: Specifying Language in XHTML & HTML Content