feat(isISO6391): add ISO 639-1 validator

[braaar]

This PR adds a validator which validates ISO 639-1 languages codes, such as 'af', 'nb' and 'fr'.

I would like this feature because ISO 639-1 seems to be the most commonly used set of language codes when referring solely to a language and not a locale, and I will be using them for an upcoming project which uses validator.js.

This PR is essentially a cleaned up version of a previous PR which I suspect was closed partially due to the lack of cleanup: #1103.

Thanks to @ezkemboi and @profnandaa for their contributions in earlier PRs and issues.

My contribution is the cleanup of the diff as well as rewritten test code and readme entry.

See related issue: #989

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)

[codecov]

Codecov Report

Merging #1892 (ae32fd5) into master (f055c11) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1892 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 102 103 +1 Lines 2072 2078 +6 Branches 472 472 =========================================
+ Hits 2072 2078 +6 

Impacted Files	Coverage Δ
src/index.js	100.00% <100.00%> (ø)
src/lib/isISO6391.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f055c11...ae32fd5. Read the comment docs.

[braaar]

I understand the desire to stick to regex based validation, but ISO will never update this spec with breaking changes, as far as I understand it. This specific version of ISO 639 is not likely to be updated ever again. It was last updated in 2002 and has since been reviewed three times without changes.

[braaar]

I cleaned up the list of language codes so it's easier on the eyes, like the list in the ISO3166 validator

[WikiRik]

Yeah, I expect limited changes (and if they occur only in additions) and doing regex based validation is not realistic for this one. Looks good to me

[braaar]

I suppose a more complete implementation of this could be isISO639(str, versions) where you can specify which versions of ISO639 you wish to validate against (perhaps just 1 through 5, since version 6 was withdrawn).

The default behaviour without any options specified should match any of the 5 official and current versions of the standard.

Here's how I would implement that:

// declare 5 different sets with all the language codes in themconstsets=[isISO6391Set,isISO6392Set,isISO6393Set,isISO6394Set,isISO6395Set];exportdefaultfunctionisISO639(str,versions=[1,2,3,4,5]){assertString(str);returnversions.reduce((result,version)=>{constcurrentSet=sets[version-1];returncurrentSet.has(str)||result;},false);}

[WikiRik]

That would be a more complete implementation, but I'm not sure how often that would be used. Especially with the large number of supported languages for ISO 639-3, it might be too much for this project.
Also, I am not sure if the default for matching any of the 5 would be smart for false positives. But I would like to hear the opinions of @profnandaa and @ezkemboi about this

[rhenandias]

I came looking for this feature today, any updates regarding this functionality?

I agree with the option to specify the version via an options parameter, however, I would set the default version to 1. For now the default set in commit works for me.

[profnandaa]

No objection from me. LGTM, thanks for your contrib 🎉

// Sorry for the delay in reviewing this.

[braaar]

This PR adds a validator which validates ISO 639-1 languages codes, such as 'af', 'nb' and 'fr'.

I would like this feature because ISO 639-1 seems to be the most commonly used set of language codes when referring solely to a language and not a locale, and I will be using them for an upcoming project which uses validator.js.

This PR is essentially a cleaned up version of a previous PR which I suspect was closed partially due to the lack of cleanup: #1103.

Thanks to @ezkemboi and @profnandaa for their contributions in earlier PRs and issues.

My contribution is the cleanup of the diff as well as rewritten test code and readme entry.

See related issue: #989

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)

[codecov]

Codecov Report

Merging #1892 (ae32fd5) into master (f055c11) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1892 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 102 103 +1 Lines 2072 2078 +6 Branches 472 472 =========================================
+ Hits 2072 2078 +6 

Impacted Files	Coverage Δ
src/index.js	100.00% <100.00%> (ø)
src/lib/isISO6391.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f055c11...ae32fd5. Read the comment docs.

[braaar]

I understand the desire to stick to regex based validation, but ISO will never update this spec with breaking changes, as far as I understand it. This specific version of ISO 639 is not likely to be updated ever again. It was last updated in 2002 and has since been reviewed three times without changes.

[braaar]

I cleaned up the list of language codes so it's easier on the eyes, like the list in the ISO3166 validator

[WikiRik]

Yeah, I expect limited changes (and if they occur only in additions) and doing regex based validation is not realistic for this one. Looks good to me

[braaar]

I suppose a more complete implementation of this could be isISO639(str, versions) where you can specify which versions of ISO639 you wish to validate against (perhaps just 1 through 5, since version 6 was withdrawn).

