Page character set

Internet SteelSeries Gauges
1

I’ve set up the SteelSeries gauges on a Saratoga template page: http://meteo.aerolugo.com/lugo/wxgauges.php (see “Completos” tab).

I know about the different character set used by script and template, as kindly explained by Ken here: http://discourse.weather-watch.com/p/443932

If I change that page’s character set to UTF-8 all gauges works perfect, but I lose all spanish written accents. As long as the only problem is about the degree character (

2

Spanish will encode just fine in UTF-8. I think the problem you are having is that your PHP server is not set up to work in UTF-8 and is returning the Unicode characters (incorrectly) in ISO-8859-1.

I haven’t tried it myself (using English I do not use any Unicode characters), but this page shows one way of setting it up…
http://allseeing-i.com/How-to-setup-your-PHP-site-to-use-UTF8

EDIT: Actually, this is a pretty good summary of PHP 5.x’s problems with UTF-8, which are due to be fixed in ver 6 (fingers crossed).
http://www.phpwact.org/php/i18n/charsets

UTF-8 is now the default encoding for the vast majority of the web (>75%) given its flexibility of working with all languages.
http://w3techs.com/technologies/overview/character_encoding/all

3

Hi Luis,

With the existing Saratoga templates and languages other than English, you can’t really use UTF-8 for the character set as all the language translation files are in ISO-8859-n (except Hebrew), and the support scripts already take data from UTF-8 websites like WeatherUnderground and MeteoAlarm.eu and convert the output to ISO-8859-n appropriate to the particular language.

If you want the degree sign in the gauges to show correctly, the currently ‘safe’ way is to use a self-sizing

something like

<div id="main-copy">
  
   <h2>Current Weather Gauges</h2>
    <p>&nbsp;</p>
    <iframe id="ifgauges" src="/steelseries/indexif.html" width="630" frameborder="0"></iframe>


<script type="text/javascript">
function setIframeHeight(iframe) {
    if (iframe) {
        var iframeWin = iframe.contentWindow || iframe.contentDocument.parentWindow;
        if (iframeWin.document.body) {
            iframe.height = iframeWin.document.documentElement.scrollHeight || iframeWin.document.body.scrollHeight;
        }
    }
};

window.onload = function () {
    setIframeHeight(document.getElementById('ifgauges'));
};
</script>    
</div><!-- end main-copy -->

which can be seen here.

It does have the

The reason I did the Saratoga templates in ISO-8859-n languages was largely to keep the browser load down … the UTF-8 font set is huge and contains a lot of mostly-unneeded characters, and not all display fonts are available in UTF-8 (mostly Arial/Helvetica is universally available). It was just easier on
the webmasters using the templates to stick to a simple ISO font at the time.

Mark, you’re correct in that most multilingual sites now use UTF-8 since it makes it easier on their webmasters :slight_smile:

The issue for the Saratoga templates (USA and Canada) to use UTF-8 is the bulk of the external data from NOAA/NWS and Environment Canada comes in ISO-8859-1, so for the Canadian sites, the ec-radar/ec-forecast scripts would need to convert ISO-8859-1 to UTF-8 for the French translations.

Best regards,
Ken

4

Thanks Ken, I understand how we go where we are, I was just trying to find ways forward without invoking iframes, but I must confess to not knowing much about PHP (or how character encoding is handled).

I believe PHP does have a utf8_encode() function for converting ISO-8859-1 strings to UTF-8 which could be used for the input data feeds.
BUT I realise your templates came first, are very widely used, and changing them is probably not a task you would wish to, or even desire to undertake.
Integrating these types of things is nearly always more complex than it first appears.

5

So I see it’s not a simple question. I have to decide.

Ken, Mark, thanks for all your help.

6

Yes, I use the iconv() function to change character sets as needed (in WU-forecast.php and get-meteoalarm-warning-inc.php ) already.

I suppose my next task is to generate a HTML5/CSS3/UTF-8 version of the AJAX/PHP templates (as a Version 4) and thereby fix it for the future.

I was kinda waiting for HTML5 to become a real standard, and not just supported (variously) by modern browsers. Older browsers (IE8-) still have only funky (or no support) and there appear to be a lot of folks still using the old browsers. It’s one of the reasons why I chose the lowest-common-denominator and used XHTML 1.0-Transitional/CSS2 as the base… even the old browsers support that (and the new ones too :slight_smile: )

Best regards,
Ken

7

Well if you do ever take that mammoth task on, think of all the cool new CSS3 features you can implement :wink:

8

It’s on my ‘to-do’ list, so sometime likely this year as HTML5/CSS3 proceeds to standardization. I just didn’t want to do all the hacked-up browser-specific CSS needed to give it a fresh face … also, multiple scripts to add iconv() features to make it work.

Sometime before year-end 2013 I think it’s feasible for me to package it up. With over 700 sites using the template sets, I also have to provide a upgrade/migration utility set too (as I did for the V2->V3 set).