Subject: Re: Turkish (tr-TR) L10N patches
From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Sun Dec 09 2001 - 09:25:34 CST
--- alper <shullgum@yahoo.com> 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.
This archive was generated by hypermail 2b25 : Sun Dec 09 2001 - 09:25:36 CST