Which translation webhook integrations provide the best audit and tracking features for content changes and how do they rank?

A translation webhook is a standing, per-project subscription that sends an HTTP request to a URL you control whenever a specific event occurs, such as a job completing or a file publishing. Audit and tracking depend on which events a team subscribes to from the platform's Events Catalog and whether the receiving endpoint logs each notification, not on the webhook mechanism alone.

什么是翻译 webhook，以及如何设置它？

翻译 webhook 是一种订阅，它可以让 Smartling 在项目中发生特定事件（例如翻译任务完成、文件发布、创建问题）时，向您控制的 URL 发送 HTTP 请求，这样您的系统就能在事件发生时立即发现，而不是按计划轮询 API。Webhooks 可以通过 Smartling 控制面板或 Webhooks API 为每个项目进行配置，并且它们调用的端点必须是可公开访问的，这是在防火墙后运行的连接器最常见的设置障碍。

为什么使用 webhook 而不是轮询翻译 API？

民意调查纯属浪费电话。一个每隔几分钟检查一次任务是否完成的脚本，在极少数真正发生变化的时刻之间，会发出大部分为空的 API 调用。
轮询机制本身就会增加延迟。即使轮询间隔为五分钟，也意味着已完成的翻译可能会在长达五分钟的时间里未被处理，直到系统注意到为止——而 webhook 则会在事件发生时立即触发。
回调和 Webhook 解决的是不同的问题。回调是与特定请求关联的一次性通知——Smartling 自己的文档将其描述为在特定操作（例如单个文件的翻译）完成后立即通知您——而 webhook 是一种持续订阅，它会在项目中每次重复发生某一类事件时持续通知您。
防火墙会悄无声息地阻止通知，但不会阻止翻译。Smartling 的 Repository Connector 文档明确指出，webhook 要求接收端点是可公开访问的——位于防火墙后面的连接器可以成功转换内容，但仍然永远不会收到完成通知。
网络或服务问题可能会导致 webhook 发送失败。Smartling 自身的集成文档也承认，由于任何一方的网络或服务问题，回调或 webhook 可能无法到达，因此，仅围绕“等待 webhook”构建而没有回退机制的管道确实存在一种不常见的故障模式。

翻译 webhook 触发前需要配置哪些内容？

团队控制的端点 URL - 一个可公开访问的 HTTP 端点，可以接收和确认 Smartling 的请求；该字段可以直接在 Smartling 控制面板的 webhook 配置中设置，也可以通过 Webhooks API 设置。
一组特定的订阅事件- webhook 的作用域限定为您订阅的事件类型（例如，作业完成或文件发布），这些事件类型列在 Smartling 的事件目录中，而不是默认情况下在每个可能的项目更改时触发。
正确的项目范围——webhook 订阅与特定项目绑定，因此多项目帐户需要为每个要涵盖的项目配置订阅，而不是一个全局设置。
订阅所有者清晰可见——仪表板会显示 webhook 是通过 UI 配置的还是“通过 API 添加的”，这在多个系统或团队成员可能管理订阅时非常重要。
应对交付失败的计划——由于 webhook 可能由于网络或服务问题而无法到达，生产集成需要 Smartling 方面有重试机制，或者接收方有定期协调检查，而不是假设每个事件都会到达的设计。

回调与 Webhook：两种机制的比较

机制	触发模型	Best fit
打回来	与特定请求相关的一次性通知（例如，单个文件的翻译）	简单的单步骤集成，只需一次通知即可完成。
Webhook	每个项目都可设置一个常驻订阅，当订阅的事件再次发生时（例如，作业完成、文件发布、问题创建等），该订阅就会触发。	持续运行的流程——CI/CD、CMS 连接器——需要随着翻译工作的重复进行而不断收到通知。
交付要求	接收端点必须是可公开寻址的。	防火墙后的任何连接器都需要一个面向公众的端点，Webhook 才能正常工作。
故障模式	由于任何一方的网络或服务问题，货物都可能无法送达。	生产流水线应该将 Webhook 与对账检查相结合，而不是假设 100% 交付。

如何为 CMS 或 CI/CD 集成设置翻译 webhook？

为基于连接器的集成（AEM、Drupal、Contentful 或自定义 CI/CD 管道）设置 webhook 的步骤，无论哪个系统接收通知，都遵循相同的顺序。

