这样的技术有一个很大的优点，也有一个很大的缺点。
好处是，正如您所提到的，所有者可以动态更改主题名称，从而更改翻译的来源。如果您有一个特殊的用例，例如不同版本的翻译，这可能非常有用。
我有一个项目，我使用第一个字符串作为变量。使用此方法，我可以动态转换从不同函数返回的字符串，在我的示例中是从API返回的。具体而言，我收到的错误如下AdError.INVALID_INPUT, 我可以输出每种语言的错误描述。
问题是，最大的缺点是，您无法在主题/插件中找到所有字符串。许多翻译程序（或WPML之类的插件）循环遍历您的文件并搜索__() 和_e() 函数（以及所有其他翻译函数），并解析字符串以创建翻译的引用。
如果在调用中使用变量，则无法找到textdomain的字符串或translationstring的字符串，因为它们是动态的，并且没有硬编码到文件中。
如果选择此路径，则需要一个额外的文件，其中定义了所有翻译：
__( \'Your new String\', \'yourtheme\' );
__( \'Your new String2\', \'yourtheme\' );
如果您使用
.mo-文件，这会变得更容易一些，因为您只需更改文件，但只要添加另一个字符串，所有翻译文件也必须更新。
结论
一般来说，我不鼓励您对textdomains使用这种方法。只需在整个主题文件中搜索/替换就会容易得多（大多数编辑器只需点击几下即可完成）。
如果您想要翻译您不知道的字符串或动态生成的字符串，这可以是一个很大的简化。只需确保在gettext 函数，以确定所需的翻译是否已在翻译系统/生产订单/采购订单文件中识别。
像这样的事情应该会奏效（未经测试）：
add_filter( \'gettext\', \'f711_check_for_translations\', 10, 3 );
function f711_check_for_translations( $translated, $text, $domain ) {
if ( $text == $translated ) {
AddNewStringToTranslationStrings( $text ); // Function to add the string to your translation strings, however you are going to do that.
}
return $translated;
}
