Opened 10 years ago
Closed 10 years ago
#23840 closed Bug (fixed)
Confusing message from makemessages
Reported by: | Takis Issaris | Owned by: | Ilja Maas |
---|---|---|---|
Component: | Internationalization | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
When there's no locale dir available to store the gettext related messages the makemessages command complains with the following message:
CommandError: Unable to find a locale path to store translations for file db.sqlite3
If found the message rather confusing due to the messages referring to the database file, implying that something was going wrong and it was trying to find translatable strings in the sqlite database file.
Maybe it would be better if the filename wouldn't be mentioned?
Attachments (2)
Change History (10)
comment:1 by , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|
by , 10 years ago
Attachment: | makemessages.diff added |
---|
comment:2 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
While looking into patching this I found out some IMHO strange behaviour.
If no --extension or --domain is provided makemessages claims to be handling .txt and .html files ( via --verbosity=2 )
That is not really true as it is also handling all .py files.
Actually forcing --extension=html also gets the .py files handled
My patch changes this back to actually only handling the extensions specified or .html .txt and .py if nothing is specified.
After patching, the find_files routine skips all unwanted/unknown extensions, even before diving into the TranslatableFiles fixing the confusing messages for unhandled extensions
Note: As far as I can see there a no unittest covering this part.
comment:3 by , 10 years ago
Has patch: | set |
---|---|
Needs tests: | set |
comment:5 by , 10 years ago
I've attached a (possible) failing test that should be fixed by the patch (I didn't verify this).
@iljamaas Are you interested in creating a pull request on Github for this ticket (combining both test and fix)?
comment:8 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Confirmed, we should definitely skip files with unrecognized extensions sooner in the process, in
find_files
.