Mudlet: 修改时停止丢失翻译

创建于 2018-09-07  ·  28评论  ·  资料来源: Mudlet/Mudlet

问题摘要/请求功能描述:

我们最近对字符串进行了一些小的更新,甚至对字符串进行了评论。 将它们上传到 Crowdin 后,所有最近对这些字符串进行的翻译都消失了。 他们应该保持原样,或者至少给出决定的选择权。

重现问题的步骤/添加功能的原因:

  1. 将文件上传到 Crowdin,开始翻译
  2. 在 github 源码中修改翻译后的字符串
  3. 查看 Crowdin。 翻译没了!

错误输出/特征的预期结果

Crowdin 知识库对此进行了解释:

更新源文件
如果修改了某些源字符串,系统会显示一个包含这些字符串列表的对话框。 您将能够选择要保留哪些现有翻译而不进行更改或删除,以及是否要保留或删除批准。
crowdin

该部分专门讨论了通过 Crowdin 网站手动更新文件。
当更新的文件通过 github 集成到达时,这个对话如何开始?

额外信息,例如 Mudlet 版本、操作系统以及如何解决/实施的想法:

来自集合的示例西班牙语更改
1

西班牙语翻译“so”不见了。 在这种情况下,源字符串甚至没有改变,而只是字符串的注释。 在其他情况下,一个字符串很长(约 100 个单词),只有 1 个单词发生了变化,其余的保持不变。 当然,大部分译文还是有效的,所以不应该这样删掉。

翻译者仍然可以将“so”视为建议,如果他们努力再次单击每个字符串(包括那些尚未翻译的字符串),但该建议位于其他建议之间,甚至没有标记为“this has been之前这个字符串的翻译"

2

discussion i18n & l10n

最有用的评论

谢谢,感激:)我们会研究这个。

所有28条评论

知道如何补救吗? @crowdin

你在哪里划定保留或放弃翻译之间的界限?

对我来说,将翻译放回 TM 似乎是最好的,再次将其拉出非常容易,翻译人员可以决定是否要重新使用文本。

确切地说,需要为每个字符串单独绘制该线,就像 Crowdin 的屏幕截图所暗示的那样。

我欢迎翻译人员在从 github 提取字符串后开始弹出对话框的选项。

现在,他们甚至无法区分之前翻译了哪些字符串,以快速修复拉动问题。

我觉得每次修改都花几个小时研究哪些翻译被破坏是不合理的。

当使用 Qt 自己的语言学家(或者更确切地说lupdate )直接从源代码更新一堆特定于语言的.ts文件时, lupdate有一个选项:

          Drop all obsolete and vanished strings.

只有提供了该选项,才会导致未使用或过时 - 我认为CrowdIn正在处理评论中的更改 - 从.ts文件中清除字符串。 不知何故,我们需要让 CrowdIn 为我们这样做。 :祈祷:

重要的是,我不认为评论的更改(尽管消歧的更改可能不同)应该清除翻译 - 失去“已批准”状态可能是可以接受的,但不能被遗忘。

大家好,

请注意,在通过 CLI / API / GitHub 更新文件时,您也可以通过在存储在您的存储库中的配置文件 ( crowdin.yml ) 中指定update_option参数来保存修改后的字符串的翻译。

更多信息:
https://support.crowdin.com/configuration-file/#changed -strings-update

进行更改后,请暂停并恢复 Crowdin 中的集成以应用更改

希望这正是您所需要的!

感谢您的回复!

@Kebap你想要哪个选项?

多谢你们。 这太棒了。 将详细审查选项。

我想尝试“update_as_unapproved”选项,这似乎是一个很好的折衷方案:翻译保持不变,但失去其批准状态。

现在,当我对此进行测试时,它似乎不起作用。 字符串仍然丢失了翻译。 我什至增强了配置 yaml 文件的自动创建的简要布局,以便准确反映上面链接的知识库部分中给出的示例。

尽管如此,不幸的是,Crowdin 似乎只是替换了字符串,而不是保留它们的翻译并删除批准。 我做错了吗?

字符串以前有翻译和批准(批准似乎在 .ts 文件中不可见?)
image

更新选项“update_as_unapproved”用短和长 yaml 布局测试,结果相同
image

修改字符串(或评论)后,Crowdin 现在显示修改后的字符串,无需翻译和批准
image

Crowdin Diff 将字符串报告为“已删除并添加”而不是“保留但失去批准”
image

-- 请在此行上方回复 --

        Hi everyone,

看来问题是在您的项目中,您的文件是 .html 和
.ts。 这种类型的文件没有明确的KEY:VALUE结构,
因此,当您更新文件时,每个更改的字符串都是
视为新字符串。 这是系统的预期行为,
但我会问开发人员是否有什么可以做的
一旦他们在办公室的情况下!

你如何评价我的回复?
好 [1] 好 [2] 不好 [3]

--
真挚地,
奥尔加·库塔
客户成功经理

链接:

