6

我认为这是一个genstrings错误或“功能”，但想看看是否有人遇到过这个或知道答案。我正计划为此打开一个雷达。

我们使用自己的本地化宏。让我们称之为CustomLocalizedString。在我们的代码库中，它非常大，我们使用了很多 3rd Party 库。对于绝大多数第 3 方库，如果碰巧有它们，我们不希望它们的任何本地化字符串。当我们确实想使用它们的本地化字符串时，我们修改 3rd Party lib 以使用我们的CustomLocalizedString宏。由于我们不关心的字符串正在使用NSLocalizedString*宏，因此认为这不是问题。

本地化基本上开始标记一些有问题的字符串。经过一番研究，我意识到它来自第 3 方库。然后我进一步意识到我们还包括了其他不应该存在的字符串（我们有大量的字符串）。这些是使用NSLocalizedString*marco 的字符串。

所以我们的调用genstrings是这样的：

genstrings -o output -s CustomLocalizedString

我实际上使用xargsandfind来创建文件参数，因此为简洁起见，我省略了该部分。根据输出，看起来像是genstrings将NSLocalizedString和CustomLocalizedString字符串都放入 Localizable.strings 文件中。

为了进一步验证我用这个创建了一个文件：

NSLocalizedString(@"Normal localized string macro", nil);
CustomLocalizedString(@"Custom localized string macro", nil);

并跑了：

genstrings -o out -s CustomLocalizedString localized_string.txt

输出是：

/* No comment provided by engineer. */
"Custom localized string macro" = "Custom localized string macro";

/* No comment provided by engineer. */
"Normal localized string macro" = "Normal localized string macro";

运行man genstrings产生这个：

-s routine
    Substitutes routine for NSLocalizedString.  For example, -s MyLocalString will catch calls to MyLocalString and MyLocalStringFromTable.

这听起来像是NSLocalizedString*宏会被忽略，但事实并非如此。

注意我已经重新编写了find能够只包含我们想要本地化的第 3 方库。我们的第 3 方库基本上都在一个目录中。由于团队中有很多开发人员，我宁愿尝试查找是否缺少标志或其他允许我包含 3rd Party lib 目录并使其仅正确使用CustomLocalizedString宏的东西。否则我可以预见有人没有意识到我们是如何运行的genstrings，我们突然发现我们需要本地化的字符串不是因为它们没有添加到我们的genstrings find列表中为时已晚。

4

0 回答 0