Fuchsia 本地化子系统的发展受平台的即时需求影响。另一方面，本地化领域有着悠久的历史，并且有许多众所周知的问题需要解决。我们采用了一种开发方法，只处理平台在短期内需要的问题，例如开发使用无障碍功能管理器 (a11y) 和屏幕阅读器的功能。因此，我们故意将一些问题推迟到子系统需要使用它们为止。
本部分列出了此类已知但尚未实现的作品，作为未来使用的记录，或者作为相关方选取某些作品并将其贡献到开源 Fuchsia 代码库的方式。您可以前往邮寄名单 intl-dev@fuchsia.dev 讨论任何在此发布的主题。
未来的工作大致按区域分类。
API
除了 C++ 之外，没有其他 API 支持。Rust 提供低级支持，但由于目前没有 Rust 客户端，因此目前还未使用它。理想情况下，这个代码只有一个实现 (Rust)
没有类型安全的 API 可用于消息。理想情况下，我们能够基于
strings.xml的内容使用目标编程语言生成类型安全代码。这目前并未实现：创作者需要通过自动化测试或其他方式来验证消息格式和参数顺序是否与本地化消息的预期相符。这是因为底层 API 不是类型感知型 API，除非通过实时生成自定义代码来修复问题。
安全性
- 加载的消息存储在堆上，并且可以写入。这可能会带来安全风险。更好的方法是将消息加载到随后将被标记为只读的连续内存区域中。这样可以防止任何试图利用格式 API 的基本类型不安全 API 的攻击，使其混淆以揭示其不应透露的信息。
语言区域回退
目前，回退机制并未内置以下所需的属性，但非常有必要。
不支持动态更改语言区域。调用程序必须监听
OnChange事件并相应地更新Lookup。通常，程序作者应以正确方式实现对语言区域更改的响应。这与应该已经存在的通信基础架构大相径庭，因为我们预计
LookupAPI 的用户已经与fuchsia.intl集成，可以了解用户的语言区域偏好设置。
打包
您需要通过在
BUILD.gn文件中注册本地化资源来生成和打包这些资源。原则上，这是可以自动执行的，因为构建系统知道资源的源位置和目标位置，以及它们各自的语言区域。这项工作尚未完成。目前，还无法实现按需加载本地化资源。采用目前的实现方法，无法将本地化资源捆绑到独立于“主”二进制软件包中的软件包中。对于空间受限的设备以及以多种语言本地化的应用（例如 Gmail 应用或 Chrome 浏览器），这成为一个重要因素，有时可能会妨碍采用。
按需加载将仅允许下载用户在其设备上实际使用的本地化资源。
目前尚未实现第三方贡献的内容。此功能（如果可用）将允许第三方向由其他人（而非其自身维护）的应用提供本地化资源。这样便可单独支持长尾语言，而原作者没有动力维护这种长尾语言。
除了提供对将现有 Fuchsia 软件包切片为“适当”且独立的“语言包”数据集软件包的明显机械支持，这一功能差距还包括解决软件分发参与方之间的信任和代码验证问题。到目前为止，对于 Fuchsia 软件来说，这还不是重大问题。