The default behaviour without any options specified should match any of the 5 official and current versions of the standard.

Here's how I would implement that:

// declare 5 different sets with all the language codes in themconstsets=[isISO6391Set,isISO6392Set,isISO6393Set,isISO6394Set,isISO6395Set];exportdefaultfunctionisISO639(str,versions=[1,2,3,4,5]){assertString(str);returnversions.reduce((result,version)=>{constcurrentSet=sets[version-1];returncurrentSet.has(str)||result;},false);}

[WikiRik]

That would be a more complete implementation, but I'm not sure how often that would be used. Especially with the large number of supported languages for ISO 639-3, it might be too much for this project.
Also, I am not sure if the default for matching any of the 5 would be smart for false positives. But I would like to hear the opinions of @profnandaa and @ezkemboi about this

[rhenandias]

I came looking for this feature today, any updates regarding this functionality?

I agree with the option to specify the version via an options parameter, however, I would set the default version to 1. For now the default set in commit works for me.

[profnandaa]

No objection from me. LGTM, thanks for your contrib 🎉

// Sorry for the delay in reviewing this.

[braaar]

This PR adds a validator which validates ISO 639-1 languages codes, such as 'af', 'nb' and 'fr'.

I would like this feature because ISO 639-1 seems to be the most commonly used set of language codes when referring solely to a language and not a locale, and I will be using them for an upcoming project which uses validator.js.

This PR is essentially a cleaned up version of a previous PR which I suspect was closed partially due to the lack of cleanup: #1103.

Thanks to @ezkemboi and @profnandaa for their contributions in earlier PRs and issues.

My contribution is the cleanup of the diff as well as rewritten test code and readme entry.

See related issue: #989

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)

[codecov]

Codecov Report

Merging #1892 (ae32fd5) into master (f055c11) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1892 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 102 103 +1 Lines 2072 2078 +6 Branches 472 472 =========================================
+ Hits 2072 2078 +6 

Impacted Files	Coverage Δ
src/index.js	100.00% <100.00%> (ø)
src/lib/isISO6391.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f055c11...ae32fd5. Read the comment docs.

[braaar]

I understand the desire to stick to regex based validation, but ISO will never update this spec with breaking changes, as far as I understand it. This specific version of ISO 639 is not likely to be updated ever again. It was last updated in 2002 and has since been reviewed three times without changes.

[braaar]

I cleaned up the list of language codes so it's easier on the eyes, like the list in the ISO3166 validator

[WikiRik]

Yeah, I expect limited changes (and if they occur only in additions) and doing regex based validation is not realistic for this one. Looks good to me

[braaar]

I suppose a more complete implementation of this could be isISO639(str, versions) where you can specify which versions of ISO639 you wish to validate against (perhaps just 1 through 5, since version 6 was withdrawn).

The default behaviour without any options specified should match any of the 5 official and current versions of the standard.

Here's how I would implement that:

// declare 5 different sets with all the language codes in themconstsets=[isISO6391Set,isISO6392Set,isISO6393Set,isISO6394Set,isISO6395Set];exportdefaultfunctionisISO639(str,versions=[1,2,3,4,5]){assertString(str);returnversions.reduce((result,version)=>{constcurrentSet=sets[version-1];returncurrentSet.has(str)||result;},false);}

[WikiRik]

That would be a more complete implementation, but I'm not sure how often that would be used. Especially with the large number of supported languages for ISO 639-3, it might be too much for this project.
Also, I am not sure if the default for matching any of the 5 would be smart for false positives. But I would like to hear the opinions of @profnandaa and @ezkemboi about this

[rhenandias]

I came looking for this feature today, any updates regarding this functionality?

I agree with the option to specify the version via an options parameter, however, I would set the default version to 1. For now the default set in commit works for me.

[profnandaa]

No objection from me. LGTM, thanks for your contrib 🎉

// Sorry for the delay in reviewing this.

[braaar]

This PR adds a validator which validates ISO 639-1 languages codes, such as 'af', 'nb' and 'fr'.

I would like this feature because ISO 639-1 seems to be the most commonly used set of language codes when referring solely to a language and not a locale, and I will be using them for an upcoming project which uses validator.js.

This PR is essentially a cleaned up version of a previous PR which I suspect was closed partially due to the lack of cleanup: #1103.

Thanks to @ezkemboi and @profnandaa for their contributions in earlier PRs and issues.

My contribution is the cleanup of the diff as well as rewritten test code and readme entry.

