GNU gettext - Bugs: bug #50357, xgettext doesn't recognise...
You are not allowed to post comments on this tracker with your current authentication level.
bug #50357: xgettext doesn't recognise encoding aliases Python supports
Submitter: | Geoffrey Sneddon <gsnedders> | ||
Submitted: | Sun 19 Feb 2017 10:11:55 PM UTC | ||
Category: | Python | Severity: | 3 - Normal |
Item Group: | None | Status: | Not a Bug |
Privacy: | Public | Assigned to: | haible |
Open/Closed: | Closed |
Jump to the original submission
Mon 20 Feb 2017 10:17:50 AM UTC, comment #6: |
Bruno Haible <haible> |
Mon 20 Feb 2017 10:12:06 AM UTC, comment #5:
But the "# coding:" marker is interpreted by different programs: not only by Python when it loads or compiles the file, but also by editors (Emacs et al.) when they display a file, or - here - by xgettext when it extracts internationalized strings.
|
Bruno Haible <haible> |
Sun 19 Feb 2017 11:37:12 PM UTC, comment #4: I'll also point out that character set name matching is standardised in various places; for example in UTR #22: <http://www.unicode.org/reports/tr22/tr22-7.html#Charset_Alias_Matching>. Per that, "utf8" and "UTF-8" refer to the same encoding. |
Geoffrey Sneddon <gsnedders> |
Sun 19 Feb 2017 11:33:33 PM UTC, comment #3: https://docs.python.org/3/library/codecs.html#standard-encodings documents the set of encodings Python's standard library supports, and all Python implementations to my knowledge support the same set of encodings for Python source files. Notably, that table includes utf8 as an alias.
|
Geoffrey Sneddon <gsnedders> |
Sun 19 Feb 2017 11:31:14 PM UTC, comment #2: In other words, just bite the bullet and change your source code to mention "# coding: utf-8". This is a one-time effort, and it's future-proof because the encoding name 'UTF-8' is standardized. |
Bruno Haible <haible> |
Sun 19 Feb 2017 11:28:19 PM UTC, comment #1: Thanks for the report.
|
Bruno Haible <haible> |
Sun 19 Feb 2017 10:11:55 PM UTC, original submission:
Given a file starting with `# coding: utf8` xgettext outputs:
|
Geoffrey Sneddon <gsnedders> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2017-02-19 | haible | Status | None | Not a Bug | |
Assigned to | None | haible | |||
Open/Closed | Open | Closed |
Powered by Savane 3.13-caa5.
Corresponding source code
No, name matching is not standardised. Different charset conversion libraries have different ways of doing it. The UTR #22 probably describes the way ICU does it, but ICU is != glibc, != libiconv, != Windows, != Solaris, etc.
Additionally, the problem with this specification is that it's not future-proof: If before, you have interpreted ISO-8859-1-5 as being equivalent to ISO-8859-15, it will break once an encoding ISO-8859-1-5 is really introduced. The text even states that this has already happened (for ISO-IR-9-1 and ISO-IR-9-2).