From naoto.sato at oracle.com Fri Dec 10 10:36:32 2010 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 10 Dec 2010 10:36:32 -0800 Subject: [loc-en-dev] he/iw issue Message-ID: <4D027330.9030201@oracle.com> Hi, I cannot seem to remember why we dropped he/iw lookup in ResourceBundle. The design notes (http://sites.google.com/site/openjdklocale/design-notes/resource-bundle-lookup-order) just mentions: Note: Special Case 1 is removed. If someone really need resources to be tagged by he/yi/id, he/she should use ResourceBundle.Control to control the behavior. What was the reason we dropped this? It seems to me it is asking too much for applications to provide a custom ResourceBundle.Control for the legit ISO639 language codes. Naoto From y.umaoka at gmail.com Fri Dec 10 11:22:41 2010 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Fri, 10 Dec 2010 14:22:41 -0500 Subject: [loc-en-dev] he/iw issue In-Reply-To: <4D027330.9030201@oracle.com> References: <4D027330.9030201@oracle.com> Message-ID: <4D027E01.8040301@gmail.com> On 12/10/2010 1:36 PM, Naoto Sato wrote: > Hi, > > I cannot seem to remember why we dropped he/iw lookup in > ResourceBundle. The design notes > (http://sites.google.com/site/openjdklocale/design-notes/resource-bundle-lookup-order) > just mentions: > > Note: Special Case 1 is removed. If someone really need resources to > be tagged by he/yi/id, he/she should use ResourceBundle.Control to > control the behavior. > > What was the reason we dropped this? It seems to me it is asking too > much for applications to provide a custom ResourceBundle.Control for > the legit ISO639 language codes. > > Naoto > Several reasons. Unlike other special cases, there is no way to create a locale with language code "he"/"yi"/"id". Therefore, you cannot represent them in the candidate Locale list used by resource bundle. It is still possible to look for both _he and _iw with a candidate Locale iw, but we did not see much value with this implementation - what we get with this is just allowing people to use either he or iw, while the downside is additional cost to look up these variants. -Yoshito From naoto.sato at oracle.com Fri Dec 10 11:31:36 2010 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 10 Dec 2010 11:31:36 -0800 Subject: [loc-en-dev] he/iw issue In-Reply-To: <4D027E01.8040301@gmail.com> References: <4D027330.9030201@oracle.com> <4D027E01.8040301@gmail.com> Message-ID: <4D028018.9000107@oracle.com> > what we get with this is just allowing people to use either he or iw Well, I see this is important enough as: - he is important as it's the ISO code for Hebrew. - iw is important for compatibility. I think supporting both would overcome the lookup cost (and it can be limited only to he/iw etc.). Again, asking apps to provide a custom Control for legit codes sounds too much. Naoto (12/10/10 11:22 AM), Yoshito Umaoka wrote: > On 12/10/2010 1:36 PM, Naoto Sato wrote: >> Hi, >> >> I cannot seem to remember why we dropped he/iw lookup in >> ResourceBundle. The design notes >> (http://sites.google.com/site/openjdklocale/design-notes/resource-bundle-lookup-order) >> just mentions: >> >> Note: Special Case 1 is removed. If someone really need resources to >> be tagged by he/yi/id, he/she should use ResourceBundle.Control to >> control the behavior. >> >> What was the reason we dropped this? It seems to me it is asking too >> much for applications to provide a custom ResourceBundle.Control for >> the legit ISO639 language codes. >> >> Naoto >> > > Several reasons. Unlike other special cases, there is no way to create a > locale with language code "he"/"yi"/"id". Therefore, you cannot > represent them in the candidate Locale list used by resource bundle. It > is still possible to look for both _he and _iw with a candidate Locale > iw, but we did not see much value with this implementation - what we get > with this is just allowing people to use either he or iw, while the > downside is additional cost to look up these variants. > > -Yoshito From y.umaoka at gmail.com Fri Dec 10 11:42:46 2010 From: y.umaoka at gmail.com (Yoshito Umaoka) Date: Fri, 10 Dec 2010 14:42:46 -0500 Subject: [loc-en-dev] he/iw issue In-Reply-To: <4D028018.9000107@oracle.com> References: <4D027330.9030201@oracle.com> <4D027E01.8040301@gmail.com> <4D028018.9000107@oracle.com> Message-ID: <4D0282B6.8090509@gmail.com> On 12/10/2010 2:31 PM, Naoto Sato wrote: > > what we get with this is just allowing people to use either he or iw > > Well, I see this is important enough as: > > - he is important as it's the ISO code for Hebrew. I'm not convinced much about this. In Java, people had to use suffix _iw for Hebrew bundles - I do not think support _he in addition to _iw make people happy. > - iw is important for compatibility. > > I think supporting both would overcome the lookup cost (and it can be > limited only to he/iw etc.). Again, asking apps to provide a custom > Control for legit codes sounds too much. > I think this is one of area which we may want to look into. ResourceBundle.Control is powerful, but specifying custom Control implementation everywhere is usually not acceptable. I think the right solution is to allow user to "set" default control. -Yoshito From naoto.sato at oracle.com Fri Dec 10 11:55:32 2010 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 10 Dec 2010 11:55:32 -0800 Subject: [loc-en-dev] he/iw issue In-Reply-To: <4D0282B6.8090509@gmail.com> References: <4D027330.9030201@oracle.com> <4D027E01.8040301@gmail.com> <4D028018.9000107@oracle.com> <4D0282B6.8090509@gmail.com> Message-ID: <4D0285B4.70006@oracle.com> (12/10/10 11:42 AM), Yoshito Umaoka wrote: > On 12/10/2010 2:31 PM, Naoto Sato wrote: >> > what we get with this is just allowing people to use either he or iw >> >> Well, I see this is important enough as: >> >> - he is important as it's the ISO code for Hebrew. > > I'm not convinced much about this. In Java, people had to use suffix _iw > for Hebrew bundles - I do not think support _he in addition to _iw make > people happy. That does not justify what we should be doing. In fact, we've received dozen requests (including web bug votes) for this. > >> - iw is important for compatibility. >> >> I think supporting both would overcome the lookup cost (and it can be >> limited only to he/iw etc.). Again, asking apps to provide a custom >> Control for legit codes sounds too much. >> > I think this is one of area which we may want to look into. > ResourceBundle.Control is powerful, but specifying custom Control > implementation everywhere is usually not acceptable. I think the right > solution is to allow user to "set" default control. Yes, that's worth looking into in the future release. Naoto