See related issue: #989

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)

[codecov]

Codecov Report

Merging #1892 (ae32fd5) into master (f055c11) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1892 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 102 103 +1 Lines 2072 2078 +6 Branches 472 472 =========================================
+ Hits 2072 2078 +6 

Impacted Files	Coverage Δ
src/index.js	100.00% <100.00%> (ø)
src/lib/isISO6391.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f055c11...ae32fd5. Read the comment docs.

[braaar]

I understand the desire to stick to regex based validation, but ISO will never update this spec with breaking changes, as far as I understand it. This specific version of ISO 639 is not likely to be updated ever again. It was last updated in 2002 and has since been reviewed three times without changes.

[braaar]

I cleaned up the list of language codes so it's easier on the eyes, like the list in the ISO3166 validator

[WikiRik]

Yeah, I expect limited changes (and if they occur only in additions) and doing regex based validation is not realistic for this one. Looks good to me

[braaar]

I suppose a more complete implementation of this could be isISO639(str, versions) where you can specify which versions of ISO639 you wish to validate against (perhaps just 1 through 5, since version 6 was withdrawn).

The default behaviour without any options specified should match any of the 5 official and current versions of the standard.

Here's how I would implement that:

// declare 5 different sets with all the language codes in themconstsets=[isISO6391Set,isISO6392Set,isISO6393Set,isISO6394Set,isISO6395Set];exportdefaultfunctionisISO639(str,versions=[1,2,3,4,5]){assertString(str);returnversions.reduce((result,version)=>{constcurrentSet=sets[version-1];returncurrentSet.has(str)||result;},false);}

[WikiRik]

That would be a more complete implementation, but I'm not sure how often that would be used. Especially with the large number of supported languages for ISO 639-3, it might be too much for this project.
Also, I am not sure if the default for matching any of the 5 would be smart for false positives. But I would like to hear the opinions of @profnandaa and @ezkemboi about this

[rhenandias]

I came looking for this feature today, any updates regarding this functionality?

I agree with the option to specify the version via an options parameter, however, I would set the default version to 1. For now the default set in commit works for me.

[profnandaa]

No objection from me. LGTM, thanks for your contrib 🎉

// Sorry for the delay in reviewing this.

[braaar]

This PR adds a validator which validates ISO 639-1 languages codes, such as 'af', 'nb' and 'fr'.

I would like this feature because ISO 639-1 seems to be the most commonly used set of language codes when referring solely to a language and not a locale, and I will be using them for an upcoming project which uses validator.js.

This PR is essentially a cleaned up version of a previous PR which I suspect was closed partially due to the lack of cleanup: #1103.

Thanks to @ezkemboi and @profnandaa for their contributions in earlier PRs and issues.

My contribution is the cleanup of the diff as well as rewritten test code and readme entry.

See related issue: #989

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)

[codecov]

Codecov Report

Merging #1892 (ae32fd5) into master (f055c11) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1892 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 102 103 +1 Lines 2072 2078 +6 Branches 472 472 =========================================
+ Hits 2072 2078 +6 

Impacted Files	Coverage Δ
src/index.js	100.00% <100.00%> (ø)
src/lib/isISO6391.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f055c11...ae32fd5. Read the comment docs.

[braaar]

I understand the desire to stick to regex based validation, but ISO will never update this spec with breaking changes, as far as I understand it. This specific version of ISO 639 is not likely to be updated ever again. It was last updated in 2002 and has since been reviewed three times without changes.

[braaar]

I cleaned up the list of language codes so it's easier on the eyes, like the list in the ISO3166 validator

[WikiRik]

Yeah, I expect limited changes (and if they occur only in additions) and doing regex based validation is not realistic for this one. Looks good to me

[braaar]

I suppose a more complete implementation of this could be isISO639(str, versions) where you can specify which versions of ISO639 you wish to validate against (perhaps just 1 through 5, since version 6 was withdrawn).

The default behaviour without any options specified should match any of the 5 official and current versions of the standard.

Here's how I would implement that:

// declare 5 different sets with all the language codes in themconstsets=[isISO6391Set,isISO6392Set,isISO6393Set,isISO6394Set,isISO6395Set];exportdefaultfunctionisISO639(str,versions=[1,2,3,4,5]){assertString(str);returnversions.reduce((result,version)=>{constcurrentSet=sets[version-1];returncurrentSet.has(str)||result;},false);}

[WikiRik]

