页面文案信息处理方法及电子设备与流程

1.本技术涉及信息处理技术领域，特别是涉及页面文案信息处理方法及电子设备。


背景技术：

2.页面的多语种展示是国际化服务中的重要一环。例如，对于涉及到跨境商品交易的电商服务平台而言，其网站中的页面可能会被多个不同国家的用户浏览，此时，就需要预先将页面中的文案翻译成多种不同的语种，以使得不同国家的用户可以在不同语种之间对页面进行切换展示。
3.但是，一个网站中通常会包括非常多的页面，不同的页面会对应不同的开发团队；一个页面中也可能会包括多个不同的功能模块组成，甚至这些不同的功能模块可能对应不同的开发团队，等等。具体页面或者功能模块涉及到的文案多语种翻译，通常依赖于开发团队对多语种展示的意识。也即，需要开发团队在对具体页面或功能模块开发完成后，主动与提供翻译服务的系统进行对接，获取到多个语种的文案翻译结果并进行保存，在需要以某个语种进行展示时，则可以读取对应语种下的翻译结果进行展示，以满足不同用户的多语种访问需求。但是，如果开发团队忘记进行文案翻译，或者，翻译时选择的语种太少，没有实现对多种常用语种的全覆盖，则可能会出现在按照某语种对该页面展示的过程中，某些文案并未展示成该语种，也即，存在“漏翻”的情况。另外，由于页面中的文案翻译往往依赖于翻译服务系统来自动实现，因此，也可能会出现“误翻”的情况，也即，部分文案内容在某语种下的翻译结果可能表达有误，等等。
4.为了解决页面中存在的上述“漏翻”或者“误翻”等情况，一种方式下，可以在页面发布前，对页面代码进行扫描检测，以此来避免该类问题上线。但是，由于发布、运营平台繁多，文案总会通过各种方式上线到页面中，因此，难以通过这种方式实现全面的巡查。另外，也难以从源头(例如，对开发人员进行约束等)上对“漏翻”或者“误翻”等问题进行避免。这就使得实际页面中“漏翻”或者“误翻”的现象频出，严重影响用户体验。


技术实现要素：

