“django-admin.py makemessages”中的错误 或 xgettext 调用? -> “警告:未终止的字符串”

发布于 2024-07-24 23:38:37 字数 1157 浏览 6 评论 0原文

在包裹很长字符串的情况下,django-admin.py makemessages 会因错误“警告:未终止的字符串”而终止:

string = "some text \
          more text\
          and even more"

这些字符串甚至不需要翻译 - 例如 sql 查询字符串。 当我连接字符串时,问题就消失了,但结果看起来很难看,并且需要时间来连接它们......

有人遇到这样的问题吗? 您找到解决方法了吗?

我涉及以下版本的工具:

xgettext-0.17、gettext-0.17、django-1.0.2、python-2.6.2

有一个 ticket 解决此问题,但它已关闭,可能是因为该错误仅出现在组件版本的某些组合中。

编辑:找到问题根源 - xgettext 向 sterr 打印警告消息,django 将它们视为致命错误并退出。

xgettext 调用的返回状态为 0 - “成功”。 我想 django 应该认为它是成功的,而不是因为警告而退出。

有趣的是,如果需要翻译,xgettext 仍然会提取反斜杠包裹的字符串,但会在 stderr 中发出警告(“未终止的字符串”)和 .po 文件(“国际化消息不应包含`\ r' 转义序列")

xgettext 调用如下:

xgettext -d django -L Python --keyword=gettext_noop \
         --keyword=gettext_lazy --keyword=ngettext_lazy:1,2 \
         --keyword=ugettext_noop --keyword=ugettext_lazy \
         --keyword=ungettext_lazy:1,2 
         --from-code UTF-8 -o - source_file.py

从 django/core/management/commands/makemessages.py 调用

django-admin.py makemessages dies with errors "warning: unterminated string" on cases where really long strings are wrapped:

string = "some text \
          more text\
          and even more"

These strings don't even need to be translated - e.g. sql query strings.
The problem goes away when I concatenate the string, but the result looks ugly and it takes time to join them...

Does anyone have a problem like this? Have you found a way to fix it?

I have the following versions of the tools involved:

xgettext-0.17, gettext-0.17, django-1.0.2, python-2.6.2

There was a ticket on this issue, but it was closed probably because the error appears only in some combination of component versions.

EDIT: found the source of problem - xgettext prints warning messages to sterr and django takes them as fatal errors and quits.

return status of xgettext call is 0 - "success". I guess that django should recognize it as success and not quit because of warnings.

Interestinly xgettext still extracts backslash-wrapped strings if they need to be translated, but gives warnings in stderr ("unterminated string") and .po file ("internationalized messages should not contain the `\r' escape sequence")

xgettext call is the following:

xgettext -d django -L Python --keyword=gettext_noop \
         --keyword=gettext_lazy --keyword=ngettext_lazy:1,2 \
         --keyword=ugettext_noop --keyword=ugettext_lazy \
         --keyword=ungettext_lazy:1,2 
         --from-code UTF-8 -o - source_file.py

called from django/core/management/commands/makemessages.py

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

抚笙 2024-07-31 23:38:37

我可以想到两种可能性:行尾的反斜杠后面可能有一个额外的空格; 或者您可能会以某种方式在源代码中得到错误的行结束字符(例如,当您的 Python 需要 Unix 风格时,则为 Windows 风格,从而禁用反斜杠)。

无论哪种方式,我都会利用 C 风格的自动字符串连接:

>>> string = ("some text "
...           "more text "
...           "and even more")
>>> string
'some text more text and even more'

或者,如果您不介意换行符在那里结束,请使用多行字符串:

>>> string = """some text
...             more text
...             and even more"""

在我看来,它们看起来更好,并且在重构时更不容易脆弱。

这有帮助吗?

I can think of two possibilities: you might have an extra space after your backslash at the end of the line; or you might be somehow ending up with the wrong line-ending characters in your source (e.g. Windows-style when your Python is expecting Unix-style, thus disabling the backslashes).

Either way, I would take advantage of C-style automatic string concatenation:

>>> string = ("some text "
...           "more text "
...           "and even more")
>>> string
'some text more text and even more'

Alternatively, if you don't mind newlines ending up in there, use multi-line strings:

>>> string = """some text
...             more text
...             and even more"""

IMO these look much nicer, and are much less fragile when refactoring.

Does this help?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文