You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Roland Kreuzer (Jira)" <ji...@apache.org> on 2021/11/07 10:39:00 UTC

[jira] [Comment Edited] (LANG-1172) LocaleUtils.toLocale does not handle extensions

    [ https://issues.apache.org/jira/browse/LANG-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439964#comment-17439964 ] 

Roland Kreuzer edited comment on LANG-1172 at 11/7/21, 10:38 AM:
-----------------------------------------------------------------

Some thoughts:

A valid BCP47 locale as described in the sample can be parsed using the JDKs own

[https://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#forLanguageTag(java.lang.String)]

The Javadoc of LocaleUtils#toLocale already references this option which would suggest handling the BCP47 format could be intentionally out-of-scope in favor for the more strict parsing behavior currently documented and applied.

A code comment also references LANG-879 saying "Cannot handle Java 7 script & extensions".

 

Over in Spring Framework's StringUtils there are two separate methods: one only Parsing Locale#toString and one accepting both Locale#toString and Locale#toLanguageTag. So maybe there is a valid use-case to accept both? However, looking at the implementation it is basically every input that does contain neither underscores nor spaces is handed over to Locale#forLanguageTag as well.

 

Maybe this could be an approach for Lang as well, as when adding script and extension tags it is no longer as simple as threating underscores and hyphens as equivalent. For example Java Locale {{zh_CN_#Hans}} is equivalent to BCP47 zh-Hans-CN


was (Author: rolandkreuzer):
Some thoughts:

A valid BCP47 locale as describted in the sample can be parsed using the JDKs own

[https://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#forLanguageTag(java.lang.String)]

The Javadoc of LocaleUtils#toLocale already references this option which would suggest handling the BCP47 format could be intentionally out-of-scope in favor for the more strict parsing behavior currently documented and applied.

A code comment also references LANG-879 saying "Cannot handle Java 7 script & extensions".

 

Over in Spring Framework's StringUtils there are two separate methods: one only Parsing Locale#toString and one accepting both Locale#toString and Locale#toLanguageTag. So maybe there is a valid use-case to accept both? However, looking at the implementation it is basically every input that does contain neither underscores nor spaces is handed over to Locale#forLanguageTag as well.

 

Maybe this could be an approach for Lang as well, as when adding script and extension tags it is no longer as simple as threating underscores and hyphens as equivalent. For example Java Locale {{zh_CN_#Hans}} is equivalent to BCP47 zh-Hans-CN

> LocaleUtils.toLocale does not handle extensions
> -----------------------------------------------
>
>                 Key: LANG-1172
>                 URL: https://issues.apache.org/jira/browse/LANG-1172
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: David Buhler
>            Priority: Major
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> The {{toLocale()}} method is unable to handle locale strings that have custom extensions that are completely valid according to the [BCP47 spec|https://tools.ietf.org/html/bcp47#section-4]. Oracle documentation for sub tag extensions can be [found here|https://docs.oracle.com/javase/tutorial/i18n/locale/extensions.html].
> An example locale string with a custom extension might be {{fr-CA-x-nb}}.
> This issue seems to have been introduced with ticket LANG-915.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)