Feature request: PCDataXmlParser flag to not convert entity references to utf-8
From
http://groups.google.com/group/liftweb/browse_thread/thread/4e33f1f2cdd02b35/352960c7974b5be3#352960c7974b5be3
> > PCDataXmlParser converts entity references to actual utf-8
> > characters. This means templates with entity references won't round-
> > trip correctly through view source, nor through localization
> > properties files / gettext files.
> Hmmm... is this worth a flag someplace to disable this behavior?
This would be extremely helpful to us, just submitting a ticket to make sure it's on the radar.
I don't mind submitting an example, given some direction on the preferred approach
http://groups.google.com/group/liftweb/browse_thread/thread/4e33f1f2cdd02b35/352960c7974b5be3#352960c7974b5be3
> > PCDataXmlParser converts entity references to actual utf-8
> > characters. This means templates with entity references won't round-
> > trip correctly through view source, nor through localization
> > properties files / gettext files.
> Hmmm... is this worth a flag someplace to disable this behavior?
This would be extremely helpful to us, just submitting a ticket to make sure it's on the radar.
I don't mind submitting an example, given some direction on the preferred approach
Leave a comment
on 2010-02-06 20:51 *
By github.importer
Imported from GitHub: http://github.com/dpp/liftweb/issues/274/find
on 2010-02-11 17:41 *
By
FYI we now have a relatively hassle-free workaround for our particular gettext localization toolchain ( turns out that msgcat --properties-input doesn't handle encoded java properties correctly, but xgettext --language=JavaProperties does . . .)
I still think it'd be a useful flag, but it's not a priority for us.
I still think it'd be a useful flag, but it's not a priority for us.
I'm not sure what you mean by they are not converted - here's a reproducible case of what I'm talking about
Using a fresh archetype from 2.0-M2, no changes to anything other than index.html:
[cody@koeninger todo]$ cat src/main/webapp/index.html
<lift:surround with="default" at="content">
<p> here's an mdash: — </p>
</lift:surround>
[cody@koeninger todo]$ wget -O - cody.koeninger.org:8080 | grep mdash
--2010-03-04 03:06:24-- http://cody.koeninger.org:8080/
Resolving cody.koeninger.org... 174.143.242.144
Connecting to cody.koeninger.org|174.143.242.144|:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3159 (3.1K) [text/html]
Saving to: `STDOUT'
100%[======================================>] 3,159 --.-K/s in 0s
2010-03-04 03:06:24 (1.51 MB/s) - `-' saved [3159/3159]
<p> here's an mdash: â </p>
I would expect that last line to be
<p> here's an mdash: — </p>
Like I said, now a low priority for us, feel free to close it if it's a feature you wont add . . . but unless I'm missing something, Lift does actually behave the way I described.
Using a fresh archetype from 2.0-M2, no changes to anything other than index.html:
[cody@koeninger todo]$ cat src/main/webapp/index.html
<lift:surround with="default" at="content">
<p> here's an mdash: — </p>
</lift:surround>
[cody@koeninger todo]$ wget -O - cody.koeninger.org:8080 | grep mdash
--2010-03-04 03:06:24-- http://cody.koeninger.org:8080/
Resolving cody.koeninger.org... 174.143.242.144
Connecting to cody.koeninger.org|174.143.242.144|:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3159 (3.1K) [text/html]
Saving to: `STDOUT'
100%[======================================>] 3,159 --.-K/s in 0s
2010-03-04 03:06:24 (1.51 MB/s) - `-' saved [3159/3159]
<p> here's an mdash: â </p>
I would expect that last line to be
<p> here's an mdash: — </p>
Like I said, now a low priority for us, feel free to close it if it's a feature you wont add . . . but unless I'm missing something, Lift does actually behave the way I described.
(In revision:629ba2515b3309dc374161564ec4a50e32ea9bc6) Closes #274. Entities are resurected as &whatever; on output
Branch: master
Branch: master