That would be a more complete implementation, but I'm not sure how often that would be used. Especially with the large number of supported languages for ISO 639-3, it might be too much for this project.
Also, I am not sure if the default for matching any of the 5 would be smart for false positives. But I would like to hear the opinions of @profnandaa and @ezkemboi about this

[rhenandias]

I came looking for this feature today, any updates regarding this functionality?

I agree with the option to specify the version via an options parameter, however, I would set the default version to 1. For now the default set in commit works for me.

[profnandaa]

No objection from me. LGTM, thanks for your contrib 🎉

// Sorry for the delay in reviewing this.

[braaar]

This PR adds a validator which validates ISO 639-1 languages codes, such as 'af', 'nb' and 'fr'.

I would like this feature because ISO 639-1 seems to be the most commonly used set of language codes when referring solely to a language and not a locale, and I will be using them for an upcoming project which uses validator.js.

This PR is essentially a cleaned up version of a previous PR which I suspect was closed partially due to the lack of cleanup: #1103.

Thanks to @ezkemboi and @profnandaa for their contributions in earlier PRs and issues.

My contribution is the cleanup of the diff as well as rewritten test code and readme entry.

See related issue: #989

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)

[codecov]

Codecov Report

Merging #1892 (ae32fd5) into master (f055c11) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1892 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 102 103 +1 Lines 2072 2078 +6 Branches 472 472 =========================================
+ Hits 2072 2078 +6 

Impacted Files	Coverage Δ
src/index.js	100.00% <100.00%> (ø)
src/lib/isISO6391.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f055c11...ae32fd5. Read the comment docs.

[braaar]

I understand the desire to stick to regex based validation, but ISO will never update this spec with breaking changes, as far as I understand it. This specific version of ISO 639 is not likely to be updated ever again. It was last updated in 2002 and has since been reviewed three times without changes.

[braaar]

I cleaned up the list of language codes so it's easier on the eyes, like the list in the ISO3166 validator

[WikiRik]

Yeah, I expect limited changes (and if they occur only in additions) and doing regex based validation is not realistic for this one. Looks good to me

[braaar]

I suppose a more complete implementation of this could be isISO639(str, versions) where you can specify which versions of ISO639 you wish to validate against (perhaps just 1 through 5, since version 6 was withdrawn).

The default behaviour without any options specified should match any of the 5 official and current versions of the standard.

Here's how I would implement that:

// declare 5 different sets with all the language codes in themconstsets=[isISO6391Set,isISO6392Set,isISO6393Set,isISO6394Set,isISO6395Set];exportdefaultfunctionisISO639(str,versions=[1,2,3,4,5]){assertString(str);returnversions.reduce((result,version)=>{constcurrentSet=sets[version-1];returncurrentSet.has(str)||result;},false);}

[WikiRik]

That would be a more complete implementation, but I'm not sure how often that would be used. Especially with the large number of supported languages for ISO 639-3, it might be too much for this project.
Also, I am not sure if the default for matching any of the 5 would be smart for false positives. But I would like to hear the opinions of @profnandaa and @ezkemboi about this

[rhenandias]

I came looking for this feature today, any updates regarding this functionality?

I agree with the option to specify the version via an options parameter, however, I would set the default version to 1. For now the default set in commit works for me.

[profnandaa]

No objection from me. LGTM, thanks for your contrib 🎉

// Sorry for the delay in reviewing this.

[braaar]

This PR adds a validator which validates ISO 639-1 languages codes, such as 'af', 'nb' and 'fr'.

I would like this feature because ISO 639-1 seems to be the most commonly used set of language codes when referring solely to a language and not a locale, and I will be using them for an upcoming project which uses validator.js.

This PR is essentially a cleaned up version of a previous PR which I suspect was closed partially due to the lack of cleanup: #1103.

Thanks to @ezkemboi and @profnandaa for their contributions in earlier PRs and issues.

My contribution is the cleanup of the diff as well as rewritten test code and readme entry.

See related issue: #989

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)

[codecov]

Codecov Report

Merging #1892 (ae32fd5) into master (f055c11) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1892 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 102 103 +1 Lines 2072 2078 +6 Branches 472 472 =========================================
+ Hits 2072 2078 +6 

Impacted Files	Coverage Δ
src/index.js	100.00% <100.00%> (ø)
src/lib/isISO6391.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f055c11...ae32fd5. Read the comment docs.

[braaar]

I understand the desire to stick to regex based validation, but ISO will never update this spec with breaking changes, as far as I understand it. This specific version of ISO 639 is not likely to be updated ever again. It was last updated in 2002 and has since been reviewed three times without changes.

