具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

为了使本领域技术人员更好地理解本申请实施例提供的技术方案，并使本申请实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请实施例中技术方案作进一步详细的说明。

请参见图1，为本申请实施例提供的一种数据处理方法的流程示意图，其中，该数据处理方法可以应用于任一支持本申请实施例的技术方案的应用程序的客户端(本文中称为第一客户端)，如图1所示，该数据处理方法可以包括以下步骤：

需要说明的是，本申请实施例中各步骤的序号大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

步骤S100、获取自定义多语言编辑信息，该自定义多语言编辑信息包括目标UI控件的显示内容的自定义译文。

本申请实施例中，目标UI(User Interface，用户界面)控件并不特指某一固定控件，而是可以指代第一客户端中任意一个或多个支持自定义多语言的UI控件。

本申请实施例中，为了提高应用程序多语言化的译文的准确性和全面性，可以针对应用程序启用自定义多语言编辑功能，并通过自定义多语言编辑的方式使应用程序中支持自定义多语言编辑的UI控件的显示内容展示为指定语种的准确译文。

示例性的，启用自定义多语言功能的应用程序中的部分或全部UI控件支持自定义多语言编辑。

步骤S110、依据自定义多语言编辑信息刷新目标UI控件的显示内容，以使目标UI控件的显示内容更新为自定义译文。

本申请实施例中，在获取到自定义多语言编辑信息的情况下，可以依据获取到的自定义多语言编辑信息刷新目标UI空间的显示内容，以使目标UI控件的显示内容更新为该获取到的自定义多语言编辑信息中包括的自定义译文。

示例性的，为了使第一客户端重启后，目标UI控件的显示内容与重启前的显示内容一致，第一客户端在获取到自定义多语言编辑信息的情况下，可以对获取到的自定义多语言编辑信息进行保存，例如，将获取到的自定义多语言编辑信息以自定义多语言文件的形式保存，并依据获取到的自定义多语言编辑信息刷新目标UI控件的显示内容，以使目标UI控件的显示内容更新为自定义译文。

示例性的，可以将获取到的自定义多语言编辑信息保存在本地磁盘。

示例性的，为了提高自定义多语言编辑信息的读取效率，还可以将获取到的自定义多语言编辑信息在内存中缓存。

示例性的，可以在对自定义多语言编辑信息保存成功的情况下，依据自定义多语言编辑信息刷新目标UI控件的显示内容，使目标UI控件的显示内容更新为自定义译文，以避免应用程序重启后目标UI控件的显示内容与重启前的显示内容不一致。

需要说明的是，在本申请实施例中，断电或故障等导致保存磁盘失败前，已经成功保存的自定义多语言编辑信息可以使用。针对程序崩溃、内存不足等故障，可以记录在程序崩溃、内存不足等故障之前的自定义多语言状态(可以包括正在进行自定义多语言编辑的状态以及已经编辑的内容)重启APP后继续自动回到上次操作。而针对突发性的手机断电等情况，则需要用户手动重新操作自定义多语言编辑的步骤。

步骤S120、在确定满足多语言编辑信息上报条件的情况下，将自定义多语言编辑信息上报给服务端，以使服务端在确定满足升级条件的情况下，依据接收到的多语言编辑信息确定多语言更新文件，并依据该多语言更新文件对相应客户端进行自定义多语言文件更新。

本申请实施例中，为了实现用户与应用程序开发者之间对翻译内容的沟通，提高应用程序的译文的准确性和全面性，客户端可以在确定满足多语言编辑信息上报条件的情况下，将获取到的自定义多语言编辑信息上报给服务端。

服务端在接收到客户端上报的多语言编辑信息的情况下，可以确定是否满足升级条件，并在确定满足升级条件的情况下，依据接收到的多语言编辑信息确定多语言更新文件，并依据该多语言更新文件对相应客户端进行自定义多语言文件更新，其具体实现可以参见图2所示方法流程中的相关说明。

可见，在图1所示方法流程中，通过对应用程序启用自定义多语言编辑信息，可以通过对应用程序中支持自定义多语言编辑的UI控件的显示内容进行自定义编辑，使目标UI控件的显示内容展示为自定义编辑的译文(即自定义译文)，以使UI控件的显示内容的译文更贴合应用地区的语言习惯，并可以扩展应用程序多语言化的译文的语种，对于已翻译地区的错误译文，可以及时改正，提高了应用程序多语言化的译文的准确性和全面性；此外，通过客户端将获取到的多语言编辑信息上报给服务端，由服务端在确定满足升级条件的情况下，对相应客户端进行自定义多语言文件更新，实现用户与应用程序开发者之间对翻译内容的沟通，进一步提高了应用程序的译文的准确性和全面性。

在一些实施例中，步骤S100中，获取自定义多语言编辑信息，可以包括：

在检测到针对目标UI控件的自定义多语言编辑指令的情况下，展示针对目标UI控件的多语言编辑界面；

获取通过多语言编辑界面输入的自定义多语言编辑信息。

示例性的，可以通过输入针对目标UI控件的自定义多语言编辑指令，对目标UI控件的显示内容进行自定义翻译。

相应地，在检测到针对目标UI控件得到自定义多语言编辑指令的情况下，如检测到针对目标UI控件的点击指令，可以展示针对目标UI控件的多语言编辑界面，如弹出可编辑的自定义多语言弹窗，并获取通过该多语言编辑界面输入的自定义多语言编辑信息。

