ppkarwasz commented on PR #1460:
URL: https://github.com/apache/commons-lang/pull/1460#issuecomment-3382756912
@jack5505,
Thanks for this contribution! Before looking at the details, I’d like to
understand your use case a bit better. Are you trying to construct `Locale`
objects from ISO 3166-1 numeric codes, or do you need a general-purpose
conversion utility between different ISO country code formats? That context
would help evaluate whether this belongs in `LocaleUtils`.
A few observations from my side:
1. **Scope of `Locale` support**
* Java’s `Locale` supports only ISO 3166-1 **alpha-2** codes for regions,
or UN M.49 **numeric** codes for macro-regions.
* ISO 3166-1 **alpha-3** and **numeric** country codes are *not* valid
BCP 47 region subtags and therefore cannot be used directly in `Locale`.
* This makes me question whether mapping alpha-2 <-> numeric belongs in
`LocaleUtils`, which is focused on `Locale`-compatible operations.
2. **Comparison with existing APIs**
* The proposed `toNumeric()` method could be seen as complementing
`Locale#getISO3Country()` and `Locale#getISO3Language()`, which already expose
ISO 3166-1 alpha-3 and ISO 639-2/3 codes.
* However, these JDK methods appear to have very limited real-world
usage. A scan across GitHub shows they are used mainly in thin wrappers or
helper utilities that simply re-expose the same functionality, rather than
being called directly in application logic ([example
search](https://github.com/search?q=lang%3AJava++getISO3Country&type=code)).
* This lack of adoption suggests that demand for alpha-3 or numeric
conversions is limited, and raises the question of whether Commons Lang is the
right place to add this functionality.
4. **Completeness of this PR**
* Right now the PR only covers alpha-2 <-> numeric. If the goal is to
provide a general conversion utility, then it feels incomplete without alpha-2
<-> alpha-3, and possibly alpha-3 <-> numeric mappings.
* Without the full picture, the API may be confusing or misleading to
users who expect all three forms to be supported.
5. **Data maintenance**
* The codes are currently hard-coded. That raises a long-term
maintenance issue: ISO and UN occasionally update codes.
* A more robust approach would be to **generate the mapping** from
CLDR’s `supplementalData.xml` (where `codeMappings` contains
alpha-2/alpha-3/numeric relationships). This is how the JDK itself sources its
locale data, ensuring alignment with Unicode/CLDR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