[braaar]

I cleaned up the list of language codes so it's easier on the eyes, like the list in the ISO3166 validator

[WikiRik]

Yeah, I expect limited changes (and if they occur only in additions) and doing regex based validation is not realistic for this one. Looks good to me

[braaar]

I suppose a more complete implementation of this could be isISO639(str, versions) where you can specify which versions of ISO639 you wish to validate against (perhaps just 1 through 5, since version 6 was withdrawn).

The default behaviour without any options specified should match any of the 5 official and current versions of the standard.

Here's how I would implement that:

// declare 5 different sets with all the language codes in themconstsets=[isISO6391Set,isISO6392Set,isISO6393Set,isISO6394Set,isISO6395Set];exportdefaultfunctionisISO639(str,versions=[1,2,3,4,5]){assertString(str);returnversions.reduce((result,version)=>{constcurrentSet=sets[version-1];returncurrentSet.has(str)||result;},false);}

[WikiRik]

That would be a more complete implementation, but I'm not sure how often that would be used. Especially with the large number of supported languages for ISO 639-3, it might be too much for this project.
Also, I am not sure if the default for matching any of the 5 would be smart for false positives. But I would like to hear the opinions of @profnandaa and @ezkemboi about this

[rhenandias]

I came looking for this feature today, any updates regarding this functionality?

I agree with the option to specify the version via an options parameter, however, I would set the default version to 1. For now the default set in commit works for me.

[profnandaa]

No objection from me. LGTM, thanks for your contrib 🎉

// Sorry for the delay in reviewing this.

[braaar]

This PR adds a validator which validates ISO 639-1 languages codes, such as 'af', 'nb' and 'fr'.

I would like this feature because ISO 639-1 seems to be the most commonly used set of language codes when referring solely to a language and not a locale, and I will be using them for an upcoming project which uses validator.js.

This PR is essentially a cleaned up version of a previous PR which I suspect was closed partially due to the lack of cleanup: #1103.

Thanks to @ezkemboi and @profnandaa for their contributions in earlier PRs and issues.

My contribution is the cleanup of the diff as well as rewritten test code and readme entry.

See related issue: #989

Checklist

• PR contains only changes related; no stray files, etc.
• README updated (where applicable)
• Tests written (where applicable)

[codecov]

Codecov Report

Merging #1892 (ae32fd5) into master (f055c11) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## master #1892 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 102 103 +1 Lines 2072 2078 +6 Branches 472 472 =========================================
+ Hits 2072 2078 +6 

Impacted Files	Coverage Δ
src/index.js	100.00% <100.00%> (ø)
src/lib/isISO6391.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f055c11...ae32fd5. Read the comment docs.

[braaar]

I understand the desire to stick to regex based validation, but ISO will never update this spec with breaking changes, as far as I understand it. This specific version of ISO 639 is not likely to be updated ever again. It was last updated in 2002 and has since been reviewed three times without changes.

[braaar]

I cleaned up the list of language codes so it's easier on the eyes, like the list in the ISO3166 validator

[WikiRik]

Yeah, I expect limited changes (and if they occur only in additions) and doing regex based validation is not realistic for this one. Looks good to me

[braaar]

I suppose a more complete implementation of this could be isISO639(str, versions) where you can specify which versions of ISO639 you wish to validate against (perhaps just 1 through 5, since version 6 was withdrawn).

The default behaviour without any options specified should match any of the 5 official and current versions of the standard.

Here's how I would implement that:

// declare 5 different sets with all the language codes in themconstsets=[isISO6391Set,isISO6392Set,isISO6393Set,isISO6394Set,isISO6395Set];exportdefaultfunctionisISO639(str,versions=[1,2,3,4,5]){assertString(str);returnversions.reduce((result,version)=>{constcurrentSet=sets[version-1];returncurrentSet.has(str)||result;},false);}

[WikiRik]

That would be a more complete implementation, but I'm not sure how often that would be used. Especially with the large number of supported languages for ISO 639-3, it might be too much for this project.
Also, I am not sure if the default for matching any of the 5 would be smart for false positives. But I would like to hear the opinions of @profnandaa and @ezkemboi about this

[rhenandias]

I came looking for this feature today, any updates regarding this functionality?

I agree with the option to specify the version via an options parameter, however, I would set the default version to 1. For now the default set in commit works for me.

[profnandaa]

No objection from me. LGTM, thanks for your contrib 🎉

// Sorry for the delay in reviewing this.