举例来说，用户可以通过点击UI界面上显示的UI控件的方式，对UI控件进行自定义多语言编辑。在检测到针对目标UI控件的自定义多语言编辑指令的情况下，可以在当前UI界面的上层，以浮窗的形式弹出可编辑的自定义多语言弹窗，由用户通过该自定义多语言弹窗对目标UI控件的显示内容进行自定义翻译。

需要说明的是，在检测到针对目标UI控件的自定义多语言编辑指令的情况下，可以在展示的针对目标UI控件的多语言编辑界面中显示当前使用的多语言翻译，以提高自定义翻译的针对性和准确性。

此外，对于不支持自定义多语言编辑的UI控件，在检测到针对该UI控件的自定义多语言编辑指令的情况下，如在处于自定义多语言编辑模式的情况下检测到针对该UI控件的点击指令，可以不对该指令进行响应。

在一些实施例中，上述在检测到针对目标UI控件的自定义多语言编辑指令的情况下，展示针对目标UI控件的多语言编辑界面之前，还包括：

在检测到第一控制指令的情况下，进入自定义多语言编辑模式，该第一控制指令用于指示第一客户端进入自定义多语言编辑模式；

在处于多语言编辑模式的情况下，检测针对目标UI控件的自定义多语言编辑指令。

示例性的，为了提高自定义多语言编辑的可控性，并降低误操作发生概率，可以预先设置用于控制客户端进入自定义多语言编辑模式的指令。

相应地，在检测到用于控制第一客户端进入自定义多语言编辑模式的控制指令(本文中称为第一控制指令)的情况下，如摇一摇，或者，对预设功能按钮的点击指令等，可以进入自定义多语言编辑模式，并在处于自定义多语言编辑模式的情况下，检测针对目标UI控件的自定义多语言编辑指令，在检测到针对目标UI控件的自定义多语言编辑指令的情况下，可以按照上述实施例中描述的方式进行处理。

在一个示例中，在处于多语言编辑模式的情况下，上述方法还可以包括：

对支持自定义多语言编辑的UI控件进行突出显示。

示例性的，考虑到启用自定义多语言编辑的应用程序中可能存在部分UI控件不支持自定义多语言编辑，为了提高编辑效率，并提高用户体验，在处于多语言编辑模式的情况下，可以对支持自定义多语言编辑的UI控件进行突出显示。

例如，在处于多语言编辑模式的情况下，可以对支持自定义多语言编辑的UI控件蒙上一种提示性标记，如黄色方框；或者，在右上角显示红点。

举例来说，在第一客户端处于多语言编辑模式的情况下，可以对支持自定义多语言编辑的UI控件进行突出显示。用户可以通过点击突出显示的UI控件的方式，对UI控件进行自定义多语言编辑。在检测到针对目标UI控件的自定义多语言编辑指令的情况下，可以弹出可编辑的自定义多语言弹窗，由用户通过该自定义多语言弹窗对目标UI控件的显示内容进行自定义翻译。

在一个示例中，上述方法还包括：

在检测到第二控制指令的情况下，退出自定义多语言编辑模式，并取消对支持自定义多语言编辑的UI控件的突出显示，该第二控制指令用于控制第一客户端退出自定义多语言编辑模式。

示例性的，为了避免误操作，并优化应用程序UI控件显示效果，在完成自定义多语言编辑的情况下，可以控制客户端退出自定义多语言编辑模式。

相应地，在检测到用于控制第一客户端退出自定义多语言编辑模式的控制指令(本文中称为第二控制指令)，如摇一摇，或者，对预设功能按钮的点击指令等，可以退出自定义多语言编辑模式，并取消对支持自定义多语言编辑的UI控件的突出显示。

在一些实施例中，步骤S120中，确定满足多语言编辑信息上报条件，可以包括：

在确定针对目标UI控件的自定义多语言编辑完成的情况下，确定满足多语言编辑信息上报条件。

示例性的，可以在确定针对目标UI控件的自定义多语言编辑完成的情况下，例如，在检测到上述第二控制指令的情况下，确定满足多语言编辑信息上报条件，即第一客户端可以在确定针对目标UI控件的自定义多语言编辑完成的情况，自动将获取到的自定义多语言编辑信息上报至服务端，以提高自定义多语言编辑信息的上报效率。

在另一些实施例中，步骤S120中，确定满足多语言编辑信息上报条件，可以包括：

在检测到针对自定义多语言编辑信息的上报确认指令的情况下，确定满足多语言编辑信息上报条件。

示例性的，为了提高自定义多语言编辑信息上报的可控性，在对获取到的自定义多语言编辑信息进行上报之前，可以进行上报确认。

例如，在确定针对目标UI控件的自定义多语言编辑完成的情况下，可以输出提示消息，该提示消息用于提示用户确认是否对获取到的自定义多语言编辑信息进行上报，并在检测到针对获取到的自定义多语言编辑信息的上报确认指令的情况下，确定满足多语言编辑信息上报条件，对获取到的自定义多语言编辑信息进行上报。

示例性的，服务端在接收到客户端上报的自定义多语言编辑信息的情况下的具体处理流程可以参见下文中的相关描述，本申请实施例在此不做赘述。

在一些实施例中，步骤S120中，将自定义多语言编辑信息上报给服务端，可以包括：

将自定义多语言编辑信息，以及第一客户端的地区信息，上报给服务端，以使服务端在确定第一目标地区的多语言文件满足升级条件的情况下，依据接收到的多语言编辑信息以及地区信息，确定第一目标地区的多语言更新文件。

