-
Notifications
You must be signed in to change notification settings - Fork 453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hide extensive traceback from the user and show only relevant information #1049
Comments
Thank you for the comprehensive issue report! As an aside, Given Babel is fundamentally a technical tool aimed at somewhat technical users, I'd rather not try to smooth over the long error, lest we end up with a babel did an oopsie woopsie situation. I'd also rather not try to be clever about redacting the traceback, since more often than not it offers valuable clues as to what has actually gone wrong when an user reaches out to the Babel folks – asking the user to re-run the command with something like Not to shift blame but to clarify the situation, the actual error you're seeing here stems from Jinja, as it's trying to parse your template: You would get the same error without Babel in-between: >>> import jinja2
>>> from jinja2.ext import InternationalizationExtension
>>> e = jinja2.Environment(extensions=[InternationalizationExtension])
>>> e.from_string("{% trans %}Hello World{% trans %}")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.12/site-packages/jinja2/environment.py", line 1105, in from_string
return cls.from_code(self, self.compile(source), gs, None)
^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/jinja2/environment.py", line 768, in compile
self.handle_exception(source=source_hint)
File "/usr/local/lib/python3.12/site-packages/jinja2/environment.py", line 936, in handle_exception
raise rewrite_traceback_stack(source=source)
File "<unknown>", line 1, in template
jinja2.exceptions.TemplateSyntaxError: control structures in translatable sections are not allowed
>>> It would of course be useful if that Jinja syntax error noted the name of the control structure, e.g.
or better yet, for this particular case,
but that's not in Babel's control; adding logic that would sniff out this situation from a Jinja-specific exception and show it differently sounds brittle. To that end, I opened a PR in Jinja that makes these errors nicer. pallets/jinja#1918 |
Thank you for your answers! Appreciated your response.
Oh, I wasn't aware of that. 😲 Is there are replacement for pybabel? Anything you can recommend?
I see what you mean. I was looking at it from a pure user point of view. Thanks for opening an issue for the Jinja project. Maybe in this case, I better close this issue. Thanks for all your help! 👍 |
Oh no, what I mean is that the You install the
c.f. installing
(In fact, all that package contains is an empty |
Thanks for the clarification. Much appreciated. 👍 |
Overview Description
Thank you for all your efforts in creating and maintaining this project. 👍
Steps to Reproduce
Prepare the environment:
Create a Jinja2 template
test.html.jinja2
with the following wrong(!) content:Create a
babel.cfg
file with the following content:Extract the translatable strings
Actual Results
An (ugly) traceback shown to the user (as presented in step 4).
Expected Results
I'm aware that the
silent
keyword inbabel.cfg
leads to this kind of error. However, nevertheless I see an issue when showing the complete traceback to the user:All these points make it more difficult for the user to extract the relevant information.
In my opinion, a verbose traceback output should never be shown to the user unless there is really something fundamentally wrong. A syntax problem in a Jinja2 template should not lead to this extensive traceback output and should be condensed to the important information.
In other words, I expected something more user-friendly. 🙂
For example, pybabel should show the relevant information only which is:
Here is one idea how it could be shown to the user:
The real output is subject for another discussion. 😉 But I think you get the idea.
If you want to make it even more useful, suggest a solution to this problem:
The URL could point to a GitHub Wiki in your repo or the actual documentation. The content should show the most common problem and how to solve it. Each content should be consistent to each other and should have the same structure. For example:
Reproducibility
See above.
Additional Information
n/a
The text was updated successfully, but these errors were encountered: