内容引擎托管连接器的可行性评估

使用本指南可以评估新的内容交换承载连接器的技术可行性，并估计其复杂性。

简介

一个连接器是一项将在Lokalise上安装和托管的服务，并作为与第三方内容平台的桥梁(从现在开始，内容平台)这样就可以在两个平台之间交换可翻译的内容。如果你还没有这样做，请熟悉本地化内容引擎架构．

本指南包括几个部分供你理解:

如何在内容平台上进行内容本地化。
哪些内容类型可以转移到Lokalise。
开发可用的API端点是什么?
可用的身份验证类型是什么。

建议在内容平台和Lokalise中创建一个帐户，并提供一些用于测试的数据。

以下是该分析过程的方案:

步骤1。弄清楚如何在内容平台上进行内容本地化

您应该了解用户如何在内容平台中使用多语言内容。一些内容平台已经提供了多语言支持，而其他一些内容平台则需要变通方法、附加插件或可用于管理多语言数据的高级选项。

目前需要解决的主要问题是，在lockalise上进行本地化后，多语言内容将如何存储在内容平台中。

在完成下面的问题之后，你应该对内容平台上的本地化工作流程有一个较高的理解。基本上有两种选择:

A.提供多语言支持:当Lokalise用户导出本地化内容时，翻译将与现有项目无缝关联。
B.不支持多语言:当Lokalise用户导出本地化内容时，将在内容平台上创建新项目。

让我们来看看这些选项。

选项A)提供多语言支持

如果你的内容平台处理本地化内容，它是如何工作的?

多语言支持的体系结构

如果你的内容平台处理本地化内容，它是如何工作的?这里有一些你可以检查的东西:

每个文本项目是否包括所有翻译?
每个文本项都包含语言参数吗?具有语言参数的不同文本项之间是否相互链接?
多语言内容是否组织在单独的文件夹或另一种类型的层次结构中?
是否存在默认语言?

存储的语言

现在让我们检查一下语言在内容平台中的存储方式:

用户是否需要针对不同的内容类型启用多语言功能?或者内容平台默认为所有内容类型启用它?
是否有一个预定义的所有客户可用的语言列表?这个语言列表是有限的还是无限的?用户可以定义自己的自定义语言吗?
内容平台是否通过ISO代码识别语言?如果是，它们是否类似于Lokalise使用的标准代码?
用户是否可以添加自定义ISO代码或修改当前的ISO代码?在这种情况下，这些代码是否必须遵循任何命名约定?它们能和Lokalise上使用的ISO代码匹配吗?
- 注意，Lokalise自定义代码包括下划线(例如，en_US)．您的内容平台可能使用破折号或其他自定义代码。如果语言代码与Lokalise的默认语言代码不匹配，那么用户可以使用Lokalise上的自定义语言代码使它们在两个平台上都匹配。

选项B)多语言支持不可用

如果您的内容平台不能处理本地化内容，那么您需要了解内容平台用户通常使用哪些变通方法来克服这种限制，或者编写您自己的解决方案。

这里有一些你可以检查的东西:

是否有任何插件或额外的服务来管理多语言内容? 如果有，是否有一种方法可以通过API使用它?多语言属性究竟是如何存储的?
是否有保存翻译内容的特定方法?例如，有选项卡，分支或特设组件，可以用于多语言的目的? 如果是，那么您应该检查这些元素是否可以通过API访问。
或者，如果您的内容平台上没有前面的选项，您可以检查翻译后的元素是否可以存储为新项，以及这些项是否支持其他属性。
- 例如，您的内容平台提供电子邮件模板，但不支持多语言。那么，也许您唯一的选择是创建翻译成不同语言的新电子邮件，并通过自定义属性将它们链接到原始电子邮件模板。

步骤2。决定哪些内容类型可以转移到Lokalise

这一步的结果将是用户能够传输到Lokalise的所有内容类型的列表。因此，你应该更深入地了解你想让用户本地化的分组、内容类型和字段，以及如何将它们转化为可以翻译的项目。

浏览内容平台中可用的内容类型(例如，文章、电子邮件、模板等)。
根据您的用户知识和他们常见的本地化需求，选择您希望他们能够发送到Lokalise的内容类型子集。
找出所选内容类型的多语言选项，并检查如何将翻译后的内容存储在内容平台中。
- 例如，假设您的内容平台可以使用电子邮件，但不支持多语言。有没有一种方法可以创建新的电子邮件作为最初的翻译，并将它们全部链接起来?

步骤3。熟悉内容平台API

此时，您应该验证所需的工作流是否可以通过API重现。