示例性的，考虑到不同地区的语言习惯可能会存在区别，因此，为了保证自定义多语言的准确性，使其更贴合用户的语言习惯，在进行多语言文件更新的情况下，可以结合地区进行更新。

相应地，第一客户端在向服务端上报多语言编辑信息的情况下，还可以将第一客户端的地区信息也上报给服务端。

示例性的，客户端的地区信息可以依据用户对客户端的相关设置确定，例如，依据客户端的归属地设置(若未设定，则可以使用默认值)确定。

示例性的，不同地区的划分可以按照预设区域范围划分，例如，按照省份划分、按照地理大区划分(如华东、华中等)

服务端在接收到客户端上报自定义多语言编辑信息，以及地区信息的情况下，可以依据地区信息，对不同地区的自定义多语言编辑信息进行统计，以确定各地区的多语言文件是否满足升级条件，并在确定某地区(本文中称为第一目标地区)的多语言文件满足升级条件的情况下，依据接收到的第一目标地区的多语言编辑信息，确定第一目标地区的多语言更新文件，其具体实现可以参见图2所示方法流程中的相关描述。

在一些实施例中，上述获取自定义多语言编辑信息之后，还可以包括：

将自定义多语言编辑信息发送给第二客户端，以使第二客户端在对目标UI控件的显示内容进行展示情况下，依据自定义多语言编辑信息展示自定义译文。

需要说明的是，第二客户端并不特指某一固定的客户端，而是可以指代与第一客户端相同应用程序的其它一个或多个客户端。

示例性的，为了实现用户之间将其自定义翻译内容分享，对于获取到的自定义多语言编辑信息，第一客户端可以将其发送给第二客户端，例如，通过局域网、蓝牙或隔空投送等方式分享给第二客户端。

第二客户端接收到第一客户端发送的自定义多语言编辑信息的情况下，可以在对目标UI控件的显示内容进行展示的情况下，依据自定义多语言编辑信息展示该自定义多语言编辑信息中包括的自定义译文，以便快速扩散符合当地语言习惯的自定义翻译。

在一些实施例中，步骤S100中，获取自定义多语言编辑信息，可以包括：

接收第三客户端发送的自定义多语言编辑信息。

需要说明的是，第三客户端并不特指某一固定的客户端，而是可以指代与第一客户端相同应用程序的其它一个或多个客户端。

示例性的，第三客户端获取自定义多语言编辑信息的具体实现流程可以参见上述实施例中的相关描述。

对于获取到的自定义多语言编辑信息，第三客户端可以共享给第一客户端，其具体实现可以参见上述实施例中的相关描述。

在一些实施例中，上述方法还可以包括：

在第一客户端启动的情况下，向服务端发送状态查询请求，以使服务端依据第一客户端的多语言文件版本信息，确定第一客户端是否需要进行多语言文件更新或回滚；

在确定需要进行多语言文件更新的情况下，从服务端下载多语言更新文件，依据本地的自定义多语言文件生成多语言备份文件，并依据多语言更新文件更新本地的自定义多语言文件，依据更新后的本地的自定义多语言文件刷新UI控件的显示内容；或者，

在确定需要进行多语言文件回滚的情况下，使用多语言备份文件替换本地的自定义多语言文件，并依据替换后的本地的自定义多语言文件刷新UI控件的显示内容；或者，

在确定不需要进行多语言文件更新或回滚的情况下，依据本地的自定义多语言文件刷新UI控件的显示内容。

示例性的，在第一客户端启动的情况下，可以向服务端发送状态查询请求，以确定是否需要进行多语言文件更新或回滚。

示例性的，状态查询请求中可以携带第一客户端的多语言文件版本信息。

服务端在接收到状态查询请求的情况下，可以依据第一客户端的多语言文件版本信息，确定第一客户端是否需要进行多语言文件更新或回滚。

示例性的，服务端可以比较本地的多语言文件版本信息(即服务端侧的多语言文件版本信息)与接收到的第一客户端的多语言文件版本信息(即客户端侧的多语言文件版本信息)，在服务端侧的多语言文件版本比客户端侧的多语言文件版本新的情况下，服务端可以确定第一客户端需要进行多语言文件更新；在服务端侧的多语言文件版本比客户端侧的多语言文件版本旧的情况下，服务端可以确定第一客户端需要进行多语言文件回滚；在服务端侧的多语言文件版本与客户端侧的多语言文件版本一致的情况下，可以确定第一客户端不需要进行多语言文件更新或回滚。

其中，服务端确定客户端是否需要进行多语言文件更新或回滚的具体实现可以参见图2所示方法流程中的相关描述。

第一客户端在确定需要进行多语言文件更新的情况下，可以从服务端下载多语言更新文件，一方面，依据本地的自定义多语言文件生成多语言备份文件，例如，复制一份本地的自定义多语言文件作为多语言备份文件，以便在更新失败的情况下，可以依据该多语言备份文件实现回滚；另一方面，可以依据多语言更新文件更新本地的自定义多语言文件，并依据更新后的本地的自定义多语言文件刷新UI控件的显示内容。

示例性的，多语言文件(包括多语言更新文件、本地的自定义多语言文件或预置的多语言文件等)可以包括多个键值对(key-value)，key为预设的当前应用程序的需要使用的任一词条的唯一值，用于唯一标识该词条，value为该词条的译文。