5.本技术提供了页面文案信息处理方法及电子设备，能够实现对页面文案翻译异常问题的巡查，同时减少用户终端侧需要上报的数据量。
6.本技术提供了如下方案：
7.一种页面文案信息处理系统，包括：
8.客户端，用于执行注入到目标页面中的页面脚本，以便在用户对所述目标页面进行访问的过程中，对所述目标页面的当前语种信息，以及页面中的文案信息进行采集，并上报到服务端，其中，所采集的文案信息包括：文案内容信息以及文案的附属信息，所述附属信息包括用于在所述目标页面中对所述文案进行唯一定位的信息；
9.所述服务端，用于根据所述当前语种信息对所接收到的文案内容是否存在翻译异常进行判断，并通过对多个用户对应的所述客户端上报的关于所述目标页面在同一语种下
的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理，并将其中属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中；
10.所述词库用于同步给所述客户端，以便在通过所述页面脚本在对所述目标页面进行文案采集时，仅对未命中所述词库的文案信息进行上报。
11.一种页面文案信息处理方法，包括：
12.确定目标页面关联的词库信息，所述词库用于保存多个词条的信息，所述多个词条的信息包括：所述目标页面中属于可治理类文案且在目标语种下不存在翻译异常的文案内容信息及其附属信息，和/或属于不可治理类文案的附属信息，所述附属信息包括用于在所述目标页面中对文案进行唯一定位的信息；
13.在用户对目标页面进行访问的过程中，对所述目标页面的当前语种信息以及页面中的文案信息进行采集；其中，所采集的文案信息包括：文案内容信息以及文案的附属信息；
14.将所采集到的文案信息与所述词库中的词条信息进行对比，将未命中所述词库的文案信息以及所述当前语种信息上报到服务端，以便由所述服务端根据所述当前语种信息对所接收到的文案信息是否存在翻译异常进行判断。
15.其中，还包括：
16.在所述目标页面关联的词库尚未被创建或者为空时，将所述用户终端侧采集到的文案信息进行全量上报到所述服务端。
17.其中，所述词库是由所述服务端通过以下方式生成并更新：通过对多个用户对应的客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理，并将其中属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中。
18.其中，所述对所述目标页面的当前语种信息以及页面中的文案信息进行采集，包括：
19.在所述用户终端侧开始对所述目标页面进行访问且尚未产生交互的状态下，对所述目标页面的当前语种信息以及页面中的文案信息进行采集；
20.通过对所述目标页面关联的文档对象模型dom的变化情况进行监测，感知用户的交互行为，以便在感知到用户产生交互行为时，对所述发生变化的节点上的文案信息进行采集。
21.其中，还包括：
22.如果在所述用户终端侧执行文案信息采集及上报任务的过程中，发生页面交互行为，并触发浏览器按照预置的帧率进行页面刷新，则将所述任务切分为多个子任务，以便以子任务为单位，将所述任务分散插入到多个相邻帧之间的页面绘制任务中的空闲时间执行。
23.其中，所述文案的附属信息包括文案对应的页面元素在目标页面dom中的路径信息；
24.所述方法还包括：
25.通过对页面交互行为引起的页面元素的路径信息变化情况进行监测，以保持对同一页面元素采集到的路径信息的唯一性。
26.其中，所述文案的附属信息还包括文案在所述目标页面中的位置坐标信息，以便所述服务端在识别出存在翻译异常的文案信息后，根据所述位置坐标信息，在所述目标页面中添加对应的框选标记。
27.其中，在对所述目标页面的当前语种信息以及页面中的文案信息进行采集之前，还包括：
28.通过对所述目标页面进行性能监测，确定所述目标页面中的元素抖动结束时机，以便在元素抖动结束后，触发对所述目标页面的当前语种信息以及页面中的文案信息的采集。
29.其中，还包括：
30.对所采集到的文案信息是否为隐藏元素对应的文案进行判断，如果是，则取消对该文案信息的上报。
31.其中，所述将所采集到的文案信息与所述词库中的词条信息进行对比，将未命中所述词库的文案信息以及所述当前语种信息上报到服务端，包括：
32.判断所述词库中是否存在与当前采集到的文案的附属信息对应的目标词条；
33.如果存在所述目标词条，并且所述目标词条对应的文案类别为可治理类，且当前采集到的文案内容与该目标词条中的文案内容一致，则将该采集到的文案确定为无需上报的文案；或者，如果存在所述目标词条，且所述目标词条对应的文案类别信息为不可治理类，则将该采集到的文案确定为无需上报的文案；
34.将除了所述无需上报的文案之外的部分文案，作为未命中所述词库的文案信息上报到服务端。
35.其中，还包括：
36.如果所述目标词条对应的文案类别为可治理类，且当前采集到的文案内容与该目标词条中的文案内容不一致，则对所述采集到的文案内容进行语种识别；
37.如果所述采集到的文案内容与所述目标页面的当前语种不一致，则为该文案内容添加翻译异常标识，并上报到服务端。
38.一种页面文案信息处理方法，包括：
39.接收客户端上报的关于目标页面采集到的当前语种信息以及文案信息，所述文案信息包括文案内容信息以及文案的附属信息，所述附属信息包括用于在所述目标页面中对所述文案进行唯一定位的信息；
40.根据所述当前语种信息对所接收到的文案内容是否存在翻译异常进行判断；
41.通过对多个用户对应的客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理；
42.根据所述目标页面中属于可治理类文案且存在翻译异常的文案，生成文案治理工单，以便对所述翻译异常进行治理；
43.将所述目标页面中属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中，所述词库用于提供给所述客户端，以便所述客户端在对所述目标页面进行文案
采集时，仅对未命中所述词库的文案信息进行上报。
44.其中，所述通过对多个用户对应的客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理，包括：
45.通过对不同用户在所述目标页面的同一位置处查看到的文案内容是否相同进行判断，并根据判断结果确定对应位置处的文案是否可治理。
46.其中，所述用户终端侧上报的文案信息还包括文案在所述目标页面中的位置坐标信息；
47.所述方法还包括：
48.在判断出存在翻译异常的文案信息后，根据所述位置坐标信息在所述目标页面中添加对所述文案信息的框选标记信息，以便在提供所述文案治理工单时，还提供所述框选标记信息。
49.其中，还包括：
50.根据所述目标页面的用户访问量、代码迭代频率和/或用户操作复杂度，控制所述目标页面的文案采集策略，以便所述用户终端侧按照所述文案采集策略执行文案的采集及上报逻辑；其中，所述文案采集策略包括文案采集的抽样率。
51.其中，所述根据所述目标页面的用户访问量、代码迭代频率和/或用户操作复杂度，控制所述目标页面的文案采集策略，包括：
52.根据所述目标页面在生命周期的不同阶段分别对应的用户访问量、代码迭代频率和/或用户操作复杂度，控制所述目标页面的文案采集策略。
53.一种页面文案信息处理装置，包括：
54.词库确定单元，用于确定目标页面关联的词库信息，所述词库用于保存多个词条的信息，所述多个词条的信息包括：所述目标页面中属于可治理类文案且在目标语种下不存在翻译异常的文案内容信息及其附属信息，和/或属于不可治理类文案的附属信息，所述附属信息包括用于在所述目标页面中对文案进行唯一定位的信息；
55.采集单元，用于在用户对目标页面进行访问的过程中，对所述目标页面的当前语种信息以及页面中的文案信息进行采集；其中，所采集的文案信息包括：文案内容信息以及文案的附属信息；
56.对比判断单元，用于将所采集到的文案信息与所述词库中的词条信息进行对比，将未命中所述词库的文案信息以及所述当前语种信息上报到服务端，以便由所述服务端根据所述当前语种信息对所接收到的文案信息是否存在翻译异常进行判断。
57.一种页面文案信息处理装置，包括：
58.文案信息接收单元，用于接收客户端上报的关于目标页面采集到的当前语种信息以及文案信息，所述文案信息包括文案内容信息以及文案的附属信息，所述附属信息包括用于在所述目标页面中对所述文案进行唯一定位的信息；
59.翻译异常判断单元，用于根据所述当前语种信息对所接收到的文案内容是否存在翻译异常进行判断；
60.文案类别识别单元，用于通过对多个用户对应的客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理；
61.工单生成单元，用于根据所述目标页面中属于可治理类文案且存在翻译异常的文案，生成文案治理工单，以便对所述翻译异常进行治理；
62.词库提供单元，用于将所述目标页面中属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中，所述词库用于提供给所述客户端，以便所述客户端在对所述目标页面进行文案采集时，仅对未命中所述词库的文案信息进行上报。
63.一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述任一项所述的方法的步骤。
64.一种电子设备，包括：
65.一个或多个处理器；以及
66.与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行前述任一项所述的方法的步骤。
67.根据本技术提供的具体实施例，本技术公开了以下技术效果：
68.通过本技术实施例，可以在客户端侧对目标页面进行文案信息的采集及上报，由服务端对接收到的文案信息进行识别，判断是否存在翻译异常问题。由于在多个用户对具体页面进行多次实际访问的过程中，是可以实现对页面中所有功能、全部操作路径的全覆盖，因此，可以能够获取到关于页面的全量文案的信息，进而完成对页面文案翻译异常的巡查。其中，在方案执行的初期，客户端侧可以对采集到的文案进行全量上报(或者，也可以根据预先配置的规则库，将无需多语种翻译的文案等进行过滤)，为了能够逐渐减少客户端侧上报的数据量，客户端侧上报的文案信息除了可以包括文案内容信息，还可以包括文案的附属信息，以用于对文案进行唯一定位；这样，服务端还可以通过对多个用户对应的客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，对所述目标页面中多个不同位置处的文案进行分类，确定出其中的可治理类文案，以及不可治理类文案；其中，对于可治理类文案，如果在具体目标页面中已经被正确翻译，则可以将该文案的文案内容信息以及对应的附属信息，加入到该目标页面的词库中，另外，还可以将不可治理类文案的附属信息也加入到词库中。这种词库可以提供给客户端，这样，客户端在具有这种词库后进行文案采集时，可以仅将未命中该词库的文案信息上传到服务端，也即，如果某位置处文案属于可治理类，并且已经在当前语种下被正确翻译且未发生变化，或者，如果某位置处的文案属于不可治理类，则都可以不必上传。总之，通过这种方式，可以实现对目标页面中存在的翻译异常问题的巡查，并且，还可以通过在目标页面维度上创建的词库的不断更新完善，而逐渐降低客户端侧上报的数量，也逐渐减少服务端侧的任务量。
69.其中，在客户端侧进行文案采集、上报的过程中，为了避免对页面的正常交互渲染造成影响，可以采用将任务进行切片后，分散插入到不同帧间页面绘制任务中的空闲时间执行，以免由于脚本的执行造成的页面卡顿等现象发生。
70.另外，还可以通过对采集时机的控制，以及对页面交互过程中引起的页面元素路径信息变化等情况进行监测等方式，来确保采集到的文案的附属信息的一致性及稳定性，以便于为后续服务端在使用这些信息进行文案类别的判断时，能够得到更准确的判断结果。
71.当然，实施本技术的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
72.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
73.图1是本技术实施例提供的系统架构的示意图；
74.图2是本技术实施例提供的文案区域类型统计示意图；
75.图3是本技术实施例提供的文案区域类型判断流程的示意图；
76.图4是本技术实施例提供的系统的示意图；
77.图5是本技术实施例提供的第一方法的流程图；
78.图6是本技术实施例提供的第二方法的流程图；
79.图7是本技术实施例提供的第一装置的示意图；
80.图8是本技术实施例提供的第二装置的示意图；
81.图9是本技术实施例提供的电子设备的示意图。
具体实施方式
82.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本技术保护的范围。
83.为了便于理解本技术实施例提供的具体实现方案，下面首先需要说明的是，本技术实施例中所述的“页面”并不是指通常所说的c端(消费者用户端)页面，而是开发视角的页面，通过同一份页面框架代码产出的页面可以视为同一页面，具体的，可以通过一些正则规则判断等方式对具有某种共同属性的多个c端页面进行抽象聚合得到的页面。例如，在电商服务系统中，开发者会提供“商品详情页”，在c端用户看来，不同商品对应不同的商品详情页，但是，在开发者视角看来，这些不同商品对应的商品详情页实际上属于同一页面的不同实例。
84.为了能够巡查出页面中存在的翻译异常(例如，“漏翻”、“误翻”等)问题，一种实现方式可以是巡检方式，也即，通过计算机模拟用户对页面的访问过程，以获取到页面在某语种状态下全量的文案，然后，判断是否存在翻译异常情况，然后由相关的开发、运营等人员对这种问题进行治理。但是，由于同一页面中包括的功能可能会有很多，另外，在不同的操作路径下也可能会呈现出不同的文案，因此，如果要获取到页面中的全量文案，通常需要对页面的各项功能非常了解，并模拟出用户所有可能的操作路径，这样才能枚举出所有可能出现的文案。但是实际上，这种方式通常是很难实现对页面文案的全面覆盖的。
85.针对上述问题，本技术实施例中，提供了直接将文案采集逻辑(具体可以是js脚本等形式)注入到具体页面中的方式来实现，这样，可以通过由客户端执行该脚本，实现在c端用户实际在访问页面的过程中进行相关文案信息的采集，具体的，可以由具体的js脚本对页面的当前语种信息进行采集，并对页面中的页面元素进行遍历，对于属于文案类别的各个元素，可以进行文案内容的采集。之后，可以将采集到的页面语种信息以及文案内容上报
到服务端，由服务端进行翻译异常问题的发现，并生成对应的工单并指派给对应的开发、运营、维护人员等，以便对页面中的文案翻译问题进行治理。也就是说，虽然单个c端用户的单次访问行为可能不能全面覆盖页面的全量文案，但是，在多个c端用户对同一页面执行的多次访问过程中，由于不同的用户在每次访问时，具体用到的页面功能、采用的操作路径等都可能是不同的，因此，可以通过多个c端用户的多次访问操作，实现对页面全量文案的覆盖。
86.具体实现时，由于页面中的文案类页面元素的数量可能会非常多，涉及到的具体文案内容也会非常多，如果每次都对页面中全部文案都上报到服务端，则端侧的处理开销可能会比较大，另外，对于服务端而言，每个端侧都上报大量文案数据，因此，服务端的处理开销会更大。但是，真正存在翻译异常的文案通常只是其中一少部分，因此，全量上传其实是没有必要的。
87.针对上述情况，本技术发明人在实现本技术的过程中发现，页面中的文案通常可以分为两种，一种属于框架文案，也即，由开发、运营等配置的文案，另一种属于ugc(user generated content，用户生产内容)文案。对于前者，属于页面固定文案，每个用户在同语种下看到的文案都是一样的；而对于后者，是跟随页面数据变动的文案，例如，商品详情页中的商品标题等。本技术实施例中在对页面中的文案翻译问题进行治理时，主要是由相关的开发、维护等人员对这种框架文案进行治理，而对于ugc文案，由于属于用户(主要是指商家等)生产的内容，不能由平台中的开发、维护等人员进行治理，因此，实际上属于不需要进行上报的文案。另外，对于页面中一些比较稳定的框架文案，如果能够确定出该文案在对应语种下是被正确翻译的，则也属于不必重复上报的文案，等等。
88.因此，本技术实施例中采用的处理方式是，在方案执行的初期阶段，由于尚未获取到关于具体页面中文案类别、翻译正确与否的知识，因此，c端确实可以上报比较大量的文案数据；但是，对于服务端而言，除了对c端上报的文案是否存在翻译异常问题进行识别，还可以对具体文案属于何种类别进行判断，并生成页面维度上的“词库”。也即，每种页面可以分别对应各自的“词库”，该词库可以用于确定具体页面在具体语种下已经被正确翻译的框架文案，另外还可以确定哪些文案属于ugc文案。这样，可以将这种词库提供给c端，c端在对页面元素进行遍历的过程中，在进行文案上报之前，可以首先基于这种词库进行判断，如果某文案属于在当前语种下已经被正确翻译的框架文案，或者ugc文案，则可以不必上报。这样，使得c端实际需要上报的文案只有可能存在翻译异常的框架文案。当然，在实际应用中，上述“词库”是逐渐完善的，c端需要上报的文案数量会随着“词库”的逐渐完善而逐渐减少。并且，逐渐可以由c端对“漏翻”的情况进行识别，并在上报的时候进行标记即可，而不必由服务端对该情况进行识别。
89.为了达到上述目的，对文案类别的识别是实现的关键一环。具体的，可以根据不同类别的文案在被不同用户访问时的不同表现特性来进行判断。例如，对于页面框架文案，其表现特性为：在不同用户访问时，这部分文案较为雷同，即同样的文案会被大量客户可见，且内容、相对位置相同或相似；而对于ugc文案，在同一相对位置，不同用户所见的内容通常是不同的。例如，如图2所示，假设三个用户在访问同一页面时，不同位置的文案内容在三个用户看来，可能会体现出三种不同情况，一种情况是“必现”，也即，同一语种下，所有用户都可见的文案内容；另一种是“偶现”，也即，同一语种下，部分用户可见的文案内容；还有一种是“仅现”，也即，同一语种下，仅一个用户可见的文案内容。其中，对于“必现”的文案内容，
通常就可以判定为框架内容；而对于“偶现”以及“仅限”的文案内容，则可以判定为“ugc”内容，等等。
90.因此，为了达到识别文案类别的目的，c端在上报文案时，除了上报具体文案内容之外，还可以上报具体文案的附属信息，具体的附属信息可以是用于对具体页面元素进行定位的信息，例如，具体可以包括元素在dom(document object model，文档对象模型，它提供了对文档结构化的描述，并将页面与脚本、程序语言联系起来，其中每一个元素看成一个节点)树中的路径(path)信息等，以用于确定元素在页面中的位置。元素位置也即文案的位置，当元素位置的生产保持了唯一性和稳定性后，即可通过这种方式进行对多个用户对应的客户端侧上报的数据进行处理，确定出页面中哪些属于框架文案，哪些属于ugc文案。具体的，服务端可以通过对比同一页面在被不同用户访问时，同样路径的元素对应的文案内容是否相同，来确定该路径对应的元素上的文案内容是属于框架文案，还是ugc文案。服务端端在识别出框架文案后，可以对文案进行语种打标，并同步至云词库，与采集时的附属信息-页面语种进行匹配，即可判定出漏翻文案。对于漏翻文案，可以根据对应的附属信息等，标记出在页面中的位置，还可以通过页面截图等方式进行保存，并生成对应的治理工单，由对应的开发、维护等人员对具体的漏翻问题进行治理。另外，服务端还可以通过相关的算法对误翻问题进行识别。其中，为了便于服务端对存在问题的文案内容进行标记，客户端侧在上报文案信息时，除了可以采集文案的path信息，还可以采集文案在页面中的位置坐标信息，这样，服务端在发现某文案内容存在异常后，则可以直接根据客户端侧上报的位置坐标信息对文案内容进行框选，例如，添加“矩形框”等。
91.具体实现时，由于客户端侧上报的文案信息具体可以包括文案内容以及附属信息，因此，可以将文案内容与附属信息组合为文案单元形式进行表达，每条文案信息可以对应一个文案单元。也即，一个文案单元中可以存储相关具体的文案信息以及附属信息。其中，由于附属信息是与元素在dom中的path相关，因此，也可以称为文案的dom信息。
92.其中，具体实现时，为了便于进行dom元素的定位，还可以为具体的dom信息生成“dom指纹”(也即，可以通过md5(message-digest algorithm 5,信息摘要算法)等算法，将dom信息转换为一个字符串)，dom指纹就可以作为能够唯一标记一类dom元素的id。以dom指纹作为唯一标记，可用于文案的所处位置进行定位。
93.另外，具体元素上的文案内容也同样可以用“文案指纹”(同样可以通过md5等算法将文案原文转换为一个字符串，等等)进行标记，也即，一条文案可以对应一个文案指纹。这样，对于一个文案单元而言，可以由“文案指纹+dom指纹”进行标记，具体存储的信息是具体的文案内容以及path、位置等信息。具体的客户端侧在进行文案信息上报时，就可以是以文案单元为单位进行上报。其中，在已经存在具体页面对应的词库的情况下，客户端侧在遍历具体dom中的节点的过程中，在遍历到每个节点，并取出其中的文案内容、path、位置等信息后，可以与词库中的信息进行对比，判断是否为ugc文案，或者已经在当前语种下被正确翻译的框架文案，如果都不是，则可以进行上报。也即，客户端侧实际上报的可以是：通过词库判断出来的可能存在翻译异常问题的框架文案。服务端在收到具体客户端侧上报的文案单元信息后，可以基于文案单元的“文案指纹+dom指纹”标记，与其他客户端侧上报的文案单元信息进行比对，判断是属于框架文案还是ugc文案。具体的，不同用户对应的客户端侧使用的指纹生成算法都是相同的，因此，如果是相同的文案原文、相同的dom信息，则对应生成
的文案指纹、dom指纹也会是相同的。如果某两个用户的客户端侧上报的文案单元中，同样的dom指纹对应了不同的文案指纹，则可以证明这两个用户在页面中该dom指纹对应的位置出看到的文案原文是不同的，这种就可能属于ugc文案。
94.也就是说，具体在进行文案类别识别时，如图3所示，可以由服务端在收到多个客户端侧上报的文案单元数据后，根据各个文案单元中的文案指纹、dom指纹、页面指纹，以及当前语种信息，对不同客户端侧上报的数据进行时间周期聚合，并根据不同用户访问页面的同一区域位置时，对应的文案内容是否相同等，对区域类型进行判断。例如，可以包括前述必现、偶现、仅现等多种类型。之后，可以根据区域类型确定出出现在该区域的文案的类别，也即，对于必现类型对应的区域，其中的文案属于框架文案；对于偶现或者仅现的区域内出现的文案，则可以判定为ugc文案，等等。
95.这里需要说明的是，在具体的页面中，还可能存在一些文案是不需要进行多语种翻译的，例如，一些页面的文字logo(标志)，或者货币符号(例如，￥、$等)等。因此，除了可以为客户端侧提供上述词库，以使得客户端侧对具体是否需要对某文案单元进行上报做出判断之外，还可以为客户端侧提供相关的规则库，以用于对上述特殊情况进行配置。其中，由于具体的文案是否属于前述不需要多语种翻译的内容，还与具体文案出现的位置有关，也即，同样一条文案，在页面中不同位置出现时，其含义可能是不同的，是否需要翻译也是不同的。因此，这种规则库中可以保存以下信息：页面+文案+文案所属的ui区域，通过这种方式来唯一标定一段具体文案，并予以规则配置，例如，具体配置的规则就可以包括是否需要上报，等等。对于这种规则库，是可以在方案执行初期就配置到客户端侧的，也即，在客户端侧还没有相关的词库可用时，就可以首先基于这种规则库过滤掉一些不需要上报的文案单元。
96.以上对本技术实施例提供的方案的整体实现框架进行了介绍，从整体上看，如图1所示，可以包括客户端侧的文案采集上报、服务端的文案类别识别、翻译异常识别(包括语种识别等，以识别漏翻、错翻等问题)、词库生成/更新等步骤，其中，生成的词库又可以提供给客户端侧，用于在进行文案采集上报时，对是否需要上报进行判断，以逐渐减少客户端侧上报的文案数量。
97.其中，具体在客户端侧进行文案采集上报过程中，还涉及到一些细节问题，下面进行介绍。如前文所述，对于页面文案的采集，可以通过页面中注入的js等脚本来实现，具体的实现逻辑包括遍历dom树中的各个节点，其中的识别文本节点，文案附属信息的采集，对文案进行上报等；在已经生成具体页面对应的词库、规则库的情况下，还需要进行词库、规则库的查询匹配，以判断出具体是否需要针对某文案单元进行上报。可见，该脚本需要完成的任务量还是很大的。而脚本的执行是阻塞ui渲染交互的，也即，在执行脚本的过程中，浏览器的渲染交互会暂停，但是，如果暂停时间过长，则可能会使得页面出现卡顿等现象，影响用户体验。因此，如何在通过脚本执行来完成各项任务的前提下，避免影响页面正常的渲染交互，是需要考虑的。
98.针对上述问题，首先可以解决节点的遍历效率问题，具体的，可以通过编写遍历代码来实现，或者，也可以使用浏览器原生api(application programming interface，应用程序编程接口)来实现。例如，浏览器原生支持的nodeiterator api document.createnodeiterator()、document.treewalker等都可快速支持遍历。
performance observer就可以用于对页面的性能进行监测，其中对的layout-shift可以有效的用来判定页面元素抖动的结束时机。
105.再者，关于元素的path信息，在用户与页面发生交互时，元素的path信息也可能会发生变化。例如，在鼠标hover(悬停)在某元素上时，可能会产生新的class属性，元素的xpath定位可能发生变化，等等。而本技术实施例中，需要根据元素的path信息对文案进行定位，因此，可以排出掉hover、点击等交互时带来的元素属性变化的影响，以免同一元素产生不同path。具体实现时，可以采用浏览器api
–
mutation observer，对影响元素path定位的属性进行监听，过滤动态属性变化，也就是说，对于一个元素而言，其path信息以第一次获取到的path信息为准，后续在交互过程中，即使同一元素的path信息发生变化，也不会进行重新采集，以此保持元素path生成逻辑的一致性和唯一性。
106.此外，页面中还可能会包括一些隐藏元素，例如，当页面在实现下拉、菜单等逻辑时，可能出现某些元素在dom中存在，但实质并未展示给用户的现象。对于该类文案，可以作为无效文案，取消采集。具体对于隐藏元素的判定，一种简单的方式可以是判断其style visible属性。不过前端实现元素隐藏的方案较多，如附带遮盖元素等，因此，还可以通过浏览器api-intersection observer的方式，从视口角度算出元素的展示区域占比，通过这种方式可以实现对隐藏元素的识别(例如，可以根据元素露出在窗口可视范围内的占比小于某阈值时，可以视为隐藏元素，等等)。
107.基于上述介绍，下面分别从多个不同角度，对本技术实施例提供的方案进行介绍。
108.实施例一
109.如前文所述，具体实现时，可以涉及到页面脚本，以实现用户终端侧的文案采集上报等逻辑，另外还可以涉及到服务端侧，以用于进行语种识别，文案类别识别，以及生成/更新词库等逻辑。因此，在该实施例一中，主要从上述页面脚本以及服务端组成的系统的角度，提供了一种页面文案信息处理系统，参见图4，该系统具体可以包括：
110.客户端401，用于通过执行注入到目标页面中的页面脚本，在用户对所述目标页面进行访问的过程中，对所述目标页面的当前语种信息，以及页面中的文案信息进行采集，并上报到服务端402，其中，所采集的文案信息包括：文案内容信息以及文案的附属信息，所述附属信息包括用于在所述目标页面中对所述文案进行唯一定位的信息；
111.所述服务端402，用于根据所述当前语种信息对所接收到的文案内容是否存在翻译异常进行判断，并通过对多个用户对应的所述客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理，并将其中属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中；
112.所述词库用于同步给所述客户端，以便通过所述页面脚本在对所述目标页面进行文案采集时，仅对未命中所述词库的文案信息进行上报。
113.在该实施例一中，主要是从整体角度对本技术实施例提供的具体实现方案进行了介绍。这里需要说明的是，具体的目标页面可以是任意具有多语种展示需求的页面。另外，如前文所述，从开发视角而言，具体的页面可以是一类c端页面的聚合，例如，关于商品详情页，在c端用户看来，是具体一件件商品的商品详情页，不同商品对应着各自不同的商品详情页，但是从开发视角而言，这些不同商品的商品详情页实际上是由同一份页面框架代码
生成的，因此，属于同一页面，只要向该同一份页面框架代码中注入具体的页面脚本，即可实现对页面中的文案进行采集上报等功能。
114.另外需要说明的是，在本技术实施例中，是在客户端侧，在用户实际访问具体目标页面的过程中，进行文案信息的采集以及上报；但具体实现时，可以并不是对每个用户的每次访问过程都进行采集及上报，而是可以按照一定的抽样率来执行。其中，对于不同的目标页面而言，具体采用的抽样率也可以不同。
115.具体实现时，由于客户端侧的文案采集主要是用于发现页面中可能存在的翻译异常问题，需要从不同的用户对应的客户端进行大量的采集，才能使得采集到的数据达到稳定可靠的状态。但是，要是页面文案达到数据稳定可信，还需要考虑到两个关键因素：页面的迭代更新、数据量大小。对于不同页面而言，从“流量”和“操作复杂性”角度来看，没有一个固化的抽样率是能够完全适配的，因此，可以通过有弹性的计算方式来执行。
116.例如，在电商服务系统中，典型的页面类型包括会场活动页、中后台页面、文章类页面等。其中，会场活动页属于功能迭代比较快的页面，文章类页面属于页面结构比较稳定，代码更新比较慢的页面，等等。其中，对于不同迭代速度的页面而言，可以采用不同的抽样率，例如，对于上述页面结构比较稳定，代码更新比较慢的页面，其抽样率可以逐渐下降，而对于迭代速度比较快的页面而言，则可以采用较高的抽样率，也更及时地发现页面中可能存在的翻译异常问题。
117.另外，即使对于同一页面，在不同的时期也可以采用不同的采集策略(主要是指抽样率等)。为了保障数据的实效性，避免由于代码变更导致的数据变化，具体的采集策略也可以伴随一个完整的生命周期而进行调整。例如，对于一个页面而言，其生命周期可能会包括多个不同的阶段，分别为流量观察期、稳定迭代期、变更观察期、变更稳定期等。一种具体实现方式下，各自对应的采集策略可以分别为：
118.流量观察期：采用固化的采集方案，适配不同流量、不同操作复杂性的场景页面；
119.稳定迭代期：稳定迭代期顾名思义，即页面文案数据趋于稳定，因此，也可以采用比较稳定的采集策略；
120.变更观察期：应用发布，代码变更等会导致文案部分失效、位置开始变化，该阶段应动态调整采集比例，还可以结合人工设置的交互链路策略等进行调整；
121.变更稳定期：变更后，再次进入稳定，该阶段可以观察一段时间，并清理历史淘汰的数据，然后可以逐渐进入到稳定的采集策略。
122.这里需要说明的是，关于具体页面脚本sdk(software development kit，软件开发工具包)可以通过nginx(是一个高性能的http(hyper text transfer protocol，超文本传输协议)和反向代理的web服务器)完成动态注入，这样能够最小限度的影响页面。在这种情况下，具体生命周期的管控也可以可托管到该nginx服务器进行统一控制。
123.另外需要说明的是，在本技术实施例中，具体从客户端侧采集的文案数据，可以称为“观察集”，也即，从该“观察集”中的数据来发现具体页面中哪些文案属于比较稳定的、已经正确翻译的框架文案(关于框架文案，也可以有其他的命名方式，在本技术实施例中统一称为可治理类文案)，哪些属于不需要进行治理的ugc文案(对应本技术实施例中的不可治理类文案)，等等。在文案数据观测稳定后，可以从不同的页面维度，沉淀出翻译正确的框架文案-语种、和/或ugc文案所对应的path等信息(不需要保存ugc文案的文案内容)组成的集
合，且数据趋于稳定，也就是形成了“词库”的概念(或者，也可以称为术语库，由于其中包括了页面中已经翻译正确的文案的信息，因此，也可以称为“正确集”)。其中，不同的页面可以对应不同的词库，这中词库可以被离散到页面维度，同步至客户端侧，以便具体脚本在采集文案的过程中，可以将命中词库的文案取消上报，从而将有效的减少上报的数据量。
124.另外，在形成了页面维度的词库的情况下，还可以可将文案的问题识别过程从离线的服务端识别转移到客户端侧，也即在客户端侧，基于词库进行端侧计算，判定文案“漏翻”、“误翻”问题，这样，在终端侧进行文案上报时，还可以带有对文案翻译异常问题的识别结果。例如，对于“漏翻”问题，在存在词库的情况下，可以在客户端侧比较容易地被识别出来，此时，可以将识别到的存在该问题的文案添加对应的标记后再上传到服务端。而对于“误翻”问题，可能具有更高的识别难度，则可以直接上报到服务端，由服务端的相关算法进行具体的识别。这种方式将大幅减少服务端的离线数据压力，进一步提升方案的泛用性。
125.此外，如前文所述，由于具体页面中可能还会存在一些诸如“logo”、货币符号等不需要进行多语种翻译的文案，因此，除了前述“观察集”、“正确集”之外，还可以存在“规则集”。具体的，该规则集可以是由页面的开发、运营等人员进行配置，具体可以以“页面+文案+文案所属的ui(user interface，用户界面)区域”等方式唯一标定一段具体文案，并予以规则配置。
126.总之，可以在客户端侧对目标页面进行文案信息的采集及上报，由服务端对接收到的文案信息进行识别，判断是否存在翻译异常问题。由于在多个用户对具体页面进行多次实际访问的过程中，是可以实现对页面中所有功能、全部操作路径的全覆盖，因此，可以能够获取到关于页面的全量文案的信息，进而完成对页面文案翻译异常的巡查。其中，在方案执行的初期，客户端侧可以对采集到的文案进行全量上报(或者，也可以根据预先配置的规则库，将无需多语种翻译的文案等进行过滤)，为了能够逐渐减少客户端侧上报的数据量，客户端侧上报的文案信息除了可以包括文案内容信息，还可以包括文案的附属信息，以用于对文案进行唯一定位；这样，服务端还可以通过对多个用户对应的客户端侧上报的关于所述目标页面在同一语种下的文案信息进行统计，对所述目标页面中多个不同位置处的文案进行分类，确定出其中的可治理类文案，以及不可治理类文案；其中，对于可治理类文案，如果在具体目标页面中已经被正确翻译，则可以将该文案的文案内容信息以及对应的附属信息，加入到该目标页面的词库中，另外，还可以将不可治理类文案的附属信息也加入到词库中。这种词库可以提供给客户端侧，这样，客户端侧在具有这种词库后进行文案采集时，可以仅将未命中该词库的文案信息上传到服务端，也即，如果某位置处文案属于可治理类，并且已经在当前语种下被正确翻译且未发生变化，或者，如果某位置处的文案属于不可治理类，则都可以不必上传。总之，通过这种方式，可以实现对目标页面中存在的翻译异常问题的巡查，并且，还可以通过在目标页面维度上创建的词库的不断更新完善，而逐渐降低客户端侧上报的数量，也逐渐减少服务端侧的任务量。
127.实施例二
128.以上实施例一主要从整体系统的角度，对本技术实施例提供的方案进行了介绍，而在该实施例二中，主要从客户端侧的页面脚本的角度，提供了一种页面文案信息处理方法，参见图5，该方法具体可以包括：
129.s501：确定目标页面关联的词库信息，所述词库用于保存多个词条的信息，所述多
个词条的信息包括：所述目标页面中属于可治理类且在目标语种下不存在翻译异常的文案内容信息及其附属信息，和/或属于不可治理类文案的附属信息，所述附属信息包括用于在所述目标页面中对文案进行唯一定位的信息。
130.在该实施例二中，具体目标页面关联的词库信息可以是预先配置的，或者，也可以如实施例一所述，是由服务端根据已经收集到的文案信息创建并逐渐更新的。当然，还可以将上述两种方式相结合，也即，可以由页面的开发或者运营人员等为具体页面预先配置一些基础的词库，后续服务端在收集客户端侧上报的文案信息的过程中，再逐渐对词库进行更新完善，等等。
131.其中，在由服务端逐渐生成并更新词库的情况下，在方案执行的初期，可能尚未为具体页面创建词库，或者具体页面关联的词库可能是空的，此时，可以将客户端侧采集到的文案信息进行全量上报到服务端。这样，服务端可以通过对多个客户端侧上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理。例如，具体实现时，可以根据多个客户端侧上报的关于所述目标页面在同一语种下的文案信息，对不同用户在所述目标页面的同一位置处查看到的文案内容是否相同进行判断，以便根据判断结果确定对应位置处的文案是否可治理(例如，可以判断出是否属于框架文案或者ugc文案等)。之后，可以将其中属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中。
132.s502：在用户对目标页面进行访问的过程中，对所述目标页面的当前语种信息以及页面中的文案信息进行采集；其中，所采集的文案信息包括：文案内容信息以及文案的附属信息。
133.在获取到词库的情况下，可以在用户对目标页面进行访问的过程中，对所述目标页面的当前语种信息以及页面中的文案信息进行采集。其中，具体在采集的过程中，可以在所述客户端侧开始对所述目标页面进行访问且尚未产生交互的状态下，对所述目标页面的当前语种信息以及页面中的文案信息进行采集。另外，还可以通过对所述目标页面关联的文档对象模型dom的变化情况进行监测，感知用户的交互行为，以便在感知到用户产生交互行为时，对所述发生变化的节点上的文案信息进行采集。
134.另外，如果在所述客户端侧执行文案信息采集及上报任务的过程中，发生页面交互行为，并触发浏览器按照预置的帧率进行页面刷新，则将所述任务切分为多个子任务，以便以子任务为单位，将所述任务分散插入到多个相邻帧之间的页面绘制任务中的空闲时间执行。
135.其中，具体所需采集的文案附属信息可以包括文案对应的页面元素在dom中的路径(path)信息；此时，还可以通过对页面交互行为引起的页面元素的路径信息变化情况进行监测，以保持对同一页面元素采集到的路径信息的唯一性，避免由于交互情况对采集结果造成的扰动。
136.另外，具体采集的所述文案的附属信息还可以包括：文案在所述目标页面中的位置坐标信息，以便所述服务端在识别出存在翻译异常的文案信息后，根据所述位置坐标信息，在所述目标页面中添加对应的框选标记。在优选的方式下，在对所述目标页面的当前语种信息以及页面中的文案信息进行采集之前，还可以通过对所述目标页面进行性能监测，
确定所述目标页面中的元素抖动结束时机，以便在元素抖动结束后，触发对所述目标页面的当前语种信息以及页面中的文案信息的采集。
137.s503：将所采集到的文案信息与所述词库中的词条信息进行对比，将未命中所述词库的文案信息以及所述当前语种信息上报到服务端，以便由所述服务端根据所述当前语种信息对所接收到的文案信息是否存在翻译异常进行判断。
138.在采集到具体节点上的文案集之后，可以将所采集到的文案信息与所述词库中的词条信息进行对比，然后，可以将未命中所述词库的文案信息以及所述当前语种信息上报到服务端。也就是说，如果具体采集到的文案属于框架文案，并且在当前语种下已经被正确翻译且未发生变化，则不需要上报。或者，如果采集到的文案属于ugc文案，则也不需要上报。具体在对文案类别进行判断时，就可以依据词库中记录的各词条及其对应的path等附属信息来进行。例如，采集到的某文案的信息后，由于可以采集到文案的path信息，因此，可以从词库中判断是否存在与该path信息对应的词条，如果存在，则还可以确定出该path对应的类别，如果属于不可治理类，则可以直接取消对该采集到的文案的上报；如果属于可治理类，则可以判断当前采集到的文案的文案内容与词库中该path对应的文案内容是否一致(其中，如果词库中保存的是文案指纹，则可以将采集到的文案内容转化为文案指纹后再进行比对)，如果文案内容也一致，则证明该采集到的文案已经被正确翻译且未发生变化，则也可以取消对该文案的上报。反之，如果在确定出当前采集到的文案的path后，发现词库中不存在与该path对应的词条，则该文案可能是新增的尚未被服务端识别过的文案，或者，可能属于已经被服务端识别为存在翻译异常，但是相关的开发或者运营等尚未完成治理的文案，等等，因此，都属于需要上报的文案。
139.其中，对于需要上报的文案，如果词库中命中的目标词条对应的文案类别为可治理类，且当前采集到的文案内容与该目标词条中的文案内容不一致，则还可以在客户端侧对所述采集到的文案内容进行语种识别，如果所述采集到的文案内容与所述目标页面的当前语种不一致，则还可以为该文案内容添加翻译异常标识后再上报到服务端。
140.另外，还可以对所采集到的文案信息是否为隐藏元素对应的文案进行判断，如果是，则取消对该文案信息的上报。
141.实施例三
142.该实施例三是从服务端的角度，提供了一种页面文案信息处理方法，参见图6，该方法具体可以包括：
143.s601：接收客户端上报的关于目标页面采集到的当前语种信息以及文案信息，所述文案信息包括文案内容信息以及文案的附属信息，所述附属信息包括用于在所述目标页面中对所述文案进行唯一定位的信息；
144.s602：根据所述当前语种信息对所接收到的文案内容是否存在翻译异常进行判断；
145.s603：通过对多个用户对应的客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理；
146.s604：根据所述目标页面中属于可治理类文案且存在翻译异常的文案，生成文案治理工单，以便对所述翻译异常进行治理；
147.s605：将所述目标页面中属于可治理类文案且在对应语种下不存在翻译异常的文
案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中，所述词库用于提供给所述客户端，以便所述客户端在对所述目标页面进行文案采集时，仅对未命中所述词库的文案信息进行上报。
148.具体实现时，可以通过对不同用户在所述目标页面的同一位置处查看到的文案内容是否相同进行判断，并根据判断结果确定对应位置处的文案是否可治理。
149.其中，所述客户端上报的文案信息还可以包括文案在所述目标页面中的位置坐标信息，在判断出存在翻译异常的文案信息后，还可以根据所述位置坐标信息在所述目标页面中添加对所述文案信息的框选标记信息，以便在提供所述文案治理工单时，还提供所述框选标记信息。
150.另外，具体实现时，还可以根据所述目标页面的用户访问量、代码迭代频率和/或用户操作复杂度，确定所述目标页面的文案采集策略，以便所述客户端侧按照所述文案采集策略执行文案的采集及上报逻辑；其中，所述文案采集策略包括文案采集的抽样率。
151.具体的，还可以根据所述目标页面在生命周期的不同阶段分别对应的用户访问量、代码迭代频率和/或用户操作复杂度，确定所述目标页面的文案采集策略。
152.关于上述实施例二、三中的未详述部分内容，可以参见实施例一以及本说明书其他部分的记载，这里不再赘述。
153.需要说明的是，本技术实施例中可能会涉及到对用户数据的使用，在实际应用中，可以在符合所在国的适用法律法规要求的情况下(例如，用户明确同意，对用户切实通知，等)，在适用法律法规允许的范围内在本文描述的方案中使用用户特定的个人数据。
154.与实施例二相对应，本技术实施例还提供了一种页面文案信息处理装置，参见图7，该装置可以包括：
155.词库确定单元701，用于确定目标页面关联的词库信息，所述词库用于保存多个词条的信息，所述多个词条的信息包括：所述目标页面中属于可治理类文案且在目标语种下不存在翻译异常的文案内容信息及其附属信息，和/或属于不可治理类文案的附属信息，所述附属信息包括用于在所述目标页面中对文案进行唯一定位的信息；
156.采集单元702，用于在用户对目标页面进行访问的过程中，对所述目标页面的当前语种信息以及页面中的文案信息进行采集；其中，所采集的文案信息包括：文案内容信息以及文案的附属信息；
157.对比判断单元703，用于将所采集到的文案信息与所述词库中的词条信息进行对比，将未命中所述词库的文案信息以及所述当前语种信息上报到服务端，以便由所述服务端根据所述当前语种信息对所接收到的文案信息是否存在翻译异常进行判断。
158.具体实现时，该装置还可以包括：
159.全量上报单元，用于在所述目标页面关联的词库尚未被创建或者为空时，将所述客户端采集到的文案信息进行全量上报到所述服务端。
160.其中，所述词库是由所述服务端通过以下方式生成并更新：通过对多个用户对应的客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理，并将其中属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中。
161.具体的，所述采集单元具体可以用于：
162.在所述客户端开始对所述目标页面进行访问且尚未产生交互的状态下，对所述目标页面的当前语种信息以及页面中的文案信息进行采集；
163.通过对所述目标页面关联的文档对象模型dom的变化情况进行监测，感知用户的交互行为，以便在感知到用户产生交互行为时，对所述发生变化的节点上的文案信息进行采集。
164.其中，为了避免脚本执行过程对页面正常渲染交互造成的影响，该装置还可以包括：
165.任务分片处理单元，用于如果在所述客户端执行文案信息采集及上报任务的过程中，发生页面交互行为，并触发浏览器按照预置的帧率进行页面刷新，则将所述任务切分为多个子任务，以便以子任务为单位，将所述任务分散插入到多个相邻帧之间的页面绘制任务中的空闲时间执行。
166.其中，所述文案的附属信息包括文案对应的页面元素在目标页面dom中的路径信息；
167.所述装置还可以包括：
168.路径变化情况监测单元，用于通过对页面交互行为引起的页面元素的路径信息变化情况进行监测，以保持对同一页面元素采集到的路径信息的唯一性。
169.另外，所述文案的附属信息还包括文案在所述目标页面中的位置坐标信息，以便所述服务端在识别出存在翻译异常的文案信息后，根据所述位置坐标信息，在所述目标页面中添加对应的框选标记。
170.此时，该装置还可以包括：
171.页面抖动判断单元，用于在对所述目标页面的当前语种信息以及页面中的文案信息进行采集之前，通过对所述目标页面进行性能监测，确定所述目标页面中的元素抖动结束时机，以便在元素抖动结束后，触发对所述目标页面的当前语种信息以及页面中的文案信息的采集。
172.再者，该装置还可以包括：
173.隐藏元素判断单元，用于对所采集到的文案信息是否为隐藏元素对应的文案进行判断，如果是，则取消对该文案信息的上报。
174.其中，所述对比判断单元具体可以用于：
175.判断所述词库中是否存在与当前采集到的文案的附属信息对应的目标词条；
176.如果存在所述目标词条，并且所述目标词条对应的文案类别为可治理类，且当前采集到的文案内容与该目标词条中的文案内容一致，则将该采集到的文案确定为无需上报的文案；或者，如果存在所述目标词条，且所述目标词条对应的文案类别信息为不可治理类，则将该采集到的文案确定为无需上报的文案；
177.将除了所述无需上报的文案之外的部分文案，作为未命中所述词库的文案信息上报到服务端。
178.另外，该装置还可以包括：
179.语种识别单元，用于如果所述目标词条对应的文案类别为可治理类，且当前采集到的文案内容与该目标词条中的文案内容不一致，则对所述采集到的文案内容进行语种识
别；
180.标记单元，用于如果所述采集到的文案内容与所述目标页面的当前语种不一致，则为该文案内容添加翻译异常标识，并上报到服务端。
181.与实施例三相对应，本技术实施例还提供了一种页面文案信息处理装置，参见图8，该装置可以包括：
182.文案信息接收单元801，用于接收客户端上报的关于目标页面采集到的当前语种信息以及文案信息，所述文案信息包括文案内容信息以及文案的附属信息，所述附属信息包括用于在所述目标页面中对所述文案进行唯一定位的信息；
183.翻译异常判断单元802，用于根据所述当前语种信息对所接收到的文案内容是否存在翻译异常进行判断；
184.文案类别识别单元803，用于通过对多个用户对应的客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理；
185.工单生成单元804，用于根据所述目标页面中属于可治理类文案且存在翻译异常的文案，生成文案治理工单，以便对所述翻译异常进行治理；
186.词库提供单元805，用于将所述目标页面中属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中，所述词库用于提供给所述客户端，以便所述客户端在对所述目标页面进行文案采集时，仅对未命中所述词库的文案信息进行上报。
187.其中，所述文案类别识别单元具体可以用于：
188.通过对不同用户在所述目标页面的同一位置处查看到的文案内容是否相同进行判断，并根据判断结果确定对应位置处的文案是否可治理。
189.具体实现时，所述客户端侧上报的文案信息还包括文案在所述目标页面中的位置坐标信息；此时，该装置还可以包括：
190.框选标记单元，用于在判断出存在翻译异常的文案信息后，根据所述位置坐标信息在所述目标页面中添加对所述文案信息的框选标记信息，以便在提供所述文案治理工单时，还提供所述框选标记信息。
191.另外，该装置还可以包括：
192.策略控制单元，用于根据所述目标页面的用户访问量、代码迭代频率和/或用户操作复杂度，控制所述目标页面的文案采集策略，以便所述客户端按照所述文案采集策略执行文案的采集及上报逻辑；其中，所述文案采集策略包括文案采集的抽样率。
193.具体的，所述策略控制单元具体可以用于：
194.根据所述目标页面在生命周期的不同阶段分别对应的用户访问量、代码迭代频率和/或用户操作复杂度，控制所述目标页面的文案采集策略。
195.另外，本技术实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述方法实施例中任一项所述的方法的步骤。
196.以及一种电子设备，包括：
197.一个或多个处理器；以及
198.与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程
序指令在被所述一个或多个处理器读取执行时，执行前述方法实施例中任一项所述的方法的步骤。
199.其中，图9示例性的展示出了电子设备的架构，例如，设备900可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理，飞行器等。
200.参照图9，设备900可以包括以下一个或多个组件：处理组件902，存储器904，电源组件906，多媒体组件908，音频组件910，输入/输出(i/o)的接口912，传感器组件914，以及通信组件916。
201.处理组件902通常控制设备900的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件902可以包括一个或多个处理器920来执行指令，以完成本公开技术方案提供的方法的全部或部分步骤。此外，处理组件902可以包括一个或多个模块，便于处理组件902和其他组件之间的交互。例如，处理组件902可以包括多媒体模块，以方便多媒体组件908和处理组件902之间的交互。
202.存储器904被配置为存储各种类型的数据以支持在设备900的操作。这些数据的示例包括用于在设备900上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器904可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。
203.电源组件906为设备900的各种组件提供电力。电源组件906可以包括电源管理系统，一个或多个电源，及其他与为设备900生成、管理和分配电力相关联的组件。
204.多媒体组件908包括在设备900和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件908包括一个前置摄像头和/或后置摄像头。当设备900处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。
205.音频组件910被配置为输出和/或输入音频信号。例如，音频组件910包括一个麦克风(mic)，当设备900处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器904或经由通信组件916发送。在一些实施例中，音频组件910还包括一个扬声器，用于输出音频信号。
206.i/o接口912为处理组件902和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。
207.传感器组件914包括一个或多个传感器，用于为设备900提供各个方面的状态评估。例如，传感器组件914可以检测到设备900的打开/关闭状态，组件的相对定位，例如所述组件为设备900的显示器和小键盘，传感器组件914还可以检测设备900或设备900一个组件
的位置改变，用户与设备900接触的存在或不存在，设备900方位或加速/减速和设备900的温度变化。传感器组件914可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件914还可以包括光传感器，如cmos或ccd图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件914还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。
208.通信组件916被配置为便于设备900和其他设备之间有线或无线方式的通信。设备900可以接入基于通信标准的无线网络，如wifi，或2g、3g、4g/lte、5g等移动通信网络。在一个示例性实施例中，通信组件916经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件916还包括近场通信(nfc)模块，以促进短程通信。例如，在nfc模块可基于射频识别(rfid)技术，红外数据协会(irda)技术，超宽带(uwb)技术，蓝牙(bt)技术和其他技术来实现。
209.在示例性实施例中，设备900可以被一个或多个应用专用集成电路(asic)、数字信号处理器(dsp)、数字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。
210.在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器904，上述指令可由设备900的处理器920执行以完成本公开技术方案提供的方法。例如，所述非临时性计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。
211.通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例或者实施例的某些部分所述的方法。
212.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
213.以上对本技术所提供的页面文案信息处理方法及电子设备，进行了详细介绍，本文中应用了具体个例对本技术的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本技术的方法及其核心思想；同时，对于本领域的一般技术人员，依据本技术的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本技术的限制。