[1]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/1/
[2]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/2/
[3]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/3/

    > On Sat, Sep 8, 2018 at 1:34:23 EEST, Mudlet/mudlet <[email protected]> wrote:

我想尝试“update_as_unapproved”选项,这似乎是
很好的妥协:翻译保持不变,但失去了批准
状态。

现在,当我对此进行测试时,它似乎不起作用。 字符串仍然丢失
他们的翻译。 我什至甚至自动增强了
创建了配置 yaml [1] 文件的简要布局,以便
准确反映知识库 [2] 部分中给出的示例
上面链接。

尽管如此,Crowdin 似乎不幸地只是取代了
字符串,而不是保留它们的翻译并删除
赞同。 我做错了吗?

字符串以前有翻译和批准(批准似乎
在 .ts 文件中不可见?)
[3]

更新选项“update_as_unapproved”已经过短期和长期测试
yaml 布局,两者的结果相同
[4]

修改字符串(或评论)后,Crowdin 现在显示已修改
未经翻译和批准的字符串
[5]

Crowdin Diff 将字符串报告为“已删除并添加”而不是“保留但
失去了他们的认可”
[6]

-
你收到这个是因为你被提到了。
直接回复此邮件,在 GitHub [7] 上查看,或将其静音
线程 [8]。

链接:

[1] https://github.com/Kebap/Mudlet/blob/crowdin-test/.crowdin.yml
[2]
https://support.crowdin.com/configuration-file/#changed -strings-update
[3]
https://user-images.githubusercontent.com/117238/45245753-12b3a300-b2fe-11e8-819a-fbc1cab389cd.png
[4]
https://user-images.githubusercontent.com/117238/45245828-632b0080-b2fe-11e8-8457-d16f53e62976.png
[5]
https://user-images.githubusercontent.com/117238/45245723-e7c94f00-b2fd-11e8-831d-14f3c0151aa8.png
[6]
https://user-images.githubusercontent.com/117238/45245651-843f2180-b2fd-11e8-8744-b431244e39e8.png
[7]
https://github.com/Mudlet/Mudlet/issues/1961#issuecomment -419583856
[8]
https://github.com/notifications/unsubscribe-auth/AA0k1tqzDWWwb2qGudFk9ENRg7Hm3D-Hks5uYvRcgaJpZM4WeaRq

是的, Qt IDE使用 .ts 文件。 当然,这不是利基市场。 Crowdin 开发人员有什么建议吗?

Qt 的反馈没有定论:

(烤肉串)大家好! 有没有人使用过基于网络的服务网站来处理翻译和翻译? 我们使用 Crowdin,它们似乎不能很好地使用 Qt .ts 文件格式。 他们似乎认为每个修改过的字符串都是一个新字符串,并且会删除旧的翻译。 有关详细信息,请参阅以下线程。 我们如何解决这个问题? https://github.com/Mudlet/Mudlet/issues/1961
(frkleint) Kebap:我建议发布到http://lists.qt-project.org/mailman/listinfo/localization邮件列表
(Kebap)似乎该邮件列表是关于翻译 Qt 项目本身的。 然而,也许还有其他人使用 Qt 构建自己的项目并翻译成其他语言?
(frkleint) Kebap:是的,但是合适的维护者/人会阅读它

让我仔细检查所有细节,@Kebap。 我脑子里有一个“B计划”,但需要测试一下。

您可以将源文本/翻译存储在 .ts 文件的元素? 在里面例如,您可以有一个唯一的字符串 ID

目前,我们将包含源文本的文件mudlet.ts导入/上传到 CrowdIn,然后他们对其进行处理以生成mudlet_xx_YY.ts ,其中xx是两个字母的语言代码, YY是两个字母的国家代码。 我相信原始的mudlet.ts是使用 Qt lupdate实用程序生成/更新的,我认为它是从我们的源./translations目录运行的lupdate -locations absolute ../src/mudlet.pro -ts ./mudlet.ts {at至少来自 *nux OS}。

