Subject: Re: Turkish (tr-TR) L10N patches
From: alper (shullgum@yahoo.com)
Date: Sat Dec 08 2001 - 22:58:12 CST
Andrew, *
After spending some time with NS6.2, I figured out that this thread has
some misleading results related to charset, encodings, etc due to
differences between Mozilla and NS6.2, and Andrew's misconceptions based
on rendering documents thru Mozilla.
No offense, please refer to my inline comments below:
On Fri, Dec 07, 2001 at 04:30:44PM +0000, Andrew Dunbar wrote:
>
> They've been checked in but I noticed the .strings
> file was not checked in.
> I also noticed that all the files seem to be in CP1254
> encoding but declare
> themselves to be ISO-8859-1.
No, they don't declare as such.
Mozilla, and NS6.2 too, parse the encoding param in <?xml> tag in
strings file, and set the encoding accordingly *if they recognize it*,
otherwise default to system locale.
In your case, Mozilla did not recognize ISO-8859-9 as encoding param, so
defaulted to your system locale, a.k.a ISO-8859-1.
In my case, NS6.2 recognized ISO-8859-9 in encoding param, so correctly
rendered and set the encoding.
I leave the explanation of this discrepancy between NS6.2 and Mozilla to
related gurus.
On Sat, Dec 08, 2001 at 03:19:43AM +0000, Andrew Dunbar wrote:
>
> Ah yes well I'm on Unix (: What you suggest doesn't
> fix the problem, it hides it. Declaring the correct
> encoding fixed it.
>
Well, the correct encoding you assert, which is "cp1254", is
unrecognizable by NS6.2. Now, I have to manually set the encoding or
change encoding param to "windows-1254" in xml tag, if not to
"ISO-8859-9".
> > > I had to manually set the encoding. But since
> > your
> > > system is probably set to a Turkish local it would
> > > have defaulted to the right encoding for you.
> > >
No, it did not default.
As I described above, both browsers are parsing the encoding param in
<?xml> tag.
>
> Well that's because Moz/NS6 can detect (usually) the
> different Cyrillic encodings because they are very
> different to the western europe ones. It can also
> detect Chinese, Japanese etc. It can't detect Turkish
> though since it's characters are also possible in
> west europe locales - icelandic for instance. It's
> tricky to explain.
No, there's no trick, it does not have a magical side as you believe.
NS6.2 rendered strings.ru-RU and strings.lt-LT correctly, because it
recognized encoding param in xml tag.
Just fiddle with the encoding param in those files and reload/re-render
to see what I'm talking about.
The bottomline, however, is NOT to find the correct encoding param
*string* for browsers, but for the parser of .strings file in AbiWord
(expat??).
Regards,
--alper
This archive was generated by hypermail 2b25 : Sat Dec 08 2001 - 22:59:30 CST