Use UTF-8 (Unicode) charset encoding for current templates

RESOLVED FIXED in Bugzilla 2.20

Status

()

Bugzilla
Bugzilla-General
RESOLVED FIXED
13 years ago
10 years ago

People

(Reporter: Wurblzap, Assigned: Wurblzap)

Tracking

2.19.3
Bugzilla 2.20
Bug Flags:
approval +

Details

Attachments

(1 attachment, 1 obsolete attachment)

2.68 KB, patch
Frédéric Buclin
: review+
Details | Diff | Splinter Review
(Assignee)

Description

13 years ago
To prepare the way for bug 126266, and to make life easier for localizers,
templates should be encoded in UTF-8. (Most templates use 7-bit ASCII encoding
and therefore automatically UTF-8, too.)

Some templates have started using ISO-8859-1, though; this bug converts them to
UTF-8.
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Bugzilla 2.20
(Assignee)

Comment 1

13 years ago
Created attachment 183888 [details] [diff] [review]
Patch
Attachment #183888 - Flags: review?(LpSolit)
(Assignee)

Updated

13 years ago
Attachment #183888 - Flags: review?(LpSolit)
(Assignee)

Comment 2

13 years ago
It turns out UTF BOM header bytes may be displayed interspersed into pages if
templates are UTF-8 encoded and the page's charset encoding is something else
(ISO-8859-1, for example).

Morphing bug to want plain ASCII.
Summary: Use UTF-8 (Unicode) charset encoding for current templates → Use plain ASCII charset encoding for current templates
(Assignee)

Comment 3

13 years ago
Created attachment 183995 [details] [diff] [review]
ASCII patch

Not too nice to mangle somebody's name :(
Attachment #183888 - Attachment is obsolete: true
Attachment #183995 - Flags: review?(LpSolit)

Comment 4

13 years ago
Comment on attachment 183995 [details] [diff] [review]
ASCII patch

r=LpSolit assuming I am the only one in this situation. But I would be very
happy if we could find a way to keep my first name with 'é' in it. :(
Attachment #183995 - Flags: review?(LpSolit) → review+
(Assignee)

Updated

13 years ago
Flags: approval?
(In reply to comment #2)
> It turns out UTF BOM header bytes may be displayed interspersed into pages if
> templates are UTF-8 encoded and the page's charset encoding is something else
> (ISO-8859-1, for example).

Uh, say what?  UTF-8 doesn't need byte order marks (That's a UCS2/UTF-16 thing),
and we shouldn't be using them.  The page charset should always ben UTF-8 as
well once bug 126266 lands.

> Morphing bug to want plain ASCII.

Please don't.  Or convince me why (the arguments presented thusfar are not
enough to convince me).
Flags: approval? → approval-
(Assignee)

Comment 6

13 years ago
(In reply to comment #2)
> It turns out UTF BOM header bytes may be displayed interspersed into pages if
> templates are UTF-8 encoded and the page's charset encoding is something else
> (ISO-8859-1, for example).

Well, when trying to set up a test case to show the effect I saw, I couldn't,
but all pages displayed just fine. I asked Frédéric to confirm, and he didn't
see any problems either. I think when testing this yesterday I must accidentally
have saved some template file with BOM header bytes.

So, back to the original assumption it is, therefore to the original goal, and
thus to the original patch.
Summary: Use plain ASCII charset encoding for current templates → Use UTF-8 (Unicode) charset encoding for current templates
(Assignee)

Updated

13 years ago
Attachment #183995 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #183888 - Attachment is obsolete: false
Attachment #183888 - Flags: review?(LpSolit)

Comment 7

13 years ago
Comment on attachment 183888 [details] [diff] [review]
Patch

seems to work...
Attachment #183888 - Flags: review?(LpSolit) → review+

Updated

13 years ago
Flags: approval- → approval?
Flags: approval? → approval+

Comment 8

13 years ago
In order to prevent such things in the future, runtests.pl should warn if
non-UTF8 characters exist in templates. Is there already a bug about that? If
not, should we open one?


Checking in template/en/default/admin/milestones/confirm-delete.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/milestones/confirm-delete.html.tmpl,v
 <--  confirm-delete.html.tmpl
new revision: 1.3; previous revision: 1.2
done
Checking in template/en/default/admin/milestones/deleted.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/milestones/deleted.html.tmpl,v
 <--  deleted.html.tmpl
new revision: 1.3; previous revision: 1.2
done
Checking in template/en/default/admin/versions/confirm-delete.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/versions/confirm-delete.html.tmpl,v
 <-- confirm-delete.html.tmpl
new revision: 1.3; previous revision: 1.2
done
Checking in template/en/default/global/user-error.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v
 <--  user-error.html.tmpl
new revision: 1.109; previous revision: 1.108
done
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.