Partially revert LANG-1172.

[seadbrane]

The changes for LANG-1172 changed the allowed input and expectations of LocaleUtils.toLocale to now also support strings which include '-'. This change reverts that behavior, but leaves support for it through a protected method.

[garydgregory]

@seadbrane
Why?
FTR https://issues.apache.org/jira/projects/LANG/issues/LANG-1172
CC: @c-w

[seadbrane]

@garydgregory Here is the earlier comment on made on the original pr.

#766 (comment)

Making this method to also support '-' changes the behavior, and now breaks code that were using it to disambiguate between locale strings and language tag strings. While I do think it would be useful to have a method to take either, that should be a new method in order to keep the behavior of this method consistent with the original intent

[seadbrane]

Any update? Also, I did not expect this to be the final revision - as I wasn't sure the preferred method signature for supporting strings with '-', which is why I left this as a protected method now.

Options:

1. Make the toLocale(String, boolean) method public
2. Expose a new method such as toLocaleLenient(String)

[seadbrane]

I can understand the reluctance to rolling this back, as I am sure there are now folks relying on the new behavior.
Although in addition to breaking the previous contract, the current behavior muddies the waters on the differences between locale and language tags, and I am concerned that more folks will now think of them and try to treat them as equivalent - which is not the case conceptually or from a string representation perspective.

[garydgregory]

Hi @seadbrane
If you want this issue to get more visibility, you should consider posting to the developer's mailing list https://commons.apache.org/mail-lists.html

[seadbrane]

Hi @garydgregory
I see you posted something on the email list already - thank you. I was not subscribed to the list at the time and looks like no responses- mind pinging the thread, or is it preferred to start a new one?

Related: The javadoc for this method had the following up through 3.12.0.

"This method validates the input strictly. The language code must be lowercase. The country code must be uppercase. The separator must be an underscore. The length must be correct. "

[garydgregory]

@seadbrane
Wow, it's been > 1 year here... Do you still need the old behavior? Do you think there is a need for a new method with strict validation of... what spec? The Jira ticket LANG-1172 mentions:

• https://tools.ietf.org/html/bcp47#section-4
• https://docs.oracle.com/javase/tutorial/i18n/locale/extensions.html

[seadbrane]

Yes, I think there is a need for the old behavior, although I think at this point introducing as a new method would be sufficient.

Support for the language tag format defined by the BCP47, which uses '-' (dash) as a separator, was added in LANG-1172. The old behavior was to not accept this format, and only accept locale strings where "The separator must be an underscore".

The format is part of the POSIX (IEEE Std 1003.1 / ISO/IEC 9945) Base Specifications.

language[_territory][.codeset]

https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html#tag_08_01_02