举例来说，对于当前应用程序的需要使用到的任一词条，可以为该词条分配一个key唯一标识该词条，该key对应的value即为该词条的指定语种的译文，该译文可以包括预置的多语言文件中的缺省译文，或者，自定义多语言文件中的自定义译文。

以英译中为例，对于当前应用程序需要使用的任一英文词条，可以设置一个key，该英文词条的缺省中文译文或自定义中文译文即为该key对应的value。

对于多语言更新文件和本地的自定义多语言文件中均存在的key-value对(即key相同)，若value不同，则以多语言更新文件中的value为准；对于多语言更新文件中存在，但是本地的自定义多语言文件中不存在的key-value对，添加到本地的自定义多语言文件中；对于多语言更新文件中不存在，但是本地的自定义多语言文件中存在的key-value对，保持不变。

示例性的，在确定需要进行多语言文件回滚的情况下，可以使用多语言备份文件替换本地的自定义多语言文件，并依据替换后的本地的自定义多语言文件刷新UI控件的显示内容。

需要说明的是，上述实施例中是针对进行多语言文件回滚为回滚至上一个版本的情况下的实现说明，对于多语言文件回滚可以回滚多个版本的情况，例如，多语言文件的初始版本号为1.0，服务端进行第一次更新后版本号为1.1，进行第二次更新后版本号为1.2，服务端可以依据检测到的指令从1.2版本回滚至1.0回滚，针对这种情况，客户端从服务端处下载多语言更新文件，进行多语言备份文件更新的情况下，会将之前使用的旧版本的多语言文件均保存为多语言文件，在确定需要进行多语言文件回滚的情况下，可以依据回滚后的多语言文件的版本号，从保存的多语言备份文件中，获取版本号一致的多语言备份文件，并依据获取到的多语言备份文件进行多语言文件回滚。

示例性的，多语言版本文件的版本号随着服务端对多语言文件进行更新或回滚而更新，客户端侧自身单独对多语言文件进行的更新并不更新多语言文件的版本号。例如，客户端侧依据用户输入的自定义多语言编辑信息对目标UI控件的显示内容进行刷新的情况下，并不需要更新多语言文件的版本号。

示例性的，在确定不需要进行多语言文件更新或回滚的情况下，可以依据本地的自定义多语言文件刷新UI控件的显示内容。

示例性的，为了实现UI控件的显示内容的刷新，对于任一显示内容，可以依据该显示内容的key查询是否存在对应的自定义译文。

在存在对应的自定义译文的情况下，如上述更新后的本地的自定义多语言文件中存在该key对应的自定义译文、上述替换后的本地的自定义多语言文件中存在该key对应的自定义译文，或，存在该key对应的自定义译文中存在该key对应的自定义译文，可以将该显示内容更新为该自定义译文。

在不存在对应的自定义译文的情况下，可以依据预置多语言文件中的译文展示该显示内容。需要说明的是，在本申请实施例中，在客户端确定需要进行多语言文件回滚，但是本地不存在多语言备份文件的情况下，可以不需要进行回滚操作。

请参见图2，为本申请实施例提供的一种数据处理方法的流程示意图，其中，该数据处理方法可以应用于任一支持本申请实施例的技术方案的应用程序的服务端，如图2所示，该数据处理方法可以包括以下步骤：

步骤S200、接收客户端上报的自定义多语言编辑信息。

本申请实施例中，客户端向服务端上报自定义多语言编辑信息的具体实现可以参见上述方法实施例中的相关描述。

步骤S210、在确定满足升级条件的情况下，依据接收到的多语言编辑信息确定多语言更新文件。

步骤S220、依据多语言更新文件对相应客户端进行自定义多语言文件更新。

本申请实施例中，为了提高UI控件的显示内容的译文的准确性，使UI控件的显示内容的译文更贴合应用环境的语言习惯，服务端可以依据接收到的多语言编辑信息确定是否需要对UI控件的显示内容的译文进行统一更新(也可以称为升级)。

示例性的，在确定满足升级条件的情况下，服务端可以依据接收到的多语言编辑信息确定UI控件的显示内容的多语言更新文件，并依据该多语言更新文件对相应客户端进行自定义多语言文件更新。

例如，服务端在确定满足升级条件，并确定了多语言更新文件的情况下，可以更新多语言文件版本信息，从而，在依据本地多语言文件版本信息以及客户端的多语言文件版本信息确定客户端需要进行多语言文件更新的情况下，依据多语言更新文件对该客户端进行自定义多语言文件更新。

在一些实施例中，步骤S210中，确定满足升级条件，可以包括：

对于接收到的多语言编辑信息中的任一词条，依据接收到的多语言编辑信息，确定该词条对应的不同自定义译文的占比；

在占比最高的自定义译文的占比超过预设比例阈值的情况下，确定该词条满足更新条件；

在满足更新条件的词条的数量达到预设数量阈值的情况下，确定满足升级条件。

示例性的，服务端可以依据接收到的多语言编辑信息，统计接收到的多语言编辑信息中各词条对应的不同自定义译文的占比。

例如，假设服务端接收到的多语言编辑信息中，词条A对应的自定义译文1的数量为100(即存在100个客户端上报的多语言编辑信息中将词条A翻译为自定义译文1)，自定义译文2的数量为200，自定义译文3的数量为300，自定义译文4的数量为400(假设词条A共对应4种不同的自定义译文)，则针对词条A，自定义译文1、自定义译文2、自定义译文3和自定义译文4的占比依次为10％、20％、30％以及40％。

