我尝试将我编写的任何应用程序中使用的所有字符串(和其他常量)外部化，原因很多，这可能是大多数堆栈过度使用的第二自然，但是我想拥有的一件事是能够自动检查任何用户可见的字符串。这带来了几个问题：

• 并非所有字符串都是用户可见的，将它们长矛化并保持适当的分隔是很简单的(但有可能)
• 我使用的大多数(如果不是全部)字符串外部化方法都涉及不会通过拼写检查器(例如aspell / ispell)的有效文本(例如：TheStrName =" some string。"和注释)。
• 许多拼写检查器(再一次为aspell / ispell)不会处理很多现成的单词(通常是技术术语，专有名词，或者只是"新"术语，例如元数据)。

我们如何将这样的东西合并到构建过程/测试套件中？每次有人更改应用程序中的所有字符串时，都要有人手动对其进行拼写检查是不可行的，而且第一次也无法正确拼写它们。

解决方案

回答

如果测试过程中没有发现错误，我们将手动执行，然后由质量检查团队，翻译人员进行本地化或者本地化质量保证期间进行处理。然后，我们提出了一个错误。

我们的大多数开发人员都不以英语为母语，因此这对我们来说不是一个普遍的问题。穿过裂缝的数量非常小，这对我们来说是一个令人满意的解决方案。

没有几百行代码可以实现100％无bug(嗯……也许是奇怪的嵌入式代码)，只需将拼写错误视为bug，不要在它上浪费太多时间。

一旦应用程序成熟，在发行版之间就不会更改超过90％的字符串，并且比较两个版本的资源，弄清什么不是新的(首先检查它们)，更改/更新的内容是一个相当琐碎的练习。 (检查下一个)以及未更改的内容(无需检查这些内容)

因此，更像是我需要在第一次时手动检查所有这些，而下次我只需要检查其中的10％。现在问问自己，是否仍然真的需要自动进行拼写检查。

回答

使用aspell。这是一个程序，可用于unixoids和cygwin，可以在多种源代码上运行。用它。

回答

首先，请不要将其放入构建过程中。如果我(意思是我的计算机)每次尝试调试或者构建新功能时都要拼写检查网站上的所有内容，那我将是一个报复的编码员。我什至不认为这种操作属于单元测试(我们正在测试的是人机界面，而不是计算机化的人机界面)。

第二点，不要编写脚本。我们将有很多误报误入歧途，以致人们将停止阅读报告，并且状况不会比开始时更好。

第三点，这可能是最容易通过人工完成的问题：QA团队，文案编写者，beta测试人员，翻译人员等。我构建的所有具有国际化内容的大型网站都具有相同的流程：我们从复制编写者将其发送到翻译服务/代理机构，将其放入持久层并进行部署。测试人员(质量检查人员，开发人员，项目经理，设计师等)会发现拼写或者语法错误，并提出错误报告。繁琐的工作和太多的双眼让许多拼写/语法错误无法通过。

第四点，页面上总会有拼写和语法错误。甚至主要的报纸网站都没有解决这个问题，他们整个办公楼里都挤满了编辑。

回答

我可以想到两种自动解决此问题的方法：

让编译器区分UI中使用的字符串和其他地方使用的字符串。根据目的重载字符串数据类型的不同变体，并重载输出方法以仅接受该类型，这样我们就可以创建仅输出UI字符串的伪UI并对其进行拼写检查。

是否可行，当然取决于平台和应用程序的整体体系结构。

另一种方法可能是使用出现在代码注释，xpath，表名中的所有字符串来简单地更新拼写检查器数据库，将其命名并认为它们完美无瑕。当然，这将降低拼写检查的精度。

回答

首先，关于字符串外部化，GNU GetText(如果正确使用)创建的字符串文件除了字符串的实际内容外几乎不包含任何文本(有一些标头，但很容易使拼写检查器忽略它们)。

第二件事，我要做的是在持续集成环境中运行拼写检查器，并且可能通过Web界面将错误提供给外部，但电子邮件也可以工作。然后，开发人员可以查看错误，并在代码中进行修复，或者使用一些简单的界面让拼写检查知道应该忽略拼写错误(Web界面可以将错误视图和拼写检查器界面集成在一起)。

回答

如果使用Java并将本地化的字符串存储在资源包中，则可以检查Bundle.properties文件并验证包字符串。我们还可以添加一个特殊的注释注释，处理器可以使用该注释注释来确定是否应跳过条目。

通过此方法，我们可以提示有关语言环境的信息，并提供一种在一个构建过程中检查多种语言的方法。

尽管我认为我所介绍的内容将指导我们进行拼写检查的方法，但我无法回答我们将如何实际执行拼写检查。