还有一种替代方法,但我不知道 CrowdIn 是否可以像我们提供单独的.ts文件那样工作(目前:

  • mudlet_de_DE.ts
  • mudlet_el_GR .ts`
  • mudlet_en_GB.ts
  • mudlet_es_ES.ts
  • mudlet_fr_FR.ts
  • mudlet_it_IT.ts
  • mudlet_nl_NL.ts
  • mudlet_pl_PL.ts
  • mudlet_ru_RU.ts
  • mudlet_zh_CN.ts
  • mudlet_zn_TW.ts

) 文件到 CrowdIn 并让它/翻译团队处理这些文件。 这意味着现有的翻译工作被保存在每个.ts文件中——这实际上是 Qt 设想的翻译方式——因为lupdate然后将使用更改更新每个单独的翻译文件运行时从代码源中提取但不会丢弃(除非使用-no-obsolete参数明确告知)不再出现​​在源中的旧文本。 这样做的缺点是所有翻译都没有一个文件,这可能会混淆/不适用于 CrowdIn系统。 好处是,#1963 立即成为一个非问题,因为我们可以生成仅复数形式的mudlet_en_US.ts文件,并在发布/版本/任何更改时将其包含在上传到 CrowdIn 中......

我认为 Crowdin 需要一个文件作为输入。 我记得在设置过程中它不喜欢多个文件 - 即问题是输入和输出文件相同。

虽然我们可以不同地命名输入和输出文件?

Crowdin 当然可以处理多个输入文件,如在不同的字符串中进行翻译。 然而在 SlySven 的计划中,它们都将具有相同的内容。 这意味着,即使是波兰语翻译团队也会看到所有文件,包括 mudlet_it_IT.ts 和 mudlet_ru_RU.ts 等。因此,我们没有继续沿着这条路走得更远,而是选择了一个中央翻译文件。

编辑:创建 .ts 文件的解释是正确的,但使用的真正命令是: lupdate -recursive .\src\ -ts .\translationsmudlet.ts

不知道你的意思是什么 Vadim,但我认为 Kebap 是在同一条轨道上 - 我们可以输入所有文件,但我们如何说/告诉 CrowdId只有mudlet_ru_RU.ts的集合应该显示给俄语(俄罗斯)翻译?

@vadi2没错,建议上传单个源文件,Crowdin 会自己生成翻译文件。

请不要将mudlet_ru_RU.ts之类的文件上传到项目中。

也许我们可以打电话进一步讨论这个问题? 请通过 andriy(at)crowdin.com 与我联系

我有一个想法肯定会奏效,但需要听听您是否对此感到满意。 问题是 .ts 没有每个字符串的唯一标识符 - 就像在 .po 中一样,其中msgid是源和标识符的文件相同, <source>也是文本和标识符(与<context><name>元素一起,每个字符串都被认为是唯一的,如果您修改<source> ,则该字符串被视为新字符串,您不能保留修改后的翻译结果中的字符串)。

无论如何,我想向您的团队讨论/演示一个非常好的解决方案/解决方法;)

...并且只有一些内容是相同的 - 来自源的文本 - 但是已经为每个语言环境完成的翻译也存储在它们各自的文件中,并且出现在每个后续的更新翻译周期中。

如果我理解它,唯一的消息标识符方案在 Qt 系统中也是允许的,但它更难使用 - 并且项目中间的更改是一项不平凡的任务(这两个系统是互斥的,你需要一个非常好的方法提出有意义的标识符)-现有方案的部分好处是重复的字符串确实会合并到一个通用的翻译中,只是改变一个需要其他的也改变,如果它们打算成为相同的...

当我们将一种语言中的所有字符串翻译成 100%,然后在一个版本中编辑一些字符串时,由于 TM,是否仍然很容易通过并重新添加它们?

这个问题似乎只是一个真正的问题,因为我们还没有达到 100%。

@vadi2如果您希望能够在 TM 的帮助下自动翻译新添加的字符串,您可以使用高级工作流程功能设置此类工作流程(我刚刚为您的帐户启用了它)
https://support.crowdin.com/advanced-workflows/

谢谢,感激:)我们会研究这个。

@Kebap写道:

编辑:创建 .ts 文件的解释是正确的,但使用的真正命令是: lupdate -recursive .\src\ -ts .\translationsmudlet.ts

-recursive是默认参数情况,不是必需的 -文件-locations absolute显然也是如此......:slightly_smiling_face: - 我只是在检查效果时发现了这一点lupdate仍然存在 C++11/14 原始字符串文字 { QTBUG , #1310} 的问题,以及字符串是否由于混淆而从mudlet.ts文件中丢失。 . :皱眉:

@Kebap这仍然是一个问题吗?

是的,尽管没有改变之前那么糟糕。 但它仍然令人困惑,即使对于发起者来说,正如您在一周前的链接问题中所看到的那样。

目前还有一些竞赛,而大多数语言还没有接近 100%,他们翻译字符串的速度会比他们再次松散翻译更快吗?

更重要的是,我发现了一个似乎恢复已删除翻译的问题。 目前我找不到从 Crowdin 中删除翻译的方法。 下次更新后会再次自动添加。

@Andrulko你有什么更新吗? 你在上面提到了B计划..

另外,为什么 Crowdin 现在会在 TM 中做出这种奇怪的行为!? 请参阅下面的屏幕截图进行比较。

我们在这里所做的只是将h3更改为a 。 没有触及其他标签。 现在发生了什么?

您是否希望翻译人员手动将每个{[=-lt;-=]}h2{[=-gt;-=]}{[=-lt;-=]}u{[=-gt;-=]}替换为<h2><u>或者更确切地说是<0>

示例链接: https ://crowdin.com/translate/mudlet/137/en-de
示例截图:
grafik

我认为这是 Crowdin TM 中的一个错误。 可能最好作为一个单独的问题向他们报告。

我也在这里通知了他们: https ://crowdin.com/contacts

您好,我们已经检查了您的请求并回复了您的邮件。 如果您有任何其他问题,请告诉我们!

此页面是否有帮助?
0 / 5 - 0 等级