为了提高应用程序多语言化的译文的准确性，对于任一词条，在确定了对应的不同自定义译文中占比最高的自定义译文的情况下，可以先确定该占比最高的自定义译文的占比是否超过预设比例阈值(取值可以根据实际场景设定)，并在确定该占比最高的自定义译文的占比超过预设比例阈值的情况下，将该占比最高的自定义译文确定为该词条对应的目标自定义译文，以避免不同用户对同一UI控件的显示内容的自定义翻译的差异性较大的情况下，该UI控件的显示内容的译文被统一更新为不通用的译文的情况发生。

在一个示例中，服务端可以将该占比最高的自定义译文确定为该词条对应的目标自定义译文。

在另一个示例中，服务端可以该占比最高的自定义译文在指定界面中展示，由相关人员对该自定义译文进行确认，并在检测到确认指令的情况下，将该占比最高的自定义译文确定为该词条对应的目标自定义译文；在检测到针对该自定义译文的修改指令的情况下，依据修改指令对该自定义译文进行修改，并将修改后的自定义译文确定为该词条对应的目标自定义译文。

示例性的，服务端可以按照上述方式分别确定各词条是否满足更新条件，并统计满足更新条件的词条的数量，在满足更新条件的词条的数量达到预设数量阈值的情况下，确定满足升级条件。

需要说明的是，在服务端确定满足更新条件的词条的数量达到预设数量阈值的情况下，可以输出提示信息，以提示相关人员当前具备升级条件，并在检测到确认指令的情况下，确定满足升级条件。

在一个示例中，对于接收到的多语言编辑信息中的任一词条，依据接收到的多语言编辑信息，将该词条对应的占比最高的自定义译文确定为该词条对应的目标自定义译文，上述依据接收到的多语言编辑信息确定多语言更新文件，包括：

对于任一词条，在存在该词条对应的目标自定义译文的情况下，将该词条以及该词条对应的目标自定义译文的对应关系添加至多语言更新文件。

在一个示例中，上述接收客户端上报的自定义多语言编辑信息，可以包括：

接收客户端上报的自定义多语言编辑信息以及地区信息；

上述对于接收到的多语言编辑信息中的任一词条，依据接收到的多语言编辑信息，确定该词条对应的不同自定义译文的占比，可以包括：

依据自定义多语言编辑信息以及地区信息，确定相同地区的自定义多语言编辑信息；

对于任一地区的自定义多语言编辑信息中包括的任一词条，依据该地区的多语言编辑信息，确定该词条对应的不同自定义译文的占比；

上述在满足更新条件的词条的数量达到预设数量阈值的情况下，确定满足升级条件，可以包括：

对于任一地区，在该地区满足更新条件的词条的数量达到预设数量阈值的情况下，确定该地区满足升级条件。

示例性的，考虑到不同地区的语言习惯可能会存在区别，因此，为了保证自定义多语言的准确性，使其更贴合用户的语言习惯，在进行多语言文件更新的情况下，可以结合地区进行更新。

相应地，客户端在向服务端上报多语言编辑信息的情况下，还可以将客户端的地区信息也上报给服务端。

其中，客户端向服务端上报地区信息的相关实现可以参见图1所示方法流程中的相关描述。

示例性的，服务端在接收到客户端上报自定义多语言编辑信息，以及地区信息的情况下，可以依据地区信息，对不同地区的自定义多语言编辑信息进行统计，分别确定各地区各词条对应的不同自定义译文的占比。

对于任一地区，服务端可以统计该地区各词条对应的不同自定义译文的占比；对于任一词条，服务端可以确定该词条对应的占比最高的自定义译文，并在该占比最高的自定义译文的占比超过预设比例阈值的情况下，将该占比最高的自定义译文确定为该词条对应的目标自定义译文。

对于任一地区，在该地区满足更新条件的词条的数量达到预设数量阈值的情况下，可以确定该地区的多语言文件满足升级条件。

在一些实施例中，步骤S220中，依据多语言更新文件对相应客户端进行自定义多语言文件更新，可以包括：

接收客户端发送的状态查询请求，该状态查询请求中至少包括客户端的多语言文件版本信息；

依据客户端的多语言文件版本信息，以及本地的多语言文件版本信息，确定客户端是否需要进行多语言文件更新或回滚，并向客户端输出确定结果，该确定结果包括需要进行多语言文件更新、需要进行多语言文件回滚、不需要进行多语言文件更新或回滚中的一个。

示例性的，客户端向服务端发送状态查询请求的实现流程可以参见图1所示方法实施例中的相关描述。

示例性的，在服务端接收到客户端发送的状态查询请求的情况下，服务端可以获取该状态查询请求中携带的客户端的多语言文件版本信息，并依据该客户端的多语言文件版本信息，以及本地的多语言文件版本信息，确定客户端是否需要进行多语言文件更新或回滚。

示例性的，在服务端依据该客户端的多语言文件版本信息，以及本地的多语言文件版本信息，确定本地的多语言文件版本高于客户端的多语言文件版本的情况下，例如，服务端进行了多语言文件版本更新，但客户端尚未更新，服务端可以确定客户端需要进行多语言文件更新，并输出确定结果。

