为了支持软件国际化，许多编程语言和平台都支持一种获取本地化资源的方法，以在向用户显示的 UI 中使用（例如 Java 的java.util.ResourceBundle类）。通常，如果用户首选语言环境的资源不可用，则有一个回退机制或语言环境解析过程，它将尝试从可用资源集中找到最近匹配的资源。例如，如果 的资源en-US不可用，则系统通常会尝试查找 的资源en。
对于许多语言和平台的资源包解决方案，区域设置解析过程似乎几乎相同。他们是否遵循一些标准的语言环境解析算法，或者，如果没有，是否存在这样的标准？
显然有RFC 4647，语言标签匹配，它描述了用于指定用户首选语言列表的“语言范围”的语法，以及用于比较和匹配语言范围的“过滤”和“查找”机制到 RFC 4646 语言标签。RFC 4647 将这些机制描述为：
过滤产生一组（可能是空的）语言标签，而查找产生一个单一的语言标签。
我不知道标准本身。
然而，所使用的算法是区域设置是分层的事实的一个微不足道的结果。有一个（名义上的）没有名称的根语言环境。下面是仅限语言的语言环境（en、fr 等）。在这些之下是国家语言环境（en_GB、en_US 等）。在这些之下，可选地是变体语言环境（en_GB_Yorkshire、en_GB_cockney 等 - 对于实际示例，请查看挪威）。
找到合适资源的自然方法是从最低、最具体的语言环境开始，然后沿着树向上走，直到找到一些东西。因此，从 en_US_TX 开始，您逐步升级到 en_US，然后是 en，然后是根目录。
The CLDR - Unicode Common Locale Data Repository has a proposed (as of 2015) algorithm based on language distance. Without the distance data this is not a solution, but is worth watching for a solution in the future.