GNOME Bugzilla – Bug 329685
Add Meta Tags to HTML export for encoding, etc
Last modified: 2006-08-11 15:19:53 UTC
Please describe the problem: If gallery have been exported to local folder, then it should contain meta tag with Content-Type field. It's not a problem for server-side viewing, but it is for local viewing of galleries <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 60415 [details] [review] patch adding some useful stuff to the html output Hi, I've written a simple patch to fix this. My patch also adds language info, based on the current locale. My fix assumes the HTML is always UTF8-encoded because as I understand it the assumption is right. But as I couldn't find any documentation for this topic, I'm not 100% sure. So this may need to be improved.
*** Bug 335929 has been marked as a duplicate of this bug. ***
Changing the title to be more findable. Thomas, can you check the patch attached to the duplicate bug and see if there's anything to integrate into yours? Thanks guys!
I confirm that this is a duplicate, that the patch is mostly OK and better than the patch submitted with #335929. However, locales can be of the form fr_FR@euro (variant, but no charset given), so the patch should also trim the @... part to give LANG info correctly: + if (language.IndexOf('@') >= 0) + language = language.Substring(0,language.IndexOf('@')); should be added to the patch
I cleaned up the match, so that it compiles properly against CVS, added the @ treatement, made it global to all galeries (not specific to html gallery), made so that language is not computed for every page (it does not change for one gallery). Patch follows.
Created attachment 62107 [details] [review] revised patch
Hi, Sorry for the late reply but I had not seen the activity here (partly because I was not in the Cc list and partly because I was far away from my computer for over a month). Jean-Christophe's patch looks fine to me and seeing as it is a rather minor change but an important one for anybody needing more than us-ascii, I would really like to see it taken into use. Anything we can do to help that happen?
Just did a quick visual inspection of this patch, and it looks good. Just one comment +if (language.IndexOf('@') >= 0) + language = language.Substring(0,language.IndexOf('.')); Is this correct? Should it not be IndexOf('@') instead?
*** Bug 345098 has been marked as a duplicate of this bug. ***
*** Bug 350650 has been marked as a duplicate of this bug. ***
I fixed the small error that Bengt caught and committed to HEAD. Thanks guys!