Generally the page's encoding is followed, unless the server specifies an encoding. As the <meta> tag seems to specify what you're expecting, and as manually switching to that value helps, it sounds like the server you're getting the page from is sending an incorrect encoding (Windows-1252) in the headers to the browser.
The proper way to fix it is to configure the server properly. For a company webserver, this probably means bugging the server admin to do it.
To see the (wrong) headers, if you're familiar with such tools, you can use things like Firebug's "Net" panel in Firefox, or Web Inspector's "Resources" panel in Chrome or Safari. Or, if you don't know these tools and the web site is publicly accessible, then you easily see the server's headers online using, for example, Web-Sniffer.
Assuming the login page specifies the same as the actual pages, then this yields:
Content-Type: text/html
...without any value for charset. Not sure if a browser should then still interpret that <meta> tag, but apparently Firefox is ignoring it, and making some best guess.
Firefox ignoring it might be caused by the HTML source. The <meta> tag should always be specified within <head> before anything else, as it might also apply to the title, scripts, CSS and so on. On this site, it doesn't and, even worse, the HTML is a total mess:
<SCRIPT LANGUAGE=JavaScript SRC="/dergi/_ScriptLibrary/pm.js"></SCRIPT>
<SCRIPT LANGUAGE=JavaScript>
thisPage._location = "/dergi/giris/login.asp";
</SCRIPT>
<FORM name=thisForm METHOD=post>
<HTML>
<style type="text/css">
<!--
[..]
-->
</style>
<HEAD>
[..]
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="TEXT/HTML; CHARSET=WINDOWS-1254">
<META NAME="GENERATOR" CONTENT="Microsoft FrontPage 5.0">
<META NAME="AUTHOR" CONTENT="[removed to protect the innocent...]">
<TITLE>YAYSAT DERGİ RAPORLARI</TITLE>
</HEAD>
<BODY>
<center>
[..]
</center>
</body>
<INPUT type=hidden name="_method">
<INPUT type=hidden name="_thisPage_state" value="">
</FORM>
</html>
Huge developer fail.
(Incidentally, Web-Sniffer shows <meta http-equiv=content-type content="text/html; charset=ISO-8859-1">, but that is due to its values for Accept-Charset. Firebug shows <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="TEXT/HTML; CHARSET=WINDOWS-1254"> just like in the question.)
As detailed here, you should be able to set the default encoding to UTF-8 (preferably without BOM) in the Preferences. I don't think this is affected by the system codepage.
The system-codepage-sniffing to change UI language is sad. I'm seen this commonly in poorly-written Japanese programs, but for DW to be doing that too is disappointing. Applications that do this need to be taken outside and shot. To get around it, you can use apploc to change the codepage a particular application sees when it runs.
Best Answer
In
about:config, setintl.charset.fallback.utf8_for_filetotrue.However, this only works for local files (
file:///URLs).(shamelessly copied from this answer)