在服务端依据该客户端的多语言文件版本信息，以及本地的多语言文件版本信息，确定本地的多语言文件版本低于客户端的多语言文件版本的情况下，例如，服务端上一次进行多语言文件版本更新之后，相关人员确定此次更新需要撤销(如更新文件有错误)，并将服务端的多语言文件恢复至上一次更新之前的版本，在该情况下，对于上一次服务端更新多语言文件版本之后进行了多语言文件版本更新的客户端，该客户端上的多语言文件版本会高于服务端上的多语言文件版本，服务端可以确定客户端需要进行多语言文件回滚。

在服务端依据该客户端的多语言文件版本信息，以及本地的多语言文件版本信息，确定本地的多语言文件版本与客户端的多语言文件版本一致的情况下，服务端可以确定客户端不需要进行多语言文件更新或回滚。

在一个示例中，上述状态查询请求中还包括客户端的地区信息；

上述依据客户端的多语言文件版本信息，以及本地的多语言文件版本信息，确定客户端是否需要进行多语言文件更新或回滚，可以包括：

依据客户端的地区信息，从本地的多语言文件版本信息中，确定第二目标地区的多语言文件版本信息；其中，第二目标地区为与客户端的地区信息匹配的地区；

依据客户端的多语言文件版本信息，以及第二目标地区的多语言文件版本信息，确定客户端是否需要进行多语言文件更新或回滚。

示例性的，为了保证自定义多语言的准确性，使其更贴合用户的语言习惯，在进行多语言文件更新的情况下，可以结合地区进行更新。

相应地，客户端向服务端发送的状态查询请求中还可以携带客户端的地区信息。

服务端在接收到客户端发送的状态查询请求的情况下，可以获取该状态查询请求中的地区信息和多语言文件版本信息，并依据该地区信息，从服务端侧的多语言文件版本信息中，确定与客户端的地址信息匹配的地区(本文中称为第二目标地区)的多语言文件版本信息，并依据客户端的多语言文件版本信息，以及第二地区的多语言文件版本信息，确定客户端是否需要进行多语言文件更新或回滚。

其中，服务端依据客户端的多语言文件版本信息，以及服务端侧的多语言文件版本信息，确定客户端是否需要进行多语言文件更新或回滚的具体实现可以参见上一实施例中的相关描述。

为了使本领域技术人员更好地理解本申请实施例提供的技术方案，下面结合具体实例对本申请实施例提供的技术方案进行说明。

下面先对下文中出现的部分术语进行解释说明。

实施例一、用户自定义多语言流程

请参见图3，用户自定义多语言主要流程可以如图3所示，其可以包括以下步骤：

3.1、监听移动设备摇一摇或开启预设的支持用户自定义多语言配置的开关等操作指令。

3.2、在监听到步骤3.1中的操作指令的情况下，开启自定义模式，并将支持自定义多语言的UI控件蒙上一种提示性标记(如黄色方框等)。

3.3、在检测到针对UI控件的点击指令的情况下，对于不支持自定义模式的控件不做处理；对于支持自定义模式的控件，弹出可编辑的自定义多语言弹窗，编辑框显示当前使用的多语言翻译。

3.4、获取通过自定义多语言弹窗输入的自定义多语言编辑信息，尝试存储该条自定义多语言编辑信息。若存储失败，则不做任何修改，需要用户重新触发步骤3.3。若存储成功，则刷新该UI控件。

3.5、监听移动设备再次摇一摇或关闭预设的支持用户自定义多语言配置的开关等控制指令。

3.6、在监听到步骤3.5中的操作指令的情况下，关闭自定义模式，并去除UI控件上的提示性标记，复原UI控件。

3.7、在自动或询问用户的方式的情况下，将用户自定义多语言文件和地区信息上传回服务器。

示例性的，考虑到不同地区的语言习惯可能会存在较大区别，因此，对于自定义多语言译文的更新，可以结合地区信息进行。

相应地，在客户端需要上报自定义多语言文件的情况下，可以将自定义多语言文件和地区信息一起上传回服务器。

3.8、服务器依据地区信息和自定义多语言文件，进行大数据分析，选择贴合指定地区用户语言习惯的多语言进行升级维护。

实施例二、用户分享自定义多语言文件

请参见图4，用户分享自定义多语言文件的主要流程可以如图4所示，其主要包括以下步骤：

4.1、客户端A通过局域网(如隔空投送)或非局域网分享的方式，将其自定义的多语言文件分享给其他客户端，如客户端B。

示例性的，通过局域网分享的方式可以包括隔空投送、蓝牙、应用程序自建服务器等短距离封闭传输方式；非局域网分享的方式可以包括除通过局域网分享的方式之外的其它广域网分享方式，如通过邮件或即时通讯软件分享等。

4.2、客户端B导入客户端A分享的多语言文件后，刷新应用程序，即可获得客户端A自定义好的多语言。

实施例三、更新贴合用户语言习惯的多语言

请参见图5，更新贴合用户语言习惯的多语言的主要流程可以如图5所示，其可以包括以下步骤：

5.1、服务器根据某地区的用户上传的自定义多语言文件，统计各词条的键(即预定义的各词条的唯一标识)对应的不同值(即不同用户自定义的翻译)的占比情况，生成统计比对结果。

5.2、产品或运营等人员根据服务器生成的统计结果，优先使用占比高的翻译(可认为贴合该地区用户语言习惯)，结合其它考量，修改或直接使用服务器生成的统计比对结果。

5.3、生成多语言更新文件，并更新多语言文件更新检查接口的检查结果。

实施例四、APP更新/回滚多语言文件

请参见图6，APP更新/回滚多语言文件的主要流程可以如图6所示，其可以包括以下步骤：

6.1、APP客户端启动时向服务器发送状态查询请求，以请求检查多语言文件是否需要更新或回滚。

其中，该状态查询请求中携带有APP客户端的多语言文件版本号以及地区信息。

6.2、若无需处理，则执行步骤6.3。

6.3.读取多语言文件，并刷新UI控件。

6.4、若需要回滚，则先将多语言备份文件替换自定义多语言文件，并删除多语言备份文件，最后执行步骤6.3。

6.5、若需要更新，则先下载用户对应地区的多语更新言文件，之后将自定义多语言文件替换多语言备份文件，然后将多语言更新文件合并到自定义多语言文件，最后执行步骤6.3。

实施例五、SDK总体架构

请参见图7，SDK总体架构设计可以如图7所示，其中：

总体架构设计为UI层、LS(Local String，本地字符串)层、DB(DataBase，数据库)层的MVC(Model–View–Controller，模型-视图-控制器)三层结构。

其中，UI层对应MVC三层结构中的V，负责界面展示；LS层对应MVC三层结构中的C，负责模型与视图间的业务逻辑；DB层对应MVC三层结构中的M，负责提供数据。

7.1、UI层是支持自定义多语言的UI控件(如Text(文本)、Input(输入)、Button(按钮)等)。以及扩展的支持自定义多语言的一些属性和方法。

示例性的，iOS、Android分别采用运行时、注解&反射的方式扩展支持属性和方法，对于可视化布局文件分别采用IBInspectable(一种iOS布局文件自定义可视化属性的技术)、xmlns(XML Namespaces，一种Android自定义命名空间技术)的方式扩展支持属性。

7.2、LS层分为LSManager(LS管理器)和LSCache(LS缓存)。LSManager主要负责返回UI控件要显示的多语言，LSCache主要负责自定义多语言的内存缓存(Memory)、磁盘缓存(Disk)的存储和读取。

7.3、DB层由预置的多语言文件(Preinstall File)和用户自定义的多语言文件(DIY File)构成。

其具体工作流程可以如图8所示，包括以下步骤：

8.1、UI控件要显示多语言，首先根据待显示的词条的key向LSManager去获取对应的多语言值(即value)。

8.2、LSManager会根据key调用LSCache去获取多语言值。

8.3、LSCache会先判断内存缓存是否有对应的自定义值，若内存缓存有对应的自定义值，则返回给LSManager；若未缓存对应的自定义值，则去读取磁盘缓存。磁盘缓存有对应的自定义值，则返回给LSManager，并将磁盘缓存内容存储到内存缓存。

8.4、若LSCache中没有获取到自定义值，LSManager会去读取预置的多语言文件，并将多语言值返回给UI控件。

实施例九、自定义多语言编辑的交互流程

请参见图9，自定义多语言编辑的交互流程可以如图9所示，其可以包括以下步骤：

9.1、在检测到自定义多语言编辑指令的情况下，弹出可编辑自定义多语言弹窗。

9.2、获取通过可编辑自定义多语言弹窗输入的自定义多语言编辑信息，调用LSCache去存储自定义多语言，若磁盘缓存成功，则也会存储到内存缓存上，并刷新UI；若存储失败，则不做修改。

9.3、在检测到关闭自定义多语言编辑模式的指令的情况下，将用户自定义多语言文件上传回服务器，服务器根据该地区的自定义多语言情况，进行大数据分析，选择贴合该地区用户语言习惯的多语言进行升级维护。

以上对本申请提供的方法进行了描述。下面对本申请提供的装置进行描述：

请参见图10，为本申请实施例提供的一种数据处理装置的结构示意图，其中，该数据处理装置可以应用于上述实施例中的客户端，如第一客户端，如图10所示，该数据处理装置可以包括：

获取单元1010，用于获取自定义多语言编辑信息；所述自定义多语言编辑信息包括目标用户界面UI控件的显示内容的自定义译文；

处理单元1020，用于依据所述自定义多语言编辑信息刷新所述目标UI控件的显示内容，以使所述目标UI控件的显示内容更新为所述自定义译文；

发送单元1030，用于在确定满足多语言编辑信息上报条件的情况下，将所述自定义多语言编辑信息上报给服务端，以使所述服务端在确定满足升级条件的情况下，依据接收到的多语言编辑信息确定多语言更新文件，并依据所述多语言更新文件对相应客户端进行自定义多语言文件更新。

在一些实施例中，所述获取单元1010，具体用于在检测到针对所述目标UI控件的自定义多语言编辑指令的情况下，展示针对所述目标UI控件的多语言编辑界面；获取通过所述多语言编辑界面输入的自定义多语言编辑信息。

在一些实施例中，如图11所示，该数据处理装置还可以包括

模式控制单元1040，用于在检测到第一控制指令的情况下，进入自定义多语言编辑模式；所述第一控制指令用于控制所述第一客户端进入自定义多语言编辑模式；对支持自定义多语言编辑的UI控件进行突出显示；

所述模式控制单元1040，还用于在检测到第二控制指令的情况下，退出所述自定义多语言编辑模式，并取消对支持自定义多语言编辑的UI控件的突出显示；所述第二控制指令用于控制所述第一客户端退出自定义多语言编辑模式。

在一些实施例中，所述发送单元1030，用于将所述自定义多语言编辑信息，以及所述第一客户端的地区信息，上报给所述服务端，以使所述服务端在确定第一目标地区的多语言文件满足升级条件的情况下，依据接收到的多语言编辑信息以及地区信息，确定所述第一目标地区的多语言更新文件。

在一些实施例中，所述发送单元1030，还用于将所述自定义多语言编辑信息发送给第二客户端，以使所述第二客户端在对所述目标UI控件的显示内容进行展示的情况下，依据所述自定义多语言编辑信息展示所述自定义译文。

在一些实施例中，所述发送单元1030，还用于在所述第一客户端启动的情况下，向所述服务端发送状态查询请求，以使所述服务端依据所述第一客户端的多语言文件版本信息，确定所述第一客户端是否需要进行多语言文件更新或回滚；

所述处理单元1020，还用于在确定需要进行多语言文件更新的情况下，从所述服务端下载多语言更新文件，依据本地的自定义多语言文件生成多语言备份文件，并依据所述多语言更新文件更新本地的自定义多语言文件，依据更新后的本地的自定义多语言文件刷新UI控件的显示内容；或者，在确定需要进行多语言文件回滚的情况下，使用多语言备份文件替换本地的自定义多语言文件，并依据替换后的本地的自定义多语言文件刷新UI控件的显示内容；或者，在确定不需要进行多语言文件更新或回滚的情况下，依据本地的自定义多语言文件刷新UI控件的显示内容。

请参见图12，为本申请实施例提供的一种数据处理装置的结构示意图，其中，该数据处理装置可以应用于上述实施例中的服务端，如图12所示，该数据处理装置可以包括：

接收单元1210，用于接收客户端上报的自定义多语言编辑信息；

确定单元1220，用于在确定满足升级条件的情况下，依据接收到的多语言编辑信息确定多语言更新文件；

处理单元1230，用于依据所述多语言更新文件对相应客户端进行自定义多语言文件更新。

在一些实施例中，所述确定单元1220，具体用于对于所述接收单元接收到的多语言编辑信息中的任一词条，依据接收到的多语言编辑信息，确定该词条对应的不同自定义译文的占比；在占比最高的自定义译文的占比超过预设比例阈值的情况下，确定该词条满足更新条件；在满足更新条件的词条的数量达到预设数量阈值的情况下，确定满足升级条件。

在一些实施例中，所述确定单元1220，具体用于对于所述接收单元接收到的多语言编辑信息中的任一词条，依据接收到的多语言编辑信息，将该词条对应的占比最高的自定义译文确定为该词条对应的目标自定义译文；

在确定满足升级条件的情况下，对于任一词条，在存在该词条对应的目标自定义译文的情况下，将该词条以及该词条对应的目标自定义译文的对应关系添加至多语言更新文件。

在一些实施例中，所述接收单元1210，具体用于接收客户端上报的自定义多语言编辑信息以及地区信息；

所述确定单元1220，具体用于依据所述自定义多语言编辑信息以及地区信息，确定相同地区的自定义多语言编辑信息；对于任一地区的自定义多语言编辑信息中包括的任一词条，依据该地区的多语言编辑信息，确定该词条对应的不同自定义译文的占比；

所述确定单元1220，还具体用于对于任一地区，在该地区在满足更新条件的词条的数量达到第二预设数量阈值的情况下，确定该地区的多语言文件满足升级条件。

在一些实施例中，所述接收单元1210，还用于接收客户端发送的状态查询请求，所述状态查询请求中至少包括所述客户端的多语言文件版本信息；

所述处理单元1230，具体用于依据所述客户端的多语言文件版本信息，以及本地的多语言文件版本信息，确定所述客户端是否需要进行多语言文件更新或回滚，并向所述客户端输出确定结果，所述确定结果包括需要进行多语言文件更新、需要进行多语言文件回滚、不需要进行多语言文件更新或回滚中的一个。

在一些实施例中，所述状态查询请求中还包括所述客户端的地区信息；

所述处理单元1230，还用于依据所述客户端的地区信息，从本地的多语言文件版本信息中，确定第二目标地区的多语言文件版本信息；其中，所述第二目标地区为与所述客户端的地区信息匹配的地区；依据所述客户端的多语言文件版本信息，以及所述第二目标地区的多语言文件版本信息，确定所述客户端是否需要进行多语言文件更新或回滚。

本申请实施例还提供一种电子设备，包括处理器和存储器，其中，存储器，用于存放计算机程序；处理器，用于执行存储器上所存放的程序时，实现上文描述的数据处理方法。

请参见图13，为本申请实施例提供的一种电子设备的硬件结构示意图。该电子设备可包括处理器1301、存储有机器可执行指令的存储器1302。处理器1301与存储器1302可经由系统总线1303通信。并且，通过读取并执行存储器1302中与数据处理逻辑对应的机器可执行指令，处理器1301可执行上文描述的数据处理方法。

本文中提到的存储器1302可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：RAM(RadomAccess Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。

在一些实施例中，还提供了一种机器可读存储介质，如图13中的存储器1302，该机器可读存储介质内存储有机器可执行指令，所述机器可执行指令被处理器执行时实现上文描述的数据处理方法。例如，所述机器可读存储介质可以是ROM、RAM、CD-ROM、磁带、软盘和光数据存储设备等。

本申请实施例还提供了一种计算机程序，存储于机器可读存储介质，例如图13中的存储器1302，并且当处理器执行该计算机程序时，促使处理器1301执行上文中描述的数据处理方法。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。