我尝试将我编写的任何应用程序中使用的所有字符串（和其他常量）外部化，原因有很多，这可能是大多数 stack-overflowers 的第二天性，但我想要的一件事是能够自动对任何应用程序进行拼写检查用户可见的字符串。这带来了几个问题：
你如何将这样的东西整合到你的构建过程/测试套件中？每次更改应用程序中的所有字符串时，让某人手动拼写检查这些字符串是不可行的——而且它们不可能在第一次时就全部正确拼写。
我可以想到两种半自动的方法：
让编译器帮助您区分 UI 中使用的字符串和其他地方使用的字符串。根据用途重载字符串数据类型的不同变体，并重载输出方法以仅接受该类型 - 这样您就可以创建一个仅输出 UI 字符串的假 UI，并对其进行拼写检查。
当然，这是否可行取决于平台和应用程序的整体架构。
另一种方法可能是简单地使用代码中出现的所有字符串（注释、xpath、表名，你可以命名）来更新拼写检查器数据库，并将它们视为完美的cromulent。这当然会降低拼写检查的精度。
我们手动进行，如果在测试期间没有发现错误，那么它们会被 QA 团队、翻译人员本地化或本地化 QA 期间发现。然后我们提出一个错误。
我们的大多数开发人员都不是以英语为母语的人，所以这对我们来说并不是一个罕见的问题。从裂缝中溜走的数量是如此之少，以至于这对我们来说是一个令人满意的解决方案。
没有任何东西超过几百行是 100% 没有错误的（嗯......也许是奇怪的嵌入式代码），只要把拼写错误想象成错误，不要在上面浪费太多时间。
一旦您的应用程序成熟，超过 90% 的字符串不会在不同版本之间发生变化，比较两个版本的资源、找出新的内容（首先检查它们）、更改/更新的内容将是一个相当简单的练习（检查下一个）和没有改变的（不需要检查这些）
所以想起来更像是我第一次需要手动检查所有这些，下次我只需要检查其中的 10%。现在问问自己是否真的需要自动化拼写检查。
首先，关于字符串外部化——GNU GetText（如果使用得当）创建的字符串文件除了字符串的实际内容之外几乎不包含任何文本（有一些标题，但很容易导致拼写检查器忽略它们）。
第二件事，我要做的是在持续集成环境中运行拼写检查器，并在外部提供错误，可能通过 Web 界面，但电子邮件也可以。然后，开发人员可以查看错误并在代码中修复它们，或者使用一些简单的界面让拼写检查知道应该忽略拼写错误（Web 界面可以集成错误视图和拼写检查界面）。
如果您使用 java 并将本地化字符串存储在资源包中，那么您可以检查 Bundle.properties 文件并验证包字符串。您还可以添加一个特殊的注释注释，您的处理器可以使用该注释来确定是否应跳过条目。
此方法将允许您提供有关语言环境的提示，并提供一种在一个构建过程中检查多种语言的方法。
我无法回答您将如何执行实际的拼写检查，但我认为我所介绍的内容将指导您执行拼写检查的方法。
使用 aspell。它是一个程序，可用于 unixoids 和 cygwin，它可以在多种源代码上运行。用它。
首先，请不要将其放入您的构建过程中。如果我（指我的计算机）每次尝试调试或构建新功能时都必须对网站上的所有内容进行拼写检查，那我将成为一个复仇的编码员。我什至不认为这种操作属于单元测试（您正在测试人机界面，而不是计算机化界面）。
第二点，不要写脚本。您将有如此多的误报从裂缝中消失，以至于人们将停止阅读报告，而您的情况并不比刚开始时好。
第三点，这可能最容易通过让人类来解决：QA 团队、文案编写者、beta 测试人员、翻译人员等。我建立的所有具有国际化内容的大型网站都有相同的流程：我们从文案作者，将其发送给翻译服务/机构，将其放入持久层，并进行部署。测试人员（QA、开发人员、PM、设计师等）会发现拼写或语法错误并提交错误报告。有太多的繁文缛节和一双双眼睛，让许多拼写/语法错误无法通过。
第四点，你的页面总会有拼写和语法错误。甚至主要的报纸网站也没有解决这个问题，他们的整个办公楼里都挤满了编辑。