技术特征：
1.一种页面文案信息处理系统，其特征在于，包括：客户端，用于通过执行注入到目标页面中的页面脚本，在用户对所述目标页面进行访问的过程中，对所述目标页面的当前语种信息，以及页面中的文案信息进行采集，并上报到服务端，其中，所采集的文案信息包括：文案内容信息以及文案的附属信息，所述附属信息包括用于在所述目标页面中对所述文案进行唯一定位的信息；所述服务端，用于根据所述当前语种信息对所接收到的文案内容是否存在翻译异常进行判断，并通过对多个用户对应的所述客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理，并将其中属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中；所述词库用于同步给所述客户端，以便在通过所述页面脚本在对所述目标页面进行文案采集时，仅对未命中所述词库的文案信息进行上报。2.一种页面文案信息处理方法，其特征在于，包括：确定目标页面关联的词库信息，所述词库用于保存多个词条的信息，所述多个词条的信息包括：所述目标页面中属于可治理类文案且在目标语种下不存在翻译异常的文案内容信息及其附属信息，和/或属于不可治理类文案的附属信息，所述附属信息包括用于在所述目标页面中对文案进行唯一定位的信息；在用户对目标页面进行访问的过程中，对所述目标页面的当前语种信息以及页面中的文案信息进行采集；其中，所采集的文案信息包括：文案内容信息以及文案的附属信息；将所采集到的文案信息与所述词库中的词条信息进行对比，将未命中所述词库的文案信息以及所述当前语种信息上报到服务端，以便由所述服务端根据所述当前语种信息对所接收到的文案信息是否存在翻译异常进行判断。3.根据权利要求2所述的方法，其特征在于，所述词库是由所述服务端通过以下方式生成并更新：通过对多个用户对应的客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理，并将其中属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中。4.根据权利要求2所述的方法，其特征在于，所述对所述目标页面的当前语种信息以及页面中的文案信息进行采集，包括：在所述用户终端侧开始对所述目标页面进行访问且尚未产生交互的状态下，对所述目标页面的当前语种信息以及页面中的文案信息进行采集；通过对所述目标页面关联的文档对象模型dom的变化情况进行监测，感知用户的交互行为，以便在感知到用户产生交互行为时，对所述发生变化的节点上的文案信息进行采集。5.根据权利要求2所述的方法，其特征在于，还包括：如果在执行文案信息采集及上报任务的过程中，发生页面交互行为，并触发浏览器按照预置的帧率进行页面刷新，则将所述任务切分为多个子任务，以便以子任务为单位，将所述任务分散插入到多个相邻帧之间的页面绘制任务中的空闲时间执行。6.根据权利要求2所述的方法，其特征在于，
所述文案的附属信息包括文案对应的页面元素在目标页面dom中的路径信息；所述方法还包括：通过对页面交互行为引起的页面元素的路径信息变化情况进行监测，以保持对同一页面元素采集到的路径信息的唯一性。7.根据权利要求2所述的方法，其特征在于，所述文案的附属信息还包括文案在所述目标页面中的位置坐标信息，以便所述服务端在识别出存在翻译异常的文案信息后，根据所述位置坐标信息，在所述目标页面中添加对应的框选标记。8.根据权利要求2至7任一项所述的方法，其特征在于，所述将所采集到的文案信息与所述词库中的词条信息进行对比，将未命中所述词库的文案信息以及所述当前语种信息上报到服务端，包括：判断所述词库中是否存在与当前采集到的文案的附属信息对应的目标词条；如果存在所述目标词条，并且所述目标词条对应的文案类别为可治理类，且当前采集到的文案内容与该目标词条中的文案内容一致，则将该采集到的文案确定为无需上报的文案；或者，如果存在所述目标词条，且所述目标词条对应的文案类别信息为不可治理类，则将该采集到的文案确定为无需上报的文案；将除了所述无需上报的文案之外的部分文案，作为未命中所述词库的文案信息上报到服务端。9.一种页面文案信息处理方法，其特征在于，包括：接收客户端上报的关于目标页面采集到的当前语种信息以及文案信息，所述文案信息包括文案内容信息以及文案的附属信息，所述附属信息包括用于在所述目标页面中对所述文案进行唯一定位的信息；根据所述当前语种信息对所接收到的文案内容是否存在翻译异常进行判断；通过对多个用户对应的客户端上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理；根据所述目标页面中属于可治理类文案且存在翻译异常的文案，生成文案治理工单，以便对所述翻译异常进行治理；将所述目标页面中属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中，所述词库用于提供给所述客户端，以便所述客户端在对所述目标页面进行文案采集时，仅对未命中所述词库的文案信息进行上报。10.根据权利要求9所述的方法，其特征在于，所述通过对多个用户终端侧上报的关于所述目标页面在同一语种下的文案信息进行统计，判断所述目标页面中多个不同位置处的文案是否为可治理，包括：通过对不同用户在所述目标页面的同一位置处查看到的文案内容是否相同进行判断，并根据判断结果确定对应位置处的文案是否可治理。11.根据权利要求9所述的方法，其特征在于，所述用户终端侧上报的文案信息还包括文案在所述目标页面中的位置坐标信息；所述方法还包括：
在判断出存在翻译异常的文案信息后，根据所述位置坐标信息在所述目标页面中添加对所述文案信息的框选标记信息，以便在提供所述文案治理工单时，还提供所述框选标记信息。12.根据权利要求9所述的方法，其特征在于，还包括：根据所述目标页面的用户访问量、代码迭代频率和/或用户操作复杂度，控制所述目标页面的文案采集策略，以便所述用户终端侧按照所述文案采集策略执行文案的采集及上报逻辑；其中，所述文案采集策略包括文案采集的抽样率。13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求2至12任一项所述的方法的步骤。14.一种电子设备，其特征在于，包括：一个或多个处理器；以及与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行权利要求2至12任一项所述的方法的步骤。

技术总结
本申请实施例公开了页面文案信息处理方法及电子设备，所述方法包括：接收客户端上报的关于目标页面采集到的当前语种信息以及文案信息；对所接收到的文案内容是否存在翻译异常进行判断；根据多个用户对应的客户端上报的文案信息，确定对应位置处的文案是否可治理；根据所述目标页面中属于可治理类文案且存在翻译异常的文案，生成文案治理工单；将属于可治理类文案且在对应语种下不存在翻译异常的文案内容信息及其附属信息、和/或属于不可治理类文案的附属信息，保存到为所述目标页面创建的词库中，以便仅对未命中所述词库的文案信息进行上报。通过本申请实施例，能够实现对页面文案翻译异常问题的巡查，同时减少用户终端侧需要上报的数据量。侧需要上报的数据量。侧需要上报的数据量。


技术研发人员：胡兴 高海慧 赵明祥 高鹏 孟玉峰 潘晨笑
受保护的技术使用者：阿里巴巴（中国）有限公司
技术研发日：2023.04.24
技术公布日：2023/9/14