You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"VI" is the ISO_3166-2 code for US Virgin Islands source
"VN" is the ISO_3166-2 code for Vietnam source
In this gem the region code "VI" is used for Vietnam, and the code "VN" is not used. Looking through the documentation, I couldn't find a decision to follow the ISO 3166-1 alpha-2 standard, but I couldn't find any decision not to either - I haven't actually found any definition of the country codes as such. But looking at them in practice they seem to mostly follow the ISO 3166-1 alpha-2 standard anyway, which can easily lead someone (i.e. me) to wrongly assume that it is the intention, and run into trouble when cross-referencing with other sources of information. As such I would argue that almost following the standard is worse than breaking with it completely.
I would suggest that a decision be made to either follow the standard or not - and document the decision in either case. And then either change vi.yaml to vn.yaml, or add a warning that this is purposely not following the ISO standard, maybe document the cases in which it has chosen to diverge.
The text was updated successfully, but these errors were encountered:
"VI" is the ISO_3166-2 code for US Virgin Islands source
"VN" is the ISO_3166-2 code for Vietnam source
In this gem the region code "VI" is used for Vietnam, and the code "VN" is not used. Looking through the documentation, I couldn't find a decision to follow the ISO 3166-1 alpha-2 standard, but I couldn't find any decision not to either - I haven't actually found any definition of the country codes as such. But looking at them in practice they seem to mostly follow the ISO 3166-1 alpha-2 standard anyway, which can easily lead someone (i.e. me) to wrongly assume that it is the intention, and run into trouble when cross-referencing with other sources of information. As such I would argue that almost following the standard is worse than breaking with it completely.
I would suggest that a decision be made to either follow the standard or not - and document the decision in either case. And then either change vi.yaml to vn.yaml, or add a warning that this is purposely not following the ISO standard, maybe document the cases in which it has chosen to diverge.
The text was updated successfully, but these errors were encountered: