--- alper <[EMAIL PROTECTED]> wrote: > Andrew, * Hi Alper. I no longer have access the machine I was developing on a few days ago but you're probably right. I was staying up all night hacking for a week and could've thought I was seeing ISO-8859-1 when you really had ISO-8859-9. Though changing these to CP1254 did certainly fix it on my system. I'm now a bit worried that there's an iconv issue for Turkish. It appears that my system worked for cp1254 but not 8859-9 and yours works for 8859 but not cp1254. Not all iconvs are created equal ): I hope some people can make sure that AbiWord works in Turkish on all systems. Sorry for any confusion I may have caused.
> 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. Okay I believe you. I can't try it now since I'm in an internet cafe. > The bottomline, however, is NOT to find the correct > encoding param > *string* for browsers, but for the parser of > .strings file in AbiWord > (expat??). This could be it. I wonder if it behaves differently with libxml. As I say the only other thing I can think of is iconv, also a constant source of grief. Andrew Dunbar. ===== http://linguaphile.sourceforge.net ________________________________________________________________ Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001.
