类似于 Rosetta 的 PHP 翻译前端？

Posted 2023-02-16

【中文标题】类似于 Rosetta 的 PHP 翻译前端？

【英文标题】：PHP translation frontend similar to Rosetta?

【发布时间】：2011-09-08 16:57:26

【问题描述】：

我目前正在将 Web 应用程序从基于数据库的国际化方法（每个单词在翻译表中都有一个条目，以及实际翻译）迁移到基于 Zend_Translate 和 CSV 文件的网络应用程序。

我需要提供一种对最终用户友好的方式来快速轻松地更新这些翻译。理想情况下，为了最大程度地降低破坏内容的风险，用户不会直接编辑 CSV 文件，而是显示一个带有字段的漂亮表单。

您知道一个独立的、基于 php 的、最终用户兼容的翻译前端，它支持 Zend_Translate 必须提供的适配器之一 - 最好是 gettext 或 csv？

类似于 Python/Django 的 Rosetta 但在 PHP 中？ Rosetta 完全符合我的要求：

但出于服务器设置的原因，我非常愿意在这里使用 PHP。

SimplePO 看起来方向正确，但太简单了——它似乎无法处理多种语言和目录以及复数。

【问题讨论】：

所以也许我误解了这个问题。我假设您想从 PHP 代码中自动提取和替换文字字符串。 Rosetta 是否真的可以用来解决问题，但您的反对意见是它没有在 PHP 中实现？基于 Python 的也可以处理 PHP 代码中的文字字符串，这似乎很奇怪。也许问题是您将手动提取感兴趣的文字并修改 PHP 代码以访问翻译，而您想要的只是翻译管理部分？如果是这样的话，用PHP程序来做会不会比较容易？

@Ira PHP 而不是 Python 的论点是，我在后者不可用的平台上部署了很多，并且要求能够即时更改翻译。自己动手确实比较容易，但我想知道是否有现成的产品已经可以完成这项工作。

确实，我误会了。我仍然不明白 Rosetta 是如何处理 PHP 部分的，但我会把它当作诗意的许可。我撤回了我的回答。

不知何故，我感觉到您已经选择了 Zend_Translate 和 CSV（或 gettext？）。您现在需要的是一种编辑 CSV（或 gettext）数据的方法？

@Adrian 完全正确！哪一种没关系，两种格式我都可以接受。

【参考方案1】：

如果你可以使用 gettext 文件（Zend_Translate 支持它们）你可以试试POEdit。从 1.3 版本开始使用起来非常简单，并且支持复数形式。

但是，用户最终必须下载文件并重新上传，因为 POEdit 不是在线工具。我不知道任何其他基于网络的工具。

【参考方案2】：

我还没有看到另一个，可能是出于以下原因。尽管在 SimplePO 网站上说了什么，但翻译人员不喜欢并且通常不会在上面显示的并排翻译系统上工作。

这就是程序员想象的翻译器的工作方式，但这是有缺陷的。翻译人员使用名为 TMX、Translation Memory Exchange 的工具包（通用名称参见 Okapi 一个开源实现以了解它），并在此构建单词、短语和句子的翻译词典。他们获取不同格式的文件并将其输入 TMX 软件，这为他们提供了第一次通过，即 60%、70% 等被翻译，但就像谷歌语言 API 在目标语言中的意义一样严重受损。

然后他们所做的是翻译 TMX 未处理的单词，将其添加到合乎逻辑的词典中，然后将其口语化，即使其在目标语言中工作并理解它。因此，翻译人员应始终将其翻译成他们的母语。

他们这样做的原因有很多，a) 这很有意义，而且有效，可以减少他们的工作量，b) 因为他们是按字面意思收费的，而且并排翻译不允许他们使用他们的工具并最大化他们的收入。

翻译人员想要的是一个您可以导出格式的文件，他们可以导入和翻译，导出并发送回给您导入。

文件格式可以是 csv、rtf、tmx、xliff、gettext，如果您阅读 Symfony 框架文档，您可以了解它们是如何处理和处理的（我认为它们做得很好）。

说了这么多，大约 8 年前，当我不得不用英语、法语、德语、匈牙利语和斯洛伐克语编写网站时，我处于类似的位置，我和 SimplPO 做了同样的事情，只是写了我自己的并排申请允许这样做。然而，我们正在为其编写应用程序的公司在内部完成了所有自己的翻译，因此我们没有遇到翻译的问题。当我们这样做时，我们编写了一个导出到 RTF 并从 RTF 导入（这本身就是令人难以置信的），这样翻译器就可以像上面那样工作。

不过，SimplePO 是我所见过的该想法的唯一其他实现。 Zend 等框架似乎认为您只是创建查找标记来替换单词和短语，并且没有在应用程序中构建任何控制来管理流程。因此，它很快就会失控，维护起来既困难又昂贵。

大多数编写多语言网站的人实际上并不这样做。他们编写一个主站点，然后复制、翻译并维护翻译版本。对我们来说，逻辑类型看起来很笨拙，但实际上非常有效。

它有效的原因之一是 i18n 和 l10n 与语言之外的许多其他事情有关。

外观和感觉。盎格鲁撒克逊人喜欢冷色和圣衬线字体，西班牙人喜欢衬线字体和明亮的颜色。当您跨越其他文化时，您的期望会在布局、类型、颜色等方面大相径庭。

法语和某种程度的德语比同等的英语要长 30%，更冗长，所以你的布局很快就会被放在手提篮里。

闪米特语从右到左

日语和其他不基于字母的语言可以从上到下运行 ltr rtl，有些甚至没有空格 日期？美国、日本、英国、匈牙利各不相同 货币和数字格式，别让我失望

很抱歉继续总结一下：- 对于简单的并排，只需自己编写，在没有任何框架的情况下花了我大约两周的时间，并且在我继续使用标签替换的情况下解决了它。但是，再想想你在做什么。小心点。

【讨论】：

感谢您对翻译的深入了解！在我的情况下，并非所有这些都 100% 适用 - 有问题的翻译人员不是专业的软件翻译人员，工作的一个同样重要的部分是让网站所有者能够即时更改文本 - 但这是有价值的信息，很高兴知道未来。我来看看 SimplePO。

【参考方案3】：

你可以试试Transtable，一个简单的网络接口，用于编辑php数组中的翻译。