至少应该仔细检查所选内容类型是否可以通过API端点访问，并且还可以通过API创建翻译或新项。但是，如果API不提供任何端点来管理所选内容类型，那么就不可能构建连接器。

对于上一步中选择的每个内容类型，确定一个API端点，允许您:

获取所有可翻译项的列表，以及每个项的标识符。
获取这些项目的实际内容。
更新项目的翻译，或创建将以某种方式链接到原始项目的新项目。

在查看API时，请检查可能影响连接器使用的任何速率限制或配额。

获取可翻译项的列表

该端点用于构建缓存端点在洛卡利斯那边。

对于所选的每一种内容类型，都应该有一个得到列表或检索所有实例或类似的API调用。

通常，这个端点提供所有现有实体的列表，其中包含一个实体标识符，该实体标识符将用于检索条目内容(即要本地化的文本)。

在这里，您还应该开始准备用户将用于过滤Lokalise端内容的字段列表(例如。，创建日期，标签，文件夹等)。

检索要翻译的项

该端点用于构建翻译端点在洛卡利斯那边。

有了项目标识符之后，需要调用来获取内容本身。你需要找到一个获取内容值或获取内容详细信息或类似的API调用。

注意，还需要获取以前的本地化版本，而不仅仅是原始语言中的项。否则，翻译后的项将不能正确更新，连接器可能会创建重复或不一致。

每个项目可能由不同的字段组成;例如，一篇文章可能由标题、描述、正文和一些附加字段组成。如果是这样:

选择能更好地识别整个组的字段，这样用户就可以在内容平台和Lokalise上以类似的方式工作(例如，对于一篇文章，它将是标题)。
Lokalise将为不同的字段创建不同的键，但项目字段将始终在内容平台和Lokalise之间一起传输，如中所述什么是“groupTitle”和“title”缓存项字段．
选择适合在Lokalise中过滤内容的其他字段:创建日期、标签、标签和任何其他相关属性。
如果有任何您不想在Lokalise上显示的元素，连接器应该有一种过滤它们的方法。例如，您可能不想显示禁用了多语言支持的元素。在这种情况下，您应该准备好在API调用中过滤掉这些元素。

将本地化的项目发送回内容平台

该端点用于构建发布端点在洛卡利斯那边。

如果您的内容类型本身支持语言，您可能正在寻找更新元素或类似的API调用。
否则，你需要一个创建新元素或类似的API调用。

选项A)提供多语言支持

在内容平台上定义语言的通常工作流程如下:

用户在内容平台中为他们的工作空间(又名概要文件、项目、文件夹或空间)添加或选择语言。
在内容平台上有一个预定义的语言列表，用户可以为每个内容项选择其中任何一种;也就是说，他们不需要为他们的工作空间特意选择相关的语言。

在任何情况下，您都需要一个端点来检索与本地化内容项相关的语言。寻找API端点，例如获取所有语言或获取默认语言或学习其他语言，这是建立环境端点在连接器上。

如果这些调用不可用，则:

翻译后的内容将使用Lokalise的地区代码导出回内容平台。在这种情况下，Lokalise中的任何自定义语言代码都应该与内容平台上的ISO代码相同;否则，它们将不匹配，翻译将不能正确导出。
可以在连接器上硬编码语言列表，如果您的内容平台提供有限的语言列表，这可能是最后的手段。注意，该列表不应该超过12种语言，因为用户需要在每次导入和导出操作中手动选择语言。

还要找一个获得语言对于所有选定的内容类型的每个项。语言参数可以在获取内容值响应或类似的端点。

选项B)多语言支持不可用

此部分仅适用于您的内容平台不支持多种语言，并且没有添加它们的变通方法(语言不能作为自定义属性添加，或者内容不能在文件夹中结构化)。

在这种情况下，您需要弄清楚本地化实体如何与原始实体链接，因为必须存储这种关系。以下是一些常见的变通方法:

将原始项的标识符存储在本地化项的可编辑字段中。
将原始项的标识符存储在本地化项的名称中。
如果可以在内容平台中创建文件夹，请将语言代码作为文件夹名称的一部分添加。
创建一个自定义对象。

步骤4。选择授权方法

选择您的用户将如何授予Lokalise对其内容的读写访问权限:

OAuth 2.0
API密匙

只能选择一种方法。主要区别在于API令牌包含用户帐户，而OAuth通常执行不一定与帐户链接的授权。在选择使用API令牌还是OAuth应用程序时，必须考虑所选端点的API的特定需求。

有关身份验证流的详细说明，请参见App设置:安装并连接到内容平台．

如果你做到了这一点，所有的问题都清楚了，恭喜你，你可以开始了连接器！