“django-admin.py makemessages”中的错误 或 xgettext 调用? -> “警告:未终止的字符串”
在包裹很长字符串的情况下,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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我可以想到两种可能性:行尾的反斜杠后面可能有一个额外的空格; 或者您可能会以某种方式在源代码中得到错误的行结束字符(例如,当您的 Python 需要 Unix 风格时,则为 Windows 风格,从而禁用反斜杠)。
无论哪种方式,我都会利用 C 风格的自动字符串连接:
或者,如果您不介意换行符在那里结束,请使用多行字符串:
在我看来,它们看起来更好,并且在重构时更不容易脆弱。
这有帮助吗?
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:
Alternatively, if you don't mind newlines ending up in there, use multi-line strings:
IMO these look much nicer, and are much less fragile when refactoring.
Does this help?