Re: Formatting locale vs. translation locale
Simon Lessard wrote: I'm so divided on this issue that I think I'll call a +0 on my side. When I go on a site in English, I expect the date to be formatted accordingly. On I couldn't tell from the comment what you meant exactly. It may be obvious when you switch languages, but you may not switch languages. If I'm in the UK running in English I will expect UK date formatting, which I think means day-month-year, and not month-day-year. I think it's pretty subtle that you're actually running in en-us and not en-gb, I don't expect the user to know that. the other hand, some user are... well... hmmm... not so comfortable with computers and could completely ignore that date can even appear in more than one format. Anyway, whatever decision is taken, I agree with Martin that we'll need to indicate it clearly. So I suggested we use a config param, the default is 1, but you can 'buy in' and set it to 2. What do people think of that? Thanks, Gab Regards, ~ Simon On 10/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: I believe that #1 is what we should do. If you do #2, then the locale will be changed away from what the view-root offers (and which might be derived from the accept-header of the request, so you have the possibility to implement #2) somehow automagically - without the developer really knowing. - First (that's the same issue as you had) - existing applications behave differently. - Second - also as a user, I'm expecting US-date format when I'm looking at an application I18nized in en-US. If you give me German date formats, you'll need to indicate this clearly, and that's something a developer has to do manually and consciously (except Trinidad has some automatic way of indicating date, time and number-format to the user). So as a German-speaking user, this is not the way I'd want the application to behave automatically. regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Arjuna Wijeyekoon wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. That's a very good point. If they only have US translations, the help uses US formatting, now we come along and actually use UK formatting, so the help is wrong. That does seem like a major problem for #2. Could we have a config setting to switch on #2, because I think #2 is very useful, but maybe they need to buy in, it's still a much less painful buy in than they have now with the converter 'locale' attribute Thanks, Gab 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be in (UK) dd-MM-, and I am actually getting (US) MM-dd-, that could cause me to miss my flight. --arjuna -- Adam --arjuna On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates
Re: Formatting locale vs. translation locale
It's true that en_US and en_GB can cause a problem. However this will hold true only if the language is the same. So, if we implements that maybe we can limit the valid formatting locales to those sharing the same language and only switch the country? That way it will be impossible to get in a state of German translation with fr_ca formatting. On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Simon Lessard wrote: I'm so divided on this issue that I think I'll call a +0 on my side. When I go on a site in English, I expect the date to be formatted accordingly. On I couldn't tell from the comment what you meant exactly. It may be obvious when you switch languages, but you may not switch languages. If I'm in the UK running in English I will expect UK date formatting, which I think means day-month-year, and not month-day-year. I think it's pretty subtle that you're actually running in en-us and not en-gb, I don't expect the user to know that. the other hand, some user are... well... hmmm... not so comfortable with computers and could completely ignore that date can even appear in more than one format. Anyway, whatever decision is taken, I agree with Martin that we'll need to indicate it clearly. So I suggested we use a config param, the default is 1, but you can 'buy in' and set it to 2. What do people think of that? Thanks, Gab Regards, ~ Simon On 10/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: I believe that #1 is what we should do. If you do #2, then the locale will be changed away from what the view-root offers (and which might be derived from the accept-header of the request, so you have the possibility to implement #2) somehow automagically - without the developer really knowing. - First (that's the same issue as you had) - existing applications behave differently. - Second - also as a user, I'm expecting US-date format when I'm looking at an application I18nized in en-US. If you give me German date formats, you'll need to indicate this clearly, and that's something a developer has to do manually and consciously (except Trinidad has some automatic way of indicating date, time and number-format to the user). So as a German-speaking user, this is not the way I'd want the application to behave automatically. regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Arjuna Wijeyekoon wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. That's a very good point. If they only have US translations, the help uses US formatting, now we come along and actually use UK formatting, so the help is wrong. That does seem like a major problem for #2. Could we have a config setting to switch on #2, because I think #2 is very useful, but maybe they need to buy in, it's still a much less painful buy in than they have now with the converter 'locale' attribute Thanks, Gab 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be in (UK) dd-MM-, and I am actually getting (US) MM-dd-, that could cause me to miss my flight. --arjuna -- Adam --arjuna On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so,
Re: Formatting locale vs. translation locale
What's the problem with running in German with fr_ca formatting locale? Basically if you're entering dates you want to let the user enter them in the way they are used to, if the help can support it. If I'm German and go to an English page, I think I would be quite happy if I could enter the date, numbers, etc in the way I'm used to. I guess I think the reason locale was put on converters was to let users format data in the way they are used to, even if the language/country is different. Thanks, Gab Simon Lessard wrote: It's true that en_US and en_GB can cause a problem. However this will hold true only if the language is the same. So, if we implements that maybe we can limit the valid formatting locales to those sharing the same language and only switch the country? That way it will be impossible to get in a state of German translation with fr_ca formatting. On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Simon Lessard wrote: I'm so divided on this issue that I think I'll call a +0 on my side. When I go on a site in English, I expect the date to be formatted accordingly. On I couldn't tell from the comment what you meant exactly. It may be obvious when you switch languages, but you may not switch languages. If I'm in the UK running in English I will expect UK date formatting, which I think means day-month-year, and not month-day-year. I think it's pretty subtle that you're actually running in en-us and not en-gb, I don't expect the user to know that. the other hand, some user are... well... hmmm... not so comfortable with computers and could completely ignore that date can even appear in more than one format. Anyway, whatever decision is taken, I agree with Martin that we'll need to indicate it clearly. So I suggested we use a config param, the default is 1, but you can 'buy in' and set it to 2. What do people think of that? Thanks, Gab Regards, ~ Simon On 10/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: I believe that #1 is what we should do. If you do #2, then the locale will be changed away from what the view-root offers (and which might be derived from the accept-header of the request, so you have the possibility to implement #2) somehow automagically - without the developer really knowing. - First (that's the same issue as you had) - existing applications behave differently. - Second - also as a user, I'm expecting US-date format when I'm looking at an application I18nized in en-US. If you give me German date formats, you'll need to indicate this clearly, and that's something a developer has to do manually and consciously (except Trinidad has some automatic way of indicating date, time and number-format to the user). So as a German-speaking user, this is not the way I'd want the application to behave automatically. regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Arjuna Wijeyekoon wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. That's a very good point. If they only have US translations, the help uses US formatting, now we come along and actually use UK formatting, so the help is wrong. That does seem like a major problem for #2. Could we have a config setting to switch on #2, because I think #2 is very useful, but maybe they need to buy in, it's still a much less painful buy in than they have now with the converter 'locale' attribute Thanks, Gab 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be
Re: Formatting locale vs. translation locale
Yes, and no... It depends on your users really. When I buy something from USA I know how to enter the date because I'm used to it, all other sites work that way. If the site was somehow intelligent enough to see that I'm French Canadian and to switch its date format accordingly, I would be quite lost if the application was not giving any clue about the format used. However, new Internet users will probably find it nice because they won't be used to usual behavior. My 2ยข, ~ Simon On 10/25/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Right! I am able to read english content, but I have no idea how english speaking guys enter their dates. Or more true, I don't care. In a *corperate* application, I am fine w/ reading english content, but want my German date format :) -M On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: What's the problem with running in German with fr_ca formatting locale? Basically if you're entering dates you want to let the user enter them in the way they are used to, if the help can support it. If I'm German and go to an English page, I think I would be quite happy if I could enter the date, numbers, etc in the way I'm used to. I guess I think the reason locale was put on converters was to let users format data in the way they are used to, even if the language/country is different. Thanks, Gab Simon Lessard wrote: It's true that en_US and en_GB can cause a problem. However this will hold true only if the language is the same. So, if we implements that maybe we can limit the valid formatting locales to those sharing the same language and only switch the country? That way it will be impossible to get in a state of German translation with fr_ca formatting. On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Simon Lessard wrote: I'm so divided on this issue that I think I'll call a +0 on my side. When I go on a site in English, I expect the date to be formatted accordingly. On I couldn't tell from the comment what you meant exactly. It may be obvious when you switch languages, but you may not switch languages. If I'm in the UK running in English I will expect UK date formatting, which I think means day-month-year, and not month-day-year. I think it's pretty subtle that you're actually running in en-us and not en-gb, I don't expect the user to know that. the other hand, some user are... well... hmmm... not so comfortable with computers and could completely ignore that date can even appear in more than one format. Anyway, whatever decision is taken, I agree with Martin that we'll need to indicate it clearly. So I suggested we use a config param, the default is 1, but you can 'buy in' and set it to 2. What do people think of that? Thanks, Gab Regards, ~ Simon On 10/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: I believe that #1 is what we should do. If you do #2, then the locale will be changed away from what the view-root offers (and which might be derived from the accept-header of the request, so you have the possibility to implement #2) somehow automagically - without the developer really knowing. - First (that's the same issue as you had) - existing applications behave differently. - Second - also as a user, I'm expecting US-date format when I'm looking at an application I18nized in en-US. If you give me German date formats, you'll need to indicate this clearly, and that's something a developer has to do manually and consciously (except Trinidad has some automatic way of indicating date, time and number-format to the user). So as a German-speaking user, this is not the way I'd want the application to behave automatically. regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Arjuna Wijeyekoon wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to
Re: Re: Re: Re: Formatting locale vs. translation locale
On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. Not sure I follow. There's no way we can get away with having only one behavior here; we need to support both the original JSF behavior and this new customized behavior, per webapp developer decision. So, getFormattingLocale() has to be customizable. The two logical APIs here are: - setFormattingLocale() - EL: like readingDirection, use trinidad-config to set up EL that drives the formatting locale 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. Hints will have to be clever, that's true. Not sure I have a good solution for this. 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be in (UK) dd-MM-, and I am actually getting (US) MM-dd-, that could cause me to miss my flight. No, not the point of this: locale is en_UK, but formatting locale is en_US could mean an English website is showing dates to an American user. Unusual, not not illegal. Obviously, showing the wrong formats is a problem, or we wouldn't be having this discussion! I don't need to be reminded of that. :) -- Adam
Re: Re: Re: Formatting locale vs. translation locale
thanks adam useful hints as usual On 10/25/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, No, there isn't a conflict. Code looking for translations will all use UIViewRoot.getLocale(). BTW, for reading direction, we already have a RequestContext getReadingDirection() that can be overridden using trinidad-config.xml. -- Adam On 10/24/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi Adam, let me clear that I think separating Formatting locale and translation locale is a very good idea. there are lots of methods in JSF to get current locale, my point is to make sure these methods don't return some thing in conflict with each other. for example we must make sure the other components on the page you mentioned are not searching for German translation of texts. the same concept can also be extended to direction, users whose language is written from right to left like Hebrew, Arabic and Farsi may prefer their menu, trees, tabs, etc to be right aligned, and behave how they expect even if the text is still in English. for example scroll bars in left side is common in right to left languages, and if your browser has put one scroll bar in left, and a JSF page displayed in the browser has put scroll bar in right side of the page it becomes very confusing. On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates out-of-the-box. I'm leaning towards #1, because it doesn't change any existing behavior, and even if we implement #1, and application developer can still choose to make an application behave like #2. But #2 is more like how I'd want my applications to behave... -- Adam On 10/23/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Arash Rajaeeyan -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: Re: Formatting locale vs. translation locale
I like #2 because: 1. no new public apis. 2. correct behaviour out-of-the-box 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. --arjuna On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates out-of-the-box. I'm leaning towards #1, because it doesn't change any existing behavior, and even if we implement #1, and application developer can still choose to make an application behave like #2. But #2 is more like how I'd want my applications to behave... -- Adam On 10/23/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Arash Rajaeeyan
Re: Re: Re: Formatting locale vs. translation locale
Arj, On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. -- Adam --arjuna On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates out-of-the-box. I'm leaning towards #1, because it doesn't change any existing behavior, and even if we implement #1, and application developer can still choose to make an application behave like #2. But #2 is more like how I'd want my applications to behave... -- Adam On 10/23/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Arash Rajaeeyan
Re: Re: Re: Formatting locale vs. translation locale
On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be in (UK) dd-MM-, and I am actually getting (US) MM-dd-, that could cause me to miss my flight. --arjuna -- Adam --arjuna On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates out-of-the-box. I'm leaning towards #1, because it doesn't change any existing behavior, and even if we implement #1, and application developer can still choose to make an application behave like #2. But #2 is more like how I'd want my applications to behave... -- Adam On 10/23/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Arash Rajaeeyan
Re: Formatting locale vs. translation locale
Arjuna Wijeyekoon wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. That's a very good point. If they only have US translations, the help uses US formatting, now we come along and actually use UK formatting, so the help is wrong. That does seem like a major problem for #2. Could we have a config setting to switch on #2, because I think #2 is very useful, but maybe they need to buy in, it's still a much less painful buy in than they have now with the converter 'locale' attribute Thanks, Gab 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be in (UK) dd-MM-, and I am actually getting (US) MM-dd-, that could cause me to miss my flight. --arjuna -- Adam --arjuna On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates out-of-the-box. I'm leaning towards #1, because it doesn't change any existing behavior, and even if we implement #1, and application developer can still choose to make an application behave like #2. But #2 is more like how I'd want my applications to behave... -- Adam On 10/23/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad
Re: Formatting locale vs. translation locale
I believe that #1 is what we should do. If you do #2, then the locale will be changed away from what the view-root offers (and which might be derived from the accept-header of the request, so you have the possibility to implement #2) somehow automagically - without the developer really knowing. - First (that's the same issue as you had) - existing applications behave differently. - Second - also as a user, I'm expecting US-date format when I'm looking at an application I18nized in en-US. If you give me German date formats, you'll need to indicate this clearly, and that's something a developer has to do manually and consciously (except Trinidad has some automatic way of indicating date, time and number-format to the user). So as a German-speaking user, this is not the way I'd want the application to behave automatically. regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Arjuna Wijeyekoon wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. That's a very good point. If they only have US translations, the help uses US formatting, now we come along and actually use UK formatting, so the help is wrong. That does seem like a major problem for #2. Could we have a config setting to switch on #2, because I think #2 is very useful, but maybe they need to buy in, it's still a much less painful buy in than they have now with the converter 'locale' attribute Thanks, Gab 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be in (UK) dd-MM-, and I am actually getting (US) MM-dd-, that could cause me to miss my flight. --arjuna -- Adam --arjuna On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates out-of-the-box. I'm leaning towards #1, because it doesn't change any existing behavior, and even if we implement #1, and application developer can still choose to make an application behave like #2. But #2 is more like how I'd want my applications to behave... -- Adam On 10/23/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL
Re: Formatting locale vs. translation locale
Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Arash Rajaeeyan
Re: Formatting locale vs. translation locale
+1 for the FormatingLocale(); you mean facesCtx.getViewRoot().getLocale() right? that's what the Trin Number/DateTime currently use when locale not set. -M On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Re: Formatting locale vs. translation locale
Yep, that's the idea. -- Adam On 10/23/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: +1 for a formatting locale. If I'm understanding you correctly the formatting locale would only be used for formatting, meaning 11-7-06 in the US and 7-11-06 in Germany, but the error string will still use the regular locale... Thanks, Gab Adam Winer wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam
Re: Re: Formatting locale vs. translation locale
Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates out-of-the-box. I'm leaning towards #1, because it doesn't change any existing behavior, and even if we implement #1, and application developer can still choose to make an application behave like #2. But #2 is more like how I'd want my applications to behave... -- Adam On 10/23/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi adam I have some experience of using ADF in countries which English is not primary language and their software needed to support more than one language at the same time. having a RequestContext.getFormattingLocale() looks like a nice idea to me, and it makes it easier to add internationalization and support for different locales to components. I think t is much better that components act intelligently according to their users clients. it would be great if you could be sure this is no conflict with method: abstract java.util.Locale calculateLocale( javax.faces.context.FacesContext context) in following class of 1.1 API: javax.faces.application.ViewHandler On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: JSF currently has support for one Locale, off of FacesContext.getLocale(). It's also possible to override the locale on a per-converter basis by explicitly setting the locale attribute on various converters. This is useful for cases when you have, for example, only translations into a limited set of languages (for example, just American English), but need to show users dates formatted in the user's locale so there is no accidental misinterpretation of dates (e.g., British English or German). I've gotten some internal requirements for using this functionality, but setting it on every single converter gets to be painful. To make this easier, I'd like to expose a new Locale on RequestContext: Locale RequestContext.getFormattingLocale() void RequestContext.setFormattingLocale(Locale locale) ... and have the DateTimeConverter and NumberConverter overrides that Trinidad supplies automatically default to the formatting locale if it is set to a non-null value. Comments? -- Adam -- Arash Rajaeeyan
