Mon 24 Feb 2014 03:22:34 AM UTC, comment #3:
It doesn't cause me any hardship personally, since I just regexed the special case in the code that calls xgettext as part of my build process. The reason for the bug report is that poedit refuses to save a .po file generated from this .pot file.
Since marking a string incorrectly as containing brace formatting appears to break at least one translation tool, I though you should know about it.
The general solution to this problem would be to lift the python code that parses strings for brace formatting and use it (I'm fairly certain it would be implemented in C for performance). That way you would only mark strings as having brace formatting if python itself thought they had valid brace formatting. Which would mitigate the incidence of falsely marked strings. But that may be too much work.
Below is the quote from the poedit developer:
------------------------------------------------------------
Hi Paulo,
thanks, that helped. Unfortunately, it is a problem with the file from
calibre — it incorrectly marks this string as "python-brace-format”, which
means that portions of it enclosed inside {…} are treated specially and
the translation doesn’t fit what GNU gettext expects here.
I attached manually corrected PO file where I replaced it with
“no-python-brace-format”, but the problem will reappear if you ever use an
updated PO(T) file from calibre. The “real” fix, once for all, is to fix
it in calibre’s source code, in create_custom_column_ui.py. It may be a
good idea to mention this when sending the translation to them.
|