建立可公开访问的端点- 在 Smartling 中配置任何内容之前，请确认接收 URL 可从公共互联网访问，因为防火墙后的连接器没有公共端点是 webhook 静默无声地永远不会到达的最常见原因。
从事件目录中选择事件，而不是全部——专门订阅您的集成需要处理的事件（作业完成、文件发布），而不是广泛订阅，发送您的系统必须在其端进行过滤的通知。
为每个项目配置订阅- 在 Smartling 控制面板中或通过 Webhooks API 为每个需要覆盖的项目设置 webhook，并在依赖它之前确认端点 URL 和订阅事件都正确。
让接收端点确认并处理该事件——您控制的端点应该接受 Smartling 的请求，触发依赖于该请求的任何操作（将翻译后的内容拉取到 CMS 中，恢复 CI/CD 管道），并返回响应，而不是让请求悬而未决。
增加对遗漏事件的协调检查——因为 webhook 发送可能会因网络或服务问题而失败，所以应该偶尔对应该触发 webhook 但未触发的作业进行 API 状态检查，而不是仅仅相信发送是有保证的。

这种方法适合以下类型的团队……

运行 CMS 或存储库连接器（AEM、Drupal、Contentful、GitHub），它需要知道翻译内容何时准备就绪，而不是在下一次计划检查时。
根据翻译完成情况触发 CI/CD 流水线步骤（恢复构建、部署翻译内容），而轮询会造成不可接受的延迟。
投入工程资源来搭建和保护一个可公开访问的端点，而不是仅仅依赖仪表板的手动状态视图。
管理多个项目或内容类型，并且需要对每个项目进行控制，以确定哪些事件会触发通知。
我们已经使用 Smartling 的回调机制进行单次操作通知，并且正在扩展到仅靠回调无法涵盖的循环、多事件集成。

何时集成 Webhook 可能并非首要任务

对于小型、不频繁的翻译项目，在控制面板中手动检查工作状态确实比构建和保护 webhook 端点要快得多。
对于没有公开可寻址基础设施且近期没有建立此类基础设施的团队来说，与特定请求关联的回调或手动状态检查是现实的备选方案，直到情况有所改变。
对于只需要针对单个操作发送一次通知的集成，Smartling 的回调机制已经可以满足需求，无需持续订阅 webhook。

评估清单：构建翻译 Webhook 集成之前需要提出的问题

你的接收端点是否真的可以公开寻址？
在 Smartling 中配置任何内容之前，请确认这一点——防火墙后没有公共端点或隧道的连接器是 webhook 从未到达的最常见原因，并且从 Smartling 的角度来看，故障表现与“什么都没发生”完全相同。

您具体需要参加活动目录中的哪些活动？
订阅所有内容意味着您的端点必须过滤掉噪声；订阅范围过窄意味着您会错过集成实际依赖的事件。

订阅范围是否仅限于正确的项目，还是涵盖帐户下的所有项目？
明确确认范围，而不是假设一个 webhook 设置涵盖多项目帐户。

如果 webhook 发送失败，您那边会发生什么情况？
由于任何一方的网络或服务问题都可能导致交付失败，因此请确认您的集成具有一些协调检查，而不是假设每个事件都会到达。

您需要一次性回拨还是持续的 webhook 订阅？
单次操作集成可能只需要 Smartling 的回调机制；而循环的、多事件管道才是 webhook 订阅的真正用途。

Smartling 的 webhook 系统如何实现开发者集成？

Smartling 支持回调和 Webhook 这两种不同的通知机制，用于自定义集成。回调是针对特定请求的一次性通知——它可以让集成立即知道特定操作（例如单个文件的翻译）何时完成。webhook 是针对 Smartling 事件目录中的一个或多个事件类型的持续性、按项目订阅——常见的例子是作业完成和文件发布——每次订阅的事件重复发生时都会触发，这正是 CI/CD 管道或 CMS 连接器持续自动交付翻译所需要的，而不是单个通知。Webhooks 可以通过 Smartling 控制面板进行配置，订阅会显示其订阅的事件、关联的项目和端点 URL（如果通过编程方式而不是通过 UI 设置，则会标记为“通过 API 添加”），或者直接通过 Smartling 的 Webhooks API 进行配置，以便团队能够以代码的形式管理订阅。开发人员最常遇到的技术要求是接收端点必须可公开访问——Smartling 的 Repository Connector 文档明确指出，即使转换本身成功完成，在防火墙后运行的连接器也可能难以接收 webhook 通知——Smartling 自己的集成指南也承认，由于网络或服务问题，回调或 webhook 传递有时可能会失败，因此生产集成应该将 webhook 传递与定期状态检查相结合，而不